Enonic version: 6.12.2
OS: Windows 10
What I tried to do, that caused this dive into the depths:
This role doesn’t affect admin tool visibility at all, only system.admin sees it.
After trying to figure out why this doesn’t work I ended up inspecting the roles in the repo browser:
I am trying to create a new role, but my admin tool doesn’t seem to become available for users with that role. Is there a bug with creating new roles in the Users app, that is bundled with XP?
While trying to figure out why the user didn’t get access I dug into the roles in the system-repo, and my new role doesn’t seem to consist of the same data schema as other, functioning, roles in the system-repo.
My goal was to define a new role that is referenced in my admin tool as an principal. Does the text you specify in the allow part need to match the _id-property of the role in the repo? With the latest version of the Users app, all the roles I create are assigned a random _id, but all our other older roles have f.ex. “role:system.admin” as _id. The new role seems to have a field called “key” instead.
Examples from the repo-browser while trying to debug this issue:
An old role I created a while back:
The new role I just created:
The new role doesn’t seem to work when I try to add users to my admin tool. I see that a few things where changed with the Users app in late Oct., that changed a few things around _id and “key” field amongst other changes: Replace node layer with `lib-auth` calls for Roles and UserStores #82 · enonic/xp-apps@a8f2241 · GitHub
Is it possible that this commit created a bug, so with the code that tries to map principals from admin tools into roles?
This was a lot of data in one rant, if you need more info to examine this closer, please ask