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
Global hook for permissions
Re: Global hook for permissions
Hi,
I would add my voice to that as well.
Olaf
I would add my voice to that as well.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Global hook for permissions
Hmm .. to make sure I understand what you describe, would this be for example something like this:
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?
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?
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.
Re: Global hook for permissions
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
yes, I guess that sounds reasonable.
Even passing PK seemed first weird to me, it is a good idea for handling the response.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Global hook for permissions
Hi,
for 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 ...
For 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
for 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
- ...
For 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
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<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 readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Global hook for permissions
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
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
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
-
- Posts: 16
- Joined: 2019-02-21 19:03
Re: Global hook for permissions
That would be great, as it will allow to define permissions per record.a.gneady wrote: ↑2019-06-22 15:24Hmm .. 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?
-
- Posts: 16
- Joined: 2019-02-21 19:03
Re: Global hook for permissions
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
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
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):
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:
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
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
]
];
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 }
]
// ...
]
],
// ...
]
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
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<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 readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Global hook for permissions
Hi Jan,
nice 1st draft.
I wonder if your
Some idea/tip
Something else as an idea (also tip/trick for others). You mention this:
[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!
Olaf
nice 1st draft.
I wonder if your
is really not a "create" premission?"copy" => false, // disable "save as copy" for sub-record
Some idea/tip
Something else as an idea (also tip/trick for others). You mention this:
In a project I created a drop down where the user is able to define where a clicked link is to be opened: For non German speakers this means (3 items, top to bottom):"view" => "modal", // controls behaviour of button: { off | modal | _self | _blank }
[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>
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
-
- Posts: 16
- Joined: 2019-02-21 19:03
Re: Global hook for permissions
Thanks a lot for the discussion.
Just wondering if any evolution since September last year?
Just wondering if any evolution since September last year?