[suggestion] roles (moderator & uploader)

[ldpr]

(sorry, i had an issue open for this before but couldn't find it, my apologies if it exists elsewhere, i might just be blind)

1. It would be great if we could hard-limit who can upload torrents to only uploaders/moderators/admins.

2. Currently, only the uploader can edit torrents they upload. if we could have a secondary group under admin that's able to edit/delete any/all torrents it'd be a great QOL improvement.

Further, allowing admin to edit all torrents would be nice too.

[da2ce7]

(from @WarmBeer)

We need a way to set up roles and permissions for users so that administrators have more control of their user base.

Example workflow:

1. Administrator opens the settings page and clicks on NEW ROLE

The administrator will then be presented with a form where they can configure the newly created role.

Role configuration options could include:

• Role name
• Role color
• Assign (MANUALLY, ON ACCOUNT CREATION, ON ACCOUNT VERIFICATION)
• View permission for a specific category (one, multiple or all)
• Upload permission for a specific category (one, multiple or all)
• Moderator permission for a specific category (one, multiple or all)

2. Administrator clicks save role.

The role is now available to assign to users.

3. Administrator opens the users page.

The administrator will then be presented with a list of all the users. From here, the administrator can assign one or multiple roles to a user.

Example roles:

ADMINISTRATOR:
This role should exist by default and will be automatically given to the first created user. This role will then replace the administrator flag in the database.

---

UNVERIFIED:

• Assign: ON ACCOUNT CREATION
• View Permission: ALL

This role will be able to view and download every available torrent, but won't be able to upload anything. This role will be automatically given to new users.

---

VERIFIED:

• Assign: ACCOUNT VERIFICATION
• View Permission: ALL
• Upload Permission: MOVIES, TV SHOWS, GAMES

This role is automatically assigned to users that verify their account. They will be able to view all categories and be able to upload to the categories: MOVIES, TV SHOWS and GAMES.

---

MODERATOR:

• Assign: MANUALLY
• View Permission: ALL
• Upload Permission: ALL
• Moderator Permission: ALL

[da2ce7]

(from @josecelano)

I've created the summary below with the current state. I think it's useful to define first what we have before proposing new changes.

I called the "UNVERIFIED" user "AUTHENTICATED" and there is no "MODERATOR".

For the first implementation I would:

• Create a permissions service only for commands and queries: service.is_authorized(user, action).
• Call the service in the handlers before performing the action.
• We can add a wrapper to return the right HTTP response.
• Can add unit tests for the service and integration tests for the API endpoints.

IMPLEMENTATION NOTES:

• Roles could be hardcoded.
• Rules could also be hardcoded for the time being inside the service.

NOTES:

• Regarding settings I would split them into two groups: the ones you only set while installing the application (they could be injected as env vars in the future), and the ones you can change dynamically like the "site name". I would move the second group to a database table. If you need to restart the service after changing the value it does not make sense to allow you to change it from the web app.
• API resources do not contain any sensitive data except for "username" and "settings" so I do not think it worth creating specific resources depending on the role. It seems the general rule is either you can see the full resource or you cannot see the resource.

QUESTIONS:

• The "username" is not considered private data.