Open livfreeorcry opened 7 months ago
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.
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.
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?
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 https://github.com/bluesky-social/ozone/issues/77#issuecomment-2024671558).
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 https://github.com/bluesky-social/ozone/issues/77#issuecomment-2024694860).
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.