Conversation
There was a problem hiding this comment.
The existing non-API controller uses mark_as_sensitive as the action "type". I wanted the new API to be consistent with the nomenclature of the equivalent Accounts API (which just uses sensitive), so I decided to add another "type" that maps to the same action.
There was a problem hiding this comment.
I wanted the definition of status.reported? to be true even if the Report against the Status has already been resolved.
The Admin Status Policy lets the Admin API "show (GET)" Statuses that would otherwise not be visible to them, if the status is reported.
Since we auto-resolve reports in the bridge, we need reported? to persist as true even after the report is resolved.
I don't think this changes the intention too much, so I think upstream will be ok with this too. If not, it's easy to remove for the PR we do there.
aaga
force-pushed
the
admin-action-statuses
branch
from
5a01a07 to
1266053
Compare
| # frozen_string_literal: true | ||
|
|
||
| class Api::V1::Admin::StatusActionsController < Api::BaseController | ||
| # modeled on api/v1/admin/account_actions_controller.rb |
There was a problem hiding this comment.
I left 3 of these modeled on comments in so that it's clear where some of the new code is descended/remixed from. Happy to remove them before merging.
|
This LGTM, but I would like @wtfluckey to take a look if possible! |
| authorize [:admin, @status], :update? | ||
| representative_account = Account.representative | ||
| ApplicationRecord.transaction do | ||
| UpdateStatusService.new.call(@status, representative_account.id, sensitive: false) if @status.with_media? |
There was a problem hiding this comment.
I'm curious about including if @status.with_media?. I see that's how they are doing it in the approve_appeal_service but I don't really get why. Doesn't this mean that UpdateStatusService won't get called if the status doesn't have media?
There was a problem hiding this comment.
Yeah, it's a bit weird but it does mean that UpdateStatusService won't get called if the status doesn't have media. I left it like this to match the equivalent action – mark_as_sensitive – in status_batch_action.rb, which similarly doesn't call UpdateStatusService with sensitive: true unless there is media.
Since this method is intended to undo moderation decisions, I figured it made sense to mirror the behavior.
Zooming out, I guess the intention is that moderators should only be able to mark visual media as sensitive since it can be jarring/triggering/affective in a user's feed. I'll ask the T&S team if they want to change that policy to allow marking text-only posts as sensitive. Then, we can change both the action and undo action together.
wtfluckey
left a comment
wtfluckey
left a comment
There was a problem hiding this comment.
Took a thorough look at this and I left a couple clarifying questions, but overall this makes a ton of sense to me and matches what was described in the design documents.
|
My face when reviewing ruby code...it never gets old to me how delightful it is.
|
3 participants
Creates three new Admin API endpoints for taking actions on Statuses
/api/v1/admin/statuses/:id(DELETE and GET)/api/v1/admin/statuses/:id/unsensitive(POST)/api/v1/admin/statuses/:id/action(POST)(see design doc below for usage)
One-pager problem statement: https://docs.google.com/document/d/1Vyy6FY7hA8rXyXRmC7D0XxLt71jVHHLQK4UpGLKSosg/edit#heading=h.acfm3nlbz5rz
Tickets:
https://mozilla-hub.atlassian.net/browse/SOCIALPLAT-528
https://mozilla-hub.atlassian.net/browse/SOCIALPLAT-529
Design Doc:
https://docs.google.com/document/d/11p55NqeffaonPrH87cYxpN5iv6ubUK-6C1hzRRVRRXU/edit
Note that I changed the design doc slightly from what was previously approved (see 1, 2, and 3)
This needs to be merged and tested on staging, at which point we can change the mastodon-cinder bridge to use the new endpoints.