Seperate user and non-user roles #1006
Conversation
Changes the access policy tab of various details modals. User roles get displayed in a seperate table from the other roles, with user name and email. This should make it more intuitive to "give someone access to a video/ series". Functionality should not change, the resulting ACLs will look the same as before. Caveat 1: If roles are sanitized, we cannot reliably derive the user from their user role. Therefore, this feature will be disabled if user role sanitization is enabled in Opencast. Caveat 2: I did not find a performant way to query for user information for each and every user. Therefore, if there are upwards of multiple thousands of users, the access policy tab will take several seconds to load.
|
Use Run test server using develop.opencast.org as backend: Specify a different backend like stable.opencast.org: It may take a few seconds for the interface to spin up. |
|
This pull request is deployed at test.admin-interface.opencast.org/1006/2025-03-20_13-33-48/ . |
|
This pull request has conflicts ☹ |
|
I have tested this PR together with opencast/opencast#6382 and have a few remarks.
|
|
Thanks for testing, will look into these issues! |
The options in the dropdown for selecting a user in the access policy tab would show the user role (aka the thing actually being selected) instead of the user information like in the input field. This fixes that. Also adds some sensible fallbacks in case someone decides to have users without names.
Add support for the access roles ROLE_UI_EVENTS_DETAILS_ACL_USER_ROLES_VIEW ROLE_UI_EVENTS_DETAILS_ACL_NONUSER_ROLES_VIEW ROLE_UI_SERIES_DETAILS_ACL_USER_ROLES_VIEW ROLE_UI_SERIES_DETAILS_ACL_NONUSER_ROLES_VIEW
|
Both issues should now be fixed. |
|
This pull request has conflicts ☹ |
|
Should an event with ROLE_USER_x be visible to user x? I would, perhaps naively, assume that if I give a user read and/or write that they'd be able to see it in the admin UI... Otherwise works correctly. |
|
Could you specify what exactly is different from how you expect it? Which combination of role and actions does not do what you would think it do? |
|
Thanks @Arnei for addressing my comments.
|
To make sure I understand you correctly: If the user does not have any of the roles mentioned above, the "Access Policy" tab should not be displayed at all. For example in your screenshot, the user would go from "Processing" straight to "Summary". Is that right? What roles should the event have in that case? I would be tempted to leave fixing that to a different PR, since for me this raises questions about what the role |
Yes, the user would go from "Processing" straight to "Summary". In our case we have the ACL merge mode "actions" active, this means the roles for the series are valid for such an event (and the series is mandatory for each event).
Personally, I see the purpose of the different roles as follows:
For us, the split view for ACLs only makes sense if we can hide the non-user roles part in both the create and edit dialog. So I'd prefer to have the ACL view roles issue fixed in this PR. But if it is much easier for you to address this in another PR, then go ahead. |
This should make the search for searchable dropdowns work as expected, meaning the search string is now matched correctly against the existing labels. The custom filtering this patch removes only serves to break the search, and what it tries to achieve the 'react-select' search already does out of the box.
In the create event modal, do not display the step "Access policy" if the user is missing the role "ROLE_UI_EVENTS_DETAILS_ACL_VIEW". The step gets completely skipped. Per default, this results in an ACL with read/write access for the user.
|
Thanks for the very detailed explanation on the roles, that helped me a lot. I made a change so that the user requires the role "ROLE_UI_EVENTS_DETAILS_ACL_VIEW" to see the "Access Policy" step in the "Create Event" modal. This should work the default merge mode as well, and result in the other roles working as intended. Please test again.
Searching should now work as intended. |
|
This pull request has conflicts ☹ |
|
This pull request has conflicts ☹ |
There was a problem hiding this comment.
My only concern was addressed. I talked to @snoesberger today and he would like to test this PR again.
From the code perspective, I have nothing to complain about.
Thanks for the detailed explanation. The actual behavior is fine for me.
Thanks for this fix. I can confirm that a normal user can now create new series without the Tobira roles. But I found another issue that used to be fine: In the dropdown to select user roles, only the role id/name is displayed and I can also select non-user roles: And in the non-user section I have also user roles available to choose from. |
|
...looks like I muddled something up when resolving the latest merge conflicts. Thanks for reporting that! |
The dropdowns for user roles and non-user roles were not filtered anymore, you could select whatever role in either. Also user roles were not rendered nicely anymore. This was due to a mistake when resolving merge conflicts in the previous commit.
|
I retested @Arnei's last commit and the dropdown provides now correctly only user roles in the user role section and non-user roles in the non-user roles section again. The user names are also nicely rendered again. Thanks for fixing that! During my testing I found another small issue. In the "Access Policy" step of the create event/series dialogue, the user role is first displayed in the non-user section: Only after choosing a template the user role is correctly displayed in the user section. |
When creating a new event or series, the role of the current user is automatically added to the ACL. It was however displayed as a non-user role. This patch fixes that.
|
Thanks for catching that. The user role that is automatically added to the ACL for events and series should now be displayed as a user role once again.
|
It was causing CSS issues that were non-trivial to fix and at the very least would have required importing more additional dependencies to completely reprogram something that *should* work out of the box. We can and probably should revisit ways to increase performance in the future, but for now this is not the way.
|
This pull request has conflicts ☹ |
|
This pull request has conflicts ☹ |
|
This pull request has conflicts ☹ |
|
I did a second look at the code, because there were changes since last time. But I still have nothing to complain about. As far as I'm concerned, the PR can go out like this, provided the backend PR has been completed: opencast/opencast#6382. |
Thanks, I can confirm that this working now as expected. |
Fixes #905, #561.
Changes the access policy tab of various details modals. User roles get displayed in a seperate table from the other roles, with user name and email. This should make it more intuitive to "give someone access to a video/ series". Functionality should not change, the resulting ACLs will look the same as before.
Caveat 1: If roles are sanitized, we cannot reliably derive the user from their user role. Therefore, this feature will be disabled if user role sanitization is enabled in Opencast. (The old admin ui allowed for sanitized roles and did some best effort guesswork to derive users from roles. Even though that approach worked for many, I'd rather not reintroduce such brittle code here.)
Caveat 2: I did not find a performant way to query for user information for each and every user. Therefore, if there are upwards of multiple thousands of users, the access policy tab will take several seconds to load.
Requires backend changes. Will break the UI otherwise. opencast/opencast#6382
How to test this patch
As this requires backend changes, the automatically generated stuff from github-actions below will not work.
Install the backend PR in your Opencast. Run this PR against your Opencast, like so
PROXY_TARGET=http://localhost:8080 npm start. Thesanitizeflag can be found in your Opencast configuration files inetc/org.opencastproject.userdirectory.UserIdRoleProvider.cfg.Screenshots:
