Have edited the page title for the individual post to be:

I do note that currently the account status page does allow viewing private or follower-only posts, however, you must know the status ID, which would require database access most likely.

We should probably add some sort of audited roadblock for private or follower-only statuses, which logs that the moderator has viewed that non-public status. So you try visiting a post that is private or follower-only, and you get a message that says "Hey, this is a private or followers-only post, if you want to view this, then this will be recorded in the audit log: [continue] [back]"

I'm currently expecting bundle exec i18n-tasks check-consistent-interpolations in Check i18n to fail, given ec212c9

I'm not sure I should edit all the translations and just add - @${name}, since I don't know these languages, however, that would be the same as how it previously displayed.

Have just added a label for "in reply to" to make it slightly easier to follow threads from admin account statuses.

(And yes, I'm surprised I can view a remote status that my local server knows about through this UI, that wasn't completely intuitive to me)

All in all, I think these changes make total sense.

I do note that currently the account status page does allow viewing private or follower-only posts, however, you must know the status ID, which would require database access most likely.

Does not the authorize [:admin, @status], :show? in the controller's #show action take care of that? The checks in Admin::StatusPolicy#show? look pretty comprehensive to me. And they should prevent someone from accessing a random private status afaict.

I'm not sure I should edit all the translations and just add - @${name}, since I don't know these languages, however, that would be the same as how it previously displayed.

I think you should. As you point out, this should not lead to any visible changes.

@oneiros I think maybe I've been tripped up by viewable_through_normal_policy?, since I'm usually only testing through a handful of accounts.

i do think we probably want some audit logging that does allow access to DMs and followers-only posts (sure, an admin can see it in the database, so I don't think this changes scope necessarily), but rather gives admins the ability to see just metadata about non-public content on their server, with an audit log (and maybe a notification to the user) of this access.

But that's likely to be a later feature proposal.

I'm not sure I should edit all the translations and just add - @${name}, since I don't know these languages, however, that would be the same as how it previously displayed.

I think you should. As you point out, this should not lead to any visible changes.

@oneiros it does not in English & flags as localisation changed, so should raise to i18n volunteers to review? I suspect they may format it differently based on their locale

But that's likely to be a later feature proposal.

I really like the idea but agree that it should be out of scope for this PR.

it does not in English & flags as localisation changed, so should raise to i18n volunteers to review? I suspect they may format it differently based on their locale

This is exactly what I would expect. But I have to admit I am not yet fully familiar with the whole i18n process.

This pull request has merge conflicts that must be resolved before it can be merged.

This pull request has resolved merge conflicts and is ready for review.

Have finally rebased this pull request.

In viewing a single status:

When viewing the full statuses for an account:

When report_id parameter is set ("report" button changes to "add to report #number":

Here's it in the report details page's reported statuses table:

Note: for the report details page, I have other changes to improve that in the work I've done in #31444

I did actually just do a test to see how much work it'd be to create a reusable partial for status display based on either the statuses/show or reports/_status partials, and it's pretty simple to take those and make them work on any status we want to display in the moderation UI / Appeals UI (though appeals definitely needs a redesign if we're to display proper statuses there)

Here's what a hacked version of that looks like

Old:

New:

Looks like out-of-band hashtags don't quite look the same as in the web UI, but it's still understandable and content isn't "missing". I'm not sure how this would handle for the case where the post text doesn't contain the hashtags but the hashtags are present on the post?

I'm not sure how this would handle for the case where the post text doesn't contain the hashtags but the hashtags are present on the post?

I don't understand what you mean, that's the definition of out-of-band hashtags, isn't it? Quickly skimming through the code, I don't see any place where we deal with them, which is an issue, but not a new one.

I'm not sure how this would handle for the case where the post text doesn't contain the hashtags but the hashtags are present on the post?

I don't understand what you mean, that's the definition of out-of-band hashtags, isn't it? Quickly skimming through the code, I don't see any place where we deal with them, which is an issue, but not a new one.

@ClearlyClaire yes, existing issues, and something I forgot about when writing this PR, same with generating the in reply to links: there were cases where the status said it was a reply but I didn't have that post so had to fallback on not showing the in reply to banner.

I think we'll want a follow up issue for out-of-band hashtags for moderation UI. Also for creating a reusable partial to share across many features