Grav 1.7 User management/groups error message

[paulhibbitts]

I am really jazzed about the new user management stuff added into Grav 1.7!

I've got the following scenario:

• user group-1 that can manage/edit pages in folder-1, but not in folder-2
• user group-2 that can manage/edit pages in folder-2, but not in folder-1

Here are the screenshots of this setup:

The above works fine for user/group with CRUD rights to a folder. However, when a user without permissions tries to view a page an error message is flashed:

TypeError: Cannot convert undefined or null to object
    at Function.keys ()
    at http://localhost:8888/_TESTS/grav-skeleton-open-matter-multicourse-hub-site-users/user/plugins/admin/themes/grav/js/admin.min.js?757d8b1c0d:4150:16
    at http://localhost:8888/_TESTS/grav-skeleton-open-matter-multicourse-hub-site-users/user/plugins/admin/themes/grav/js/admin.min.js?757d8b1c0d:1072:12

What might be causing this? After the message is displayed and a user without rights tries to save a change to the page a message is displayed that they do not have the needed permissions (as expected).

However, I notice that subsequent pages (with Page Inherit option selected) do not actually show the unallowed Save button:

Is the Save button supposed to be hidden when the user does not have the needed permissions to save? This would be preferred to me.

Thanks very much for any helpful info etc. Happy to provide more info.
Paul

[mahagr]

First your user should probably not have any page permissions set, do those from the group. Also it may be better not to allow group to edit all pages, so just set the List (and maybe Read) permission from there and leave the other not set. This will prevent user from editing pages outside his group permissions. Giving access based on group is a better idea than taking access away. :)

Also I fixed the bug where user was able to see the page without permissions:

Fixed in trilbymedia/grav-plugin-flex-objects@e657321

[paulhibbitts]

Hi @mahagr , thanks so much for looking into this and that advice!

Here is my re-configured user rights setup (does this look like a better practice?):

I've tested your new commit with the above and the Save button now does not appear when a user cannot Save, thank you!
Paul

[mahagr]

What I would do is to still edit group to remove everything else but the rules you want group to have. So basically group should not have set anything else but pages list and read. Other rules can be in either user or another group. Then in the page remove red deny access from both groups.

In this way you can assign user to both groups to get access to both pages and their children.

[paulhibbitts]

Thanks very much Matias, but I am not quite following.

Here is what I am trying to do:

• users in group1 can edit only certain pages (folders) and their sub-folders
• users in group2 can only only other certain pages (folders) and their sub-folders

Based on the above I've set page editing rights for both groups, but then using Page Security to set at the page (folder) level the ability to Save. The above seems to be working on my test install.

Is this still containing unneeded steps? I was not able to add "groups" to Pages without saving CRUD options BTW.
Paul

[paulhibbitts]

@mahagr , I think I figured out what you meant🙂

For others following along, here is my revised setup:

So as Matias described, groups only have read/list page permissions, but then specific Update/Create/Delete rights are assigned at the page/folder level!

Thanks again @mahagr for your help.

UPDATE: I've tweeted a mini-guide to help other Grav users with what I've learned though this issue https://twitter.com/hibbittsdesign/status/1358874005982224384?s=20

[mahagr]

Again, I would never use Denied as it gets preferred over Allowed -- so if you have user with two groups assigned with one using deny and another allow, deny will always win. So deny is really used to enforce one rule over another if they are otherwise equal.

So as an example from your first screenshots user belongs to both group1 and group2. If in the page you have one group with all allowed and another with all denied, this user has no access to either of the pages. If you remove the deny rules like you did, in this case user can access both of the pages as it belongs to both of the groups.

But the same works also in the group level. Now think that user belongs to group1, but is also a "content manager", who has full access to pages. Unfortunately in this case belonging into group prevents the user from managing pages, because of you are blocking anyone in group1 from doing that. If you change denied rules into not set, user can belong into both groups and still be able to do his work.

So in short, deny rules should really be used only if you want to override broader rules with more strict rules for specific users.

This said, there is hierarchy for these rules where allow in higher level overrides (or skips tests for) deny with lower priority: Page author > Page Groups > Parent Pages > User > Group

[paulhibbitts]

Thanks @mahagr , I think I've got a workable understanding. Thank you again for fixing the bug related to this issue to, I've had no more issues with the test local install using the update Develop branch.

[Sogl]

@paulhibbitts Can I use the same setup for frontend?
I created an issue about this problem: getgrav/grav#3240

[paulhibbitts]

Hi @Sogl , sorry I do not have any experience with front-end page access approaches.

[mahagr]

This one is only for admin.