Page 1 of 1

Global hook for permissions

Posted: 2019-06-13 09:45
by jlarmarange
Would it be a way to have a hook allowing to define custom permissions functions without overwriting files generated by AppGini? With a global hook for example.

I have a project management system and all tables are sub-tables of the main Projects table. I want to define permission per project, using a link table between Projects and Users.

Therefore, I would like to be able to write my own functions defining what a user can see and modify.

Best regards

Re: Global hook for permissions

Posted: 2019-06-16 06:57
by onoehring
Hi,

I would add my voice to that as well.
Olaf

Re: Global hook for permissions

Posted: 2019-06-22 15:24
by a.gneady
Hmm .. to make sure I understand what you describe, would this be for example something like this:

Code: Select all

get_custom_permissions($table, $pk, $operation, $user_info)

that the application would call before displaying a record, editing or deleting it? The application would call this function passing the table name, the primary key value of the record, the operation ('view', 'edit', 'delete') and the user info array, and then if the return value is true, the operation is allowed, else it's denied. Did I understand this correctly?

Re: Global hook for permissions

Posted: 2019-06-23 06:07
by onoehring
Hi,

yes, I guess that sounds reasonable.
Even passing PK seemed first weird to me, it is a good idea for handling the response.

Olaf

Re: Global hook for permissions

Posted: 2019-06-23 06:51
by jsetzer
Hi,

for :arrow: table view, how about using the existing TABLENAME_init()-function in TABLENAME.php? We already have the $options-variable which contains most of the required properties like ...
  • AllowInsert
  • AllowUpdate
  • AllowDelete
  • AllowMassDelete
  • AllowDeleteOfParents
  • ...
AppGini could evaluate the values after the TABLENAME_init()-call and apply the settings accordingly.


For :arrow: detail view, personally I'd prefer a hook-function inside TABLENAME.php for having all table-related stuff together in one file.

I'm wondering if we need a new hook-function or if we could use the existing TABLENAME_dv()-function, extended by a new $options-variable similar to TABLENAME_init().

Concerning "global hook" for permissions:
Great idea, Ahmed! Having the record's primary key (PK) would be perfect! :)

Additionally I suggest some kind of hierarchy:
If exists, the more detailed permission-configuration (defined in TABLENAME.php) overrules the global permission-configuration which overrules the permissions defined in admin-area.

Best,
Jan

Re: Global hook for permissions

Posted: 2019-06-23 09:05
by onoehring
Hi,

as I am to new to AG to know so much details as Jan does, I suppose, his suggestion to use existing infrastructure is better than creating something here, and another there.

Olaf

Re: Global hook for permissions

Posted: 2019-09-06 09:18
by jlarmarange
a.gneady wrote:
2019-06-22 15:24
Hmm .. to make sure I understand what you describe, would this be for example something like this:

Code: Select all

get_custom_permissions($table, $pk, $operation, $user_info)

that the application would call before displaying a record, editing or deleting it? The application would call this function passing the table name, the primary key value of the record, the operation ('view', 'edit', 'delete') and the user info array, and then if the return value is true, the operation is allowed, else it's denied. Did I understand this correctly?
That would be great, as it will allow to define permissions per record.

Re: Global hook for permissions

Posted: 2019-09-06 09:21
by jlarmarange
Another comment, it will also be relevant to use that function before inserting a record.

Just a quick example. Consider a project management system with sub-tables attached to projects. You could consider that a user could have the right to insert records in a sub-table only for certain projects and not for other projects.

Best regards

Re: Global hook for permissions

Posted: 2019-09-06 10:56
by jsetzer
Good point, thank you!

When opening the project detail view the function projects_dv() will be executed. If we had a function like get_custom_permissions($table, $pk, $operation, $user_info) (see above), we were able to evaluate permissions for the (master-) record itself AND perhaps for all related data-subsets of children-tables.

If AppGini could give us an &$options-variable in TABLENAME_dv()-function, as I have suggested above, this could be an array like this (1st draft):

Code: Select all

$options = [
	// permissions for master-record
	"master" => [
        	"tableName" => "project",
        	"title" => "Projekt" . $data["name"],
        	"permissions" => [
        		"edit" => true, // all fields are editable
        		"update" => true, // enables "Save"
        		"copy" => false, // disables "Save as copy"
        		"delete" => false // disables "Delete"
        	]
        ], 
        // permissions for detail tables / children-records
        "details" => [
	        "project_tasks" => [
	        	"title" => "Aufgaben", // controls tab caption
	        	"permissions" => [
	        		"insert" => false, // disables insertion of project_tasks
	        		"view" => "modal", // controls behaviour of button: { off | modal | _self | _blank }
	        		"edit" => false, // when opening a sub-record, disable editing
	        		"update" => false, // disable "save" of sub-record
	        		"copy" => false, // disable "save as copy" for sub-record
	        		"delete" => false // disable "delete" of sub-record
	        	] // permissions
		], // project_tasks
                "project_milestones" => [
			"title = "Meilensteile",
			"permissions" => [
				// ...
			] // permissions
                ] // project_milestones
        ]
];
Having this kind of $options-variable (or any other variable name like $datamodel or $viewmodel or just $model) we could control the behaviour and even control the view (eg change title or tab-captions) for master-record AND for all detail-tabs/-records.

Wouldn't that be great?

Maybe they can combine this idea with one feature which has been requested here a couple of times already: field-dependent permissions!

Imagine the $options variable like this:

Code: Select all

$options = [
	// permissions for master-record
	"master" => [
        	// ...
        	"permissions" => [
        		...
        	], "columns" => [
        		"id" => [
        			"visible" => false
        		], "name" => [
        			"label" => "Project Name",
        			"edit" => $currentuser_is_projectowner, // evaluate before
        			"align" => "left" // { left | center | right }
        		]
        		// ... 
        	]
	], 
	// ...
]
There are some more ideas in my mind, but I think it would already be great and a big step forward if BigProf could implement that.

Best,
Jan

Re: Global hook for permissions

Posted: 2019-09-06 11:17
by onoehring
Hi Jan,

nice 1st draft.
I wonder if your
"copy" => false, // disable "save as copy" for sub-record
is really not a "create" premission?

Some idea/tip
Something else as an idea (also tip/trick for others). You mention this:
"view" => "modal", // controls behaviour of button: { off | modal | _self | _blank }
In a project I created a drop down where the user is able to define where a clicked link is to be opened:
ec96dropdown.png
ec96dropdown.png (3.93 KiB) Viewed 9886 times
For non German speakers this means (3 items, top to bottom):
[1] always in a new, but always the same tab
[2] always in a new tab
[3] this tab

The HTML code behind this is easy - but I was not aware (before searching) that one can actually do, what I did for [1], where I open the link in the My_TAB_Name tab. Meaning: You can name your own tab besides _blank and _self!

Code: Select all

<select id="ziel" name="ziel" onchange="this.form.submit()" class="input-sm">
	<option selected="" value="My_TAB_Name">in neuem, aber immer gleichen Tab</option>
	<option value="_blank">immer in neuem Tab</option>
	<option value="_self">aktueller Tab</option>
</select>
Olaf

Re: Global hook for permissions

Posted: 2020-02-24 09:51
by jlarmarange
Thanks a lot for the discussion.

Just wondering if any evolution since September last year?