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
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.
Right now the API supports adding mod only user flairs through the
PUT /v1/communityendpoint. This happens by setting themod_onlyfield totruewhen adding a flair to a community.These flairs then get displayed, along the non mod only flairs, when calling the
GET /v1/communityendpoint and specifyingmod_only=trueas a query. However, further support is required.Only mods should be able to view mod only flairs
The
get_community_flairs_apihandler should look for an optionalAuthorizationheader, 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 existingverify.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_apihandler 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.