This would help avoid situations like T106359#1718304.

Upstream changes in https://secure.phabricator.com/D19861 and https://secure.phabricator.com/D19576 mean that account disable/admin changes are now visible on User Profile → Manage, but this only shows status for an individual account.

The global disable list is visible in People → Activity Logs → Edit Query → Actions → Enable/Disable + Add/Remove Administrator, but this isn't public (only administrators have access to it).

Neither currently provide a "reason" field.

We could add a custom field to the user itself to hold the disabled reason, however, it does seem more appropriate to put that info with the log rather than directly on the user profile (and I think only users are allowed to edit their own profile fields, unless they are bot users)

@epriestley: Is this something you might be willing to merge upstream if I were to work on a patch?

I'm theoretically supportive of this but it's not obvious to me how I'd implement it. Did you have a plan in mind?

The approaches that come to mind are:

Comments: Add support for comments to user profiles, then just put a "Comment: [ ]" field in the "Disable" dialog. This is pretty simple and would generally work well, but sort of gives users a permanent set of comments that stick with their account forever, and by default they'll be editable by anyone via the API (leaving a comment requires CAN_INTERACT, not CAN_EDIT, and CAN_INTERACT is just CAN_VIEW for most objects). If someone joins a community when they're like 15 and takes a little while to become mature enough to be a productive contributor, I wouldn't necessarily want to leave a bunch of old negative comments on their profile forever. There's no easy/robust way to make these comments admin-only either, since no other application has rules like that.

It also doesn't tie the comment directly to the action: they'll be next to one another in the transaction log, but directly bound together.

"Disabled Reason" Field: Add a "Disabled Reason" to profiles, then add a "Reason: [ ]" field to the "Disable" dialog which updates it. This solves some of the problems (for example, it's easy to lock non-administrators out of this field in a robust way) but still leaves a lot of chatter on the transaction record, and shows this stuff to everyone, not just administrators. It feels like maybe this stuff should be admin-only, ideally?

Store it on User Logs: This is pretty doable, but I'd mostly like to move away from user logs for administrative actions like "Disable". One concrete issue is that user logs are retained for only 180 days (user.logs in GC), and I think they have to have a retention policy here since they store IP addresses (or maybe that got removed). But it's reasonable to want to know why someone was disabled more than 6 months after they get disabled.

In master, there's now a Feed → Transaction Logs which shows all transactions across all objects and can be filtered by object type:

This is maybe a better tool for looking at this problem in some ways than the existing user logs, although on a real install it's likely to be 95% users editing their own profiles, not administrative actions. We could possibly add filtering by transaction type. But I think I'd like to move toward the existing user activity logs being more like temporary access logs (login attempts, session stuff), and the transaction record being more like a permanent administrative history (disable, make admin, etc).

We could also store reasons as metadata on the transactions themselves, but then rendering becomes pretty messy, and you can't really edit them if you make a mistake.

Another "fix" is just to have a task somewhere called "Grand Administrative Log", visibile to administrators, and have a written human policy that you post an explanation there when you disable someone. This is worse in a lot of ways but solves all the policy/access/clutter/permanence problems? And maybe you just change the disable dialog text to say "Remember to post in Txxx about why you're doing this".

I'm also not sure how the referenced logs work -- are they permanent and fully public? Or only visible to administrators?

These logs should be fully visible to all users (public, if the instance supports that) and impossible to hide.

The most common situations I can think of are offboarding and spam/abuse, both of which do seem like they are fine to make public. And it should really be durable not subject to log retention GC. hmm...

Yeah, spam/abuse are pretty clear-cut (and probably 90%+ of our upstream disables are for those reasons too), but we've also had a nontrivial number of "this guy was kind of a jerk / lawbreaker" cases where I probably wouldn't want the comment public.

For instance, it would be understandably frustrating to a user if Googling for their handle hits me saying "this guy was kind of a jerk" on the first page of results and they don't really have much of a way to fix that. It's not really any different from me tweeting "this guy is a jerk", but it feels more negative/hostile/retaliatory than necessary to me.

There also might conceivably be some right-to-be-forgotten / GDPR issues with EU law, maybe? I'm not entirely convinced that the GDPR has as much technical or legal merit as I'd like (see upstream https://secure.phabricator.com/T13153) so we've been slow to make technical changes purely to comply with the letter of the law, but if you sign up for an account with your real name, then act like a big jerk, then someone publishes that you're a big jerk in the permanent public administrative record attached to your account, I think there might be some amount of ambiguity around data ownership and privacy. In the extreme this could be plain old libel, but, at least in theory, stronger EU privacy laws give more teeth to any argument like this.

We probably have way more of these cases where a comment might be an ongoing problem than most other installs: it doesn't really matter too much for non-public installs; and I don't think anyone is going to start writing "we fired this guy for reason X" here on corporate installs; and we're relatively contributor-hostile and pretty quick to disable users and point them at our community forum if they commit high crimes like asking for a status update on some random feature, while other open source installs tend to be more welcoming.

If there was a public log we could adopt a policy that "ambiguous/critical/maybe-reversible" disables go in a separate private "jerks" log and you say "See Txxx for details about this action.", but then administrators need to make a judgement call about ambiguity / appropriateness.

(As an aside, we have one corporate install with some issues around "alice removed bob from project P" stories, since things are rigged up so that those stories publish incidentally when someone is terminated -- drama! Here, it sounds like WMF basically already has this kind of log elsewhere without any of these social or legal problems, so I wouldn't expect that adding a public "reason" log here would create issues, but I think it's reasonable to be unsure whether that's true everywhere.)

I'm personally not convinced that this is needed.
If really wanted, when disabling Phab user accounts, I'd rather expect Phab admins to be able to amend/overwrite a user profile's description instead of adding another field...

It would at least be better if account disabling is shown in Main Page Activity Feed and Recent Activity of the admin user. It does not provide a reason though.

I am not planning to reopen this task, but note this seems not explicitly declined in the upstream.

What frustrates me is that Phabricator account disable action is not so visible. Adding and removing admin roles to accounts makes public logs to Recent Activity field of both the admin and target (and also global activity feed in Phabricator main page), so I expected there is a parallel when disabling an account. Currently it is only displayed in the disabled user's profile page (not activity feed) and nothing is displayed in the admin's activity feed.

In fact, if the activity feed of PhabBanBot in Phabricator displays a list of users disabled by this account, It may largely replace the phab-ban log maintained in Wikitech (fully replace will require Phab support of a reason field though).

Main Page Activity Feed

I think that is already the case, is it not?

and Recent Activity of the admin user.

What is the use case? Isn't it more relevant in the Recent Activity of the disabled account to find out who disabled an account?

Sorry, I am trying to understand what exactly is requested in this task, in which exact feed/log...

I hope I understood correctly

What I mean is it should be shown in all 3 places: the disabled account, the admin account and main page.