Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design UI to modify/set ACLs of events/series #671

Closed
LukasKalbertodt opened this issue Jan 19, 2023 · 1 comment
Closed

Design UI to modify/set ACLs of events/series #671

LukasKalbertodt opened this issue Jan 19, 2023 · 1 comment
Assignees
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

Comments

@LukasKalbertodt
Copy link
Member

LukasKalbertodt commented Jan 19, 2023

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

  • Do we want to add some kind of note that if a video is unlisted, the direct link is basically like password protected bc ID is unguessable?

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.

@LukasKalbertodt LukasKalbertodt added area:frontend Everything frontend related kind:new-feature A new feature area:design Issues specifically about the broader design of the site area:usability Usability related issues labels Jan 19, 2023
@LukasKalbertodt LukasKalbertodt moved this to Todo in Tobira Jan 19, 2023
@owi92 owi92 self-assigned this Jul 7, 2023
@LukasKalbertodt LukasKalbertodt moved this from Todo to In Progress ⏳ in Tobira Aug 3, 2023
@LukasKalbertodt LukasKalbertodt moved this from In Progress ⏳ to In Review 👀 in Tobira Sep 26, 2023
@LukasKalbertodt
Copy link
Member Author

This is mostly done in #911 / #947. Two remaining sub issues were split off: #951 #952

@github-project-automation github-project-automation bot moved this from In Review 👀 to Done ✔️ in Tobira Sep 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
Status: Done ✔️
Development

No branches or pull requests

2 participants