Implement some way to add users in the ACL selector #951
Assignees
Labels
area:auth
Authentication and Authorization
area:backend
Everything backend related
area:database
The Tobira database
area:frontend
Everything frontend related
Milestone
Comments
LukasKalbertodt
added
area:backend
|
Not sure I understand this or whether I'm supposed to comment, but isn't this a general problem many university systems face, like Moodle not knowing (new) students until they logged in? Maybe there's a way these systems work with this so that we can learn from them. Ignore this if I'm on the wrong track. |
|
Yes you are right, often in these contexts with a central user management system, applications have this problem. So far I haven't seen a clever solution to this in similar apps. Not to be narrow minded, but I don't think there is not a lot of opportunity to have clever ideas about this. This is a fairly straight forward problem. But I could be missing something of course. |
3 tasks
owi92
added a commit
that referenced
this issue
Dec 21, 2023
Fixes #951 (also removing our dummy users from the code, unblocking the release) The main goal of this PR was to make the ACL UI user selection work nicely. I.e. that one can search through users to add user entries to the ACL. Previously we had a bunch of hardcoded dummy users (which also made us unable to release Tobira). This is now done, but lots of related changed had to be done as well. There is also a configuration option which controls whether users can actually be searched by name or whether they can only be found by typing the exact username/email. The latter mode is the default for data privacy reasons. User information is remembered whenever a user logs into Tobira or does anything there. It is also possible to import users from a JSON file. **Important**: this PR introduces a breaking change as it makes a "user role" mandatory for users. See second commit. I doubt this is a problem for anyone, but it's still technically breaking. --- This can probably be reviewed commit by commit. The commit messages should be read for sure. However, the changes to `ui/Access.tsx` are likely very annoying to review because it's also lots of refactoring, over multiple commits. So yeah, not 100% sure how to best approach that. --- Finally, there are a few things that still have to be improved. But not in this PR, it's already large enough. I will create issues for these after merging. - [ ] Potentially add some basic user stats to `/~metrics`, e.g. "active user in last 24h - [ ] Re-add the paste functionality - [ ] Stop sending a list of all known groups to the frontend, that makes stuff slow.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we have a bunch of dummy users you can select. That obviously has to be replaced, but with what? The main problem, as described in #671 is that we don't just have a list of all users. And we can't require our login system to provide that. Further, it is even questionable from a privacy standpoint whether that's ok (though for the ETH it would be fine).
A few ideas:
tobira import-known-usersor something like that where organizations can ingest such a list. That's mostly useful for the beginning period where very few users already logged into Tobira. But it could also be used in a cronjob to push up to date user info.Regarding privacy one could make it so that users have to enter an exact username instead.
The text was updated successfully, but these errors were encountered: