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

Add support for mod only flairs #3

Open
2 tasks
ornato-t opened this issue Oct 6, 2023 · 0 comments
Open
2 tasks

Add support for mod only flairs #3

ornato-t opened this issue Oct 6, 2023 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@ornato-t
Copy link
Contributor

ornato-t commented Oct 6, 2023

Right now the API supports adding mod only user flairs through the PUT /v1/community endpoint. This happens by setting the mod_only field to true when adding a flair to a community.

interface AddFlairJson { 
    name: string, 
    display_name: string, 
    path: string | null, 
    community_actor_id: string, 
    mod_only: boolean 
}

These flairs then get displayed, along the non mod only flairs, when calling the GET /v1/community endpoint and specifying mod_only=true as a query. However, further support is required.

  • Only mods should be able to view mod only flairs
  • Only mods should be able to assign mod only user flairs, either to themselves or to others

Only mods should be able to view mod only flairs

The get_community_flairs_api handler should look for an optional Authorization header, which would work similarly to the existing ones already set up for PUT and DELETE requests. If such a header is included, and if the resulting user is a mod (this can be checked with the already existing verify.rs/verify_mod function), then the list should return mod only flairs, otherwise it should return either a list of regular flairs or an "Unauthorized" error.

Only mods should be able to assign mod only user flairs

The put_user_flair_api handler already verifies the user's JWT. However, insertions of mod only flairs should only happen if the owner of the JWT is a mod.
The challenge here is to avoid calling the verify.rs functions more than once, as they rely on the Lemmy API and are thus pretty slow. This will likely require a major rewrite of the handler.

@ornato-t ornato-t added the enhancement New feature or request label Oct 6, 2023
@ornato-t ornato-t pinned this issue Oct 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants