Design UI to modify/set ACLs of events/series #671
Labels
area:design
Issues specifically about the broader design of the site
area:frontend
Everything frontend related
area:usability
Usability related issues
kind:new-feature
A new feature
For #356 and #369 (and possibly for fine grained realm access) we need some UI to select/modify ACLs. Opencast's admin UI of course has such an UI already but that is not optimal for various reasons. Multiple organizations have patched it to improve upon it, but no design made it back into the community. Further, Tobira is more geared towards normal users while the admin UI should be only for "administrators".
So: we want a better design for Tobira, optimizing UX.
Ideally the editor should have the same power as the admin UI editor, i.e. any ACLs you can create via admin UI you should be able to create via our editor. But common use cases should be very easy. And it should be hard to misunderstand or screw up. So we likely want some form of "template" or "main options" like "public", "organization internal", "private".
It should also be easy to give access to individual users. It's not necessarily trivial to implement that, i.e. to make all users searchable in such a UI. Our login black box currently does not provide us with that information. And lots of login systems cannot even provide that information. For example AAI does not allow getting a list of all users. So two options basically:
Tobira can just remember all users that ever logged in and make them available. Obvious disadvantage: users need to have logged into Tobira at least once to be findable in this UI. (Note from Olaf some time: this is quite common in many systems and wouldn't be such a big deal)
OR: Tobira just requires the "give me all users" feature from the login provider. But this would complicate the login system and providers for AAI would still need to do the "remember all users that logged in" trick, as their backend (AAI) do not support this kind of query.
The first option is probably easier for us, as otherwise the login provider for ETH grows quite complex and needs its own database.
It is not yet required to give access to any kinds of "groups", but this should still be considered in the initial design.
Open questions
Some other notes
The "template" feature in the admin UI is bad: it's a drop down and when choosing one template, it stays on that template, even after manually editing roles. This implies that the chosen template is somehow stored. But it's not. It's a one time frontend thing of "set the liste of roles to this pre-defined list". We likely want templates in Tobira as well, but we should do a better job of explaining (through UI) what it does. And also that it will overwrite the existing ACL config.
One alternative approach would be to just have two sections of "users to give access" and "user groups to give access". And then we would have a nice label for a number of roles, e.g. "everyone" for
ROLE_ANONYMOUS
. Then users are just tasked to choose which user groups to give access to. We could also, if we have some kind of "superset" relationship information about roles, "lint" roles that are a subset of an already listed role. Add a little warning/note or something.The text was updated successfully, but these errors were encountered: