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

Granting access to accounts #56

Open
livfreeorcry opened this issue Mar 15, 2024 · 4 comments
Open

Granting access to accounts #56

livfreeorcry opened this issue Mar 15, 2024 · 4 comments
Labels
feature New feature or request self-hosting Important for folks running independent Ozone instances

Comments

@livfreeorcry
Copy link

Granting access to accounts is (seems to be?) currently done by adding DIDs to a comma-separated environment variable, with no apparent control over privileges, nor any UI visibility.

This process needs improvement, generally. Granted access should be stored in the database rather than in environment variables. Control and visibility through the UI over which accounts have access and what permissions they have would be much more usable than manually editing text files.

@bnewbold
Copy link
Collaborator

Yup!

For what it is worth, there are a couple existing levels of authorization ("triage", "moderator", "admin"). These may not be how we want to categorize permissions going forward though, so these aren't documented/recommended in the setup docs.

We have a batch of work coming down the pipe to implement OAuth, and we might make this more configurable through the interface at that time. I suppose that isn't actually a blocker for adding/removing accounts to the server-side permission list though.

@bnewbold bnewbold added the feature New feature or request label Mar 15, 2024
@baatl
Copy link

baatl commented Mar 24, 2024

Not sure what systems exist for this, but I think Discord's define-your-own-roles ACL approach, with granular permission deny/apply/inherit switches (and per-channel/label visibility/interaction permissions) for a hierarchy of roles, is what I'd aspire to, especially if I wanted moderation for a labeler to, say, be tied to the existing moderation structure of a Discord server.

@baatl
Copy link

baatl commented Mar 24, 2024

And of course, Discord also lets you set these permissions/restrictions on a per-user basis: perhaps roles and permissions could be derived from something that works the same way as account labels, or even (in interaction with) labels themselves?

@baatl
Copy link

baatl commented Mar 28, 2024

To continue about what use cases an ACL solution ought to provide for (I briefly had this on #59 because I read "mod list" and got it mixed up with "access control list"): it should be possible to mark a user / role as having access to only a subset of labels / reports (the categorization of reports itself being a concept that needs revision, per what I was just describing at #77 (comment)).

For one simple example: not all moderators for the Phobia Labeler are interested in handling reports for images with Spiders. Not only should it be possible for non-Arachnophobia moderators to filter out all Spider reports, it should be possible to make it so that users who are not on Arachnophobia Team are not even authorized to apply the arachno label (this would also help with the potential UI bloat described at #77 (comment)).

@bnewbold bnewbold added the self-hosting Important for folks running independent Ozone instances label Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request self-hosting Important for folks running independent Ozone instances
Projects
None yet
Development

No branches or pull requests

3 participants