Admin account state endpoints #1725
Conversation
| "did": { "type": "string", "format": "did" }, | ||
| "uri": { "type": "string", "format": "at-uri" }, | ||
| "blob": { "type": "string", "format": "cid" } |
There was a problem hiding this comment.
If you want the status for a blob do you end-up passing (did, blob)?
There was a problem hiding this comment.
yeah that's what i was thinking
| // if less than admin access then cannot perform a takedown | ||
| if (!access.moderator) { | ||
| throw new AuthRequiredError( | ||
| 'Must be a full moderator to update subject state', | ||
| ) | ||
| } |
There was a problem hiding this comment.
There's no update happening here, so I think we can safely skip this check.
| @@ -0,0 +1,39 @@ | |||
| { | |||
| "lexicon": 1, | |||
| "id": "com.atproto.admin.getSubjectState", | |||
There was a problem hiding this comment.
Do you envision having a separate endpoint for getting the subject state specific to a particular service? Or beyond that, fetching the subject state for multiple services at once?
There was a problem hiding this comment.
yeah - i view this as just being "what is this particular service's state for this subject?" then the moderation service could have some higher-level end points for collating state from across services
| auth: ctx.roleVerifier, | ||
| handler: async ({ input, auth }) => { | ||
| const access = auth.credentials | ||
| // if less than admin access then cannot perform a takedown |
There was a problem hiding this comment.
This comment might be out-of-date since this check below permits non-admin moderators. Or maybe we need a more stringent check within the if (takedown) {} block below.
There was a problem hiding this comment.
ah good call 👍
i updated the error text but not the comment
| @@ -0,0 +1,39 @@ | |||
| { | |||
| "lexicon": 1, | |||
| "id": "com.atproto.admin.getSubjectState", | |||
There was a problem hiding this comment.
I see what you mean about naming being hard here—"subject state" is a little loaded. Some other ideas to replace: "state": flags, statuses, notices, advisories.
There was a problem hiding this comment.
as we discussed, i think "status" might work well & syncs up nicely with foysals work
| @@ -7,7 +7,7 @@ export interface Record { | |||
| rkey: string | |||
| repoRev: string | null | |||
| indexedAt: string | |||
| takedownId: number | null | |||
| takedownId: string | null | |||
There was a problem hiding this comment.
I have a feeling you're already on it, but just a note to ensure we don't forget the db migration path for these.
| @@ -2,6 +2,14 @@ | |||
| "lexicon": 1, | |||
| "id": "com.atproto.admin.defs", | |||
| "defs": { | |||
| "statusAttr": { | |||
There was a problem hiding this comment.
Swapped out "state" for "status" (inspired by Foysal's PR #1617)
As well, differentiated between the names of these two:
"status attribute": an individual attribute of a subject's status. For instance, it's current takedown status
"status": all attributes of a subject's status
|
Closing because this is all contained in in #1723 |
Some simple routes for toggling various subject status attributes.
This only includes the
takedownattribute, but the basic idea is that other types of state (such as ability to login, mutate, download repo, etc) can included in a similar manner.I also made only one route for every type of subject (repo, record, blob) and unbundled record & blob takedowns.
There's also a bit of a weird implementation detail where we translate between the lexicon represenation of state (boolean & optional ref) and our current database schema (arbitrary string where presence means the takedown is applied). We can clean this up in pds v2
Precursor to #1723 & we'll probably merge/deploy both together. Just kept as a separate PR for ease of review