Global hook for permissions

Wish to see a specific feature/change in future releases? Feel free to post it here, and if it gets enough "likes", we'd definitely include it in future releases!
Post Reply
jlarmarange
Posts: 16
Joined: 2019-02-21 19:03

Global hook for permissions

Post by jlarmarange » 2019-06-13 09:45

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


User avatar
a.gneady
Site Admin
Posts: 1281
Joined: 2012-09-27 14:46
Contact:

Re: Global hook for permissions

Post by a.gneady » 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?
:idea: AppGini plugins to add more power to your apps:
  • DataTalk is an innovative AppGini plugin based on ChatGPT that allows you to interact with your AppGini database using natural language questions, without writing any SQL. Check the demo video
  • Mass Update plugin: Update multiple records at once and improve your workflow efficiency.
  • Check our other plugins and get a generous discount of up to 30% when buying 2 or more plugins.

User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

Re: Global hook for permissions

Post by onoehring » 2019-06-23 06:07

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

User avatar
jsetzer
AppGini Super Hero
AppGini Super Hero
Posts: 1807
Joined: 2018-07-06 06:03
Location: Kiel, Germany
Contact:

Re: Global hook for permissions

Post by jsetzer » 2019-06-23 06:51

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
Kind regards,
<js />

My AppGini Blog:
https://appgini.bizzworxx.de/blog

You can help us helping you:
Please always put code fragments inside [code]...[/code] blocks for better readability

AppGini 24.10 Revision 1579 + all AppGini Helper tools

User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

Re: Global hook for permissions

Post by onoehring » 2019-06-23 09:05

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

jlarmarange
Posts: 16
Joined: 2019-02-21 19:03

Re: Global hook for permissions

Post by jlarmarange » 2019-09-06 09:18

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.

jlarmarange
Posts: 16
Joined: 2019-02-21 19:03

Re: Global hook for permissions

Post by jlarmarange » 2019-09-06 09:21

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

User avatar
jsetzer
AppGini Super Hero
AppGini Super Hero
Posts: 1807
Joined: 2018-07-06 06:03
Location: Kiel, Germany
Contact:

Re: Global hook for permissions

Post by jsetzer » 2019-09-06 10:56

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
Kind regards,
<js />

My AppGini Blog:
https://appgini.bizzworxx.de/blog

You can help us helping you:
Please always put code fragments inside [code]...[/code] blocks for better readability

AppGini 24.10 Revision 1579 + all AppGini Helper tools

User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

Re: Global hook for permissions

Post by onoehring » 2019-09-06 11:17

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 9869 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

jlarmarange
Posts: 16
Joined: 2019-02-21 19:03

Re: Global hook for permissions

Post by jlarmarange » 2020-02-24 09:51

Thanks a lot for the discussion.

Just wondering if any evolution since September last year?

Post Reply