Page 1 of 1

Column-Value-Based-Permissions

Posted: 2020-03-20 09:50
by onoehring
Hi,

me again.
I created a new permission check: Column-Value-Based permissions (CVB) enable you to hide certain records from usergroups if
these records have a specific value in a (lookup) field.

What does it do?
You have project managers and each project manager should only see projects that are assigned to him/her. Let’s say usergroup North has projects Greenland, Norway and Kenya (yes, I know this is pretty equator, but wait, you will read in a minute why it’s there). Another usergroup of your
application names South has South Africa, Australia and Kenya. You notice: Both have Kenya.
Now think, that your table “travels” has a column “country” that holds the country with currently possible values of Greenland, Norway, Kenya, South Africa and Australia.
This extension of AG enables you to show the entries of table “travels” based on the fields value of the column country, resulting in this: Usergroup North sees only records from it’s area: Greenland, Norway and Kenya. Group South sees only South Africa, Australia and Kenya. Both groups work
on Kenya, so both have access to them. Other records that do not match the criteria (for options, see below), are not shown. Short: In tableview (TV) - see or no see; in detailview (DV) allow access or do not allow access.
CVB is different from AG’s permissions model as in CVB one user can “belong” to different groups at the same time.

It looks like this (in the demo)
Permissions table
Colum-Definition v2.png
Colum-Definition v2.png (15.41 KiB) Viewed 2046 times
Data the superadmin sees
vSuperadmin.png
vSuperadmin.png (13.69 KiB) Viewed 2046 times
Data usergroup North sees
vNorth.png
vNorth.png (10.7 KiB) Viewed 2046 times
Data usergroup South sees
vSouth.png
vSouth.png (11.15 KiB) Viewed 2046 times

It's working for me and while documenting I think I fixed some bugs, so go ahead and try (and give feedback).
In my opinion it's much easier to implement that my Field-Permissions extension ( viewtopic.php?f=4&t=3308&start=25 ).

Download v0.8 (340 KB)
https://dl.olaf-noehring.de/?t=8c3138f6 ... acbe9f8cf0

Download complete AG demo v0.8 (1.2 MB, does not include how-to/docs!)
AXP file, generated and extended application, complete SQL just throw on your testserver and try
https://dl.olaf-noehring.de/?t=6f16271e ... 2a19857846

Suggestions? Feedback? Please.
Olaf

Re: Column-Value-Based-Permissions

Posted: 2020-04-04 01:13
by dge
This looks like it may be related to a project requirement we have.

Except, instead of trying to hide data, we want to show data from ONE other user, together with the user's data.

The idea is to create pre-packaged data from a user called "resource" and have it be available to all users along with their own data.

The "resource" data will be read only. We don't want the users to see other users/groups data, only their own, and the read-only data from "resource".
Why? We want to pre-populate the system with some useful information about a certain industry and make it available to all users.

Any thoughts or ideas? Thanks so much!
David

Re: Column-Value-Based-Permissions

Posted: 2020-04-04 07:26
by onoehring
Hi,

interesting problem.

First - maybe also of interest:
Column-Value-Based Permissions (CVB) allows you to set a parameter which changes it's behavior (documented in the docs):
param_allow_general: Is either 1, 2 or 3, no quotation marks around.
1: The user is allowed to see ALL records IF NO results are found (no entry in the $table_name). If
results are found, user is allowed to see only these.
2: The user is allowed to see ONLY records for which an entry exists
3: The user is allowed to see ALL records EXCEPT those in the list
So, the problem I see with your request is, that we have the tableview which enables viewing only and the detail view - which allows editing (or the combination). The problem for TV is, we need to have some criteria which enables decision if the record is shown to the user (CVB should be able to do this: param_allow_general = 2).
For the detail view then (in your case) the user will need to be able to edit his own records, but not the "read only".
So there needs to be a check, possibly in the /hooks/tablename.php -> _init function. This check will need to test, if the current record (that will be shown for editing) is one of the regular or one of the read only group.
This could also be done utilizing the field by CVB (I would actually suggest that) - but currently you would need to write your own check. If it's a read-only record the user wants to see, your code will need to set some options in the _init function which disable the option to edit, insert and delete. These are:

Code: Select all

 $options->AllowDelete = 0;
 $options->AllowInsert = 0;
 $options->AllowUpdate = 0;
Probably also

Code: Select all

 $options->AllowDeleteOfParents = 0;
 $options->AllowMassDelete =0;
So your code (in /hooks/tablename.php -> function _init) might look like this (dirty code, just typed down):

Code: Select all

if (CHECK_YOUR_REQUIREMENTS === FALSE) {
   $options->AllowDelete = 0;
   $options->AllowInsert = 0;
   $options->AllowUpdate = 0;
   $options->AllowDeleteOfParents = 0;
   $options->AllowMassDelete =0;
} else {
 // nothing to do for your request here
}
Hope this helps
Olaf