For reference, see how this is handled in action=history: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Event:Suppress-test&action=history

Just to make it clear, this is not actionable for engineers because we need to know how it should look like. @gonyeahialam Do you have any thoughts about this?

@Daimona @ifried What does it mean for a user to be suppressed? What actions lead to it and what are the consequences of being suppressed as a user on wiki and as an event organizer?

In T316294#8198827, @gonyeahialam wrote:

@Daimona @ifried What does it mean for a user to be suppressed? What actions lead to it and what are the consequences of being suppressed as a user on wiki and as an event organizer?

See https://www.mediawiki.org/wiki/Help:Blocking_users, search "Hide username from edits and lists"; and https://meta.wikimedia.org/wiki/Oversight_policy for Wikimedia-specific policies. I'm not sure if there are other, more specific help pages.

In T316294#8199022, @Daimona wrote:

In T316294#8198827, @gonyeahialam wrote:

@Daimona @ifried What does it mean for a user to be suppressed? What actions lead to it and what are the consequences of being suppressed as a user on wiki and as an event organizer?

See https://www.mediawiki.org/wiki/Help:Blocking_users, search "Hide username from edits and lists"; and https://meta.wikimedia.org/wiki/Oversight_policy for Wikimedia-specific policies. I'm not sure if there are other, more specific help pages.

To suppress users on this extension though @gonyeahialam , User:Block does not work though because it only works for local users, but to actually block and suppress a user from appearing globally (and to create the scenario shown in the description of this ticket), we need to use Special:CentralAuth and suppress through that. See https://www.mediawiki.org/wiki/Extension:CentralAuth#Locking_and_hiding_global_users and you can read T312772#8162643 for more (likely confusing) information about this

I am not sure what actions would lead to a user being added to Special:Block vs a total suppression of the user though.

@Daimona @vaughnwalters @ifried From what I have read so far, wouldn't it mean an event will no longer continue if the organizer is suppressed or deleted?

@gonyeahialam This is for the use case of an organizer being suppressed after they created the event and enabled registration. It is up to the admin (not our system or tools) to decide whether the event page is deleted and/or event registration is disabled. For this reason, we need to know how to display the information.

Also, we are allowing multiple organizers to be associated with an event for V1. So just because one organizer is suppressed does not mean other organizers are suppressed.

@vyuen: What exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on")?

In T316294#8199454, @ifried wrote:

@gonyeahialam This is for the use case of an organizer being suppressed after they created the event and enabled registration. It is up to the admin (not our system or tools) to decide whether the event page is deleted and/or event registration is disabled. For this reason, we need to know how to display the information.

Also, we are allowing multiple organizers to be associated with an event for V1. So just because one organizer is suppressed does not mean other organizers are suppressed.

I second this. I already posted this above, but since it might be hidden in all the messages above, I'm posting it again: this is how it's handled in history pages. The result is the same as that of revision deletion. We don't have to implement it in the same way (I'm not even sure if those styles are reusable outside of action=history), but I guess we should at least try and remain consistent.

My vote is to keep the same presentation we see in the revision history example because 1) we can maintain consistency, and 2) i find the current way it is represented to be clear to me as a user. @gonyeahialam we will need your input as well. Thanks!

We can go ahead with using the revision history example Username or IP removed . We could look to improve it in the future if necessary

In T316294#8208638, @ifried wrote:

@Daimona and @vyuen: Hello! A decision has been made on this ticket from a product/UX perspective. I'm happy to assist with next steps -- let us know how it can be converted for a ticket for estimation or being added to the sprint board. Thanks!

I think could mostly already be estimated, the only thing I would like is a visual reference of how it would look like. In MediaWiki a single line through means deleted, two lines means suppressed. Then, for normal deletion the text color becomes base30 (#72777d). For both deletion and suppression, the text is also italicized. I guess my question is what visual cues we want to have.

@Daimona I think it makes sense to follow the existing Mediawiki behavior, which you have outlined. Is there any reason why we would not?

In T316294#8209315, @ifried wrote:

@Daimona I think it makes sense to follow the existing Mediawiki behavior, which you have outlined. Is there any reason why we would not?

I was just saying that there's no single MW behaviour, because it depends on which page you are, and whether the entry is deleted or suppressed. I'm also not sure if that logic can be reused, at least it would be semantically wrong because it's made specifically for history/log pages.

Personally, I think the line through is unnecessary, so we could have something like this:

I also want to confirm what should happen if there are more than one organizers, and at least one of them is NOT hidden. I'm thinking in that case we would simply display the visible names, and show "username removed" iff all organizers were suppressed.

Thanks for the response, @Daimona!

1. I agree that the strike-through is unnecessary. I don't think we need it. The visual example you provided looks good to me.
2. If we have more than one organizer, I wonder if it is still useful to display the 'username removed' because:
   • If we hide the username in one scenario and display it another scenario, it is an inconsistent user experience.
   • Perhaps it is a good idea for participants to know that one of the usernames was removed? This way, they can be more informed on the history of the event, in case there are potential Trust & Safety issues.

Curious to get the thoughts of @Sadads and @IBrazal on this one. Thanks in advance!

In T316294#8212295, @ifried wrote:

Thanks for the response, @Daimona!

1. I agree that the strike-through is unnecessary. I don't think we need it. The visual example you provided looks good to me.
2. If we have more than one organizer, I wonder if it is still useful to display the 'username removed' because:
   • If we hide the username in one scenario and display it another scenario, it is an inconsistent user experience.
   • Perhaps it is a good idea for participants to know that one of the usernames was removed? This way, they can be more informed on the history of the event, in case there are potential Trust & Safety issues.

Curious to get the thoughts of @Sadads and @IBrazal on this one. Thanks in advance!

Hi @ifried, I'm not really sure how suppression works. But if it means the same as the user will no longer be allowed to edit globally, then it also means that the account should not be allowed to create an event page or event registration. In the event that blocking was done after creating the registration, it should mean for us that the Event Registration should be closed or soft-deleted (automatically), for safety reasons. However, if the event registration should still need to be viewable by public I suggest:

• for 1 organizer, to retain the name of the Organizer (as plain text, and unlinked) , and make the page unavailable to the public later
• for two or more organizer: Username and 1 other, where 1 other is the blocked username.
• for the page history, we can just let how the MW behaves for this action

Personally, if the event has multiple organizer, I prefer showing Username unavailable than Username removed as it will create a negative impact to the credibility of the event. If it has been decided that only 1 organizer deserves suppression, we should try to limit the effect it will have to the other organizer or the event in general. We need to think of another way to warn future participants of any potential Trust & Safety issues.

Update: we are discussing this topic in the engineering + design meeting, and some things we discussed are:

• If there is only 1 organizer per event and that organizer username is suppressed, should we have an automatic disabling of event registration for those events?
  • One point to consider is that this is an edge case to have an organizer with a suppressed username, so perhaps we should aim for simpler workflows at first?

Decision: Since we want the same behavior for both events that have multiple organizers and 1 organizer, and we want an easy solution for V1 because this is an edge case scenario, let's display the words 'Username removed' in the italic styling as displayed in the comment above for all scenarios when this occurs. Meanwhile, we can explore automatically disabling registration if there is only organizer and their username is suppressed (ticket created for this work: T317197), but this is currently low priority since we see this as a rather rare edge case at this point.

+1 to all of what Imelda hightlights-- we could also leave a reference/link to the blocking/supressing log in the description of the Username removed for future investigators.

Change 831623 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Show placeholder text for hidden organizer usernames on event page

https://gerrit.wikimedia.org/r/831623

Change 831623 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Show placeholder text for hidden organizer usernames on event page

https://gerrit.wikimedia.org/r/831623

Suppress-test event is now displaying the suppressed name correctly:

I created a new event and suppressed that user through Special:CentralAuth as well and that is also displaying correctly
https://en.wikipedia.beta.wmflabs.org/wiki/Event:V-suppress-test-3
user:V-suppress-test-3

@Daimona This is issue is fixed for suppressed users but the problem persists when the organizer is deleted (also using Special:CentralAuth). See Event:V-suppress-test-4 where user V-suppress-test-4 enabled the registration and then that account was deleted by a steward:

In T316294#8246824, @vaughnwalters wrote:

@Daimona This is issue is fixed for suppressed users but the problem persists when the organizer is deleted (also using Special:CentralAuth). See Event:V-suppress-test-4 where user V-suppress-test-4 enabled the registration and then that account was deleted by a steward:

Oh, you mean when actually deleting the global account? If so, that is indeed true. I've created T318125 as a follow-up, probably lower priority. I've also created T318124 as a related follow-up.

Yes, I meant deleting the global account with Special:CentralAuth. Since you created that follow up ticket, I will move this to design sign off. Also, good idea on showing deleted/suppressed names to stewards 👍 .

In T316294#8246889, @Daimona wrote:

In T316294#8246824, @vaughnwalters wrote:

@Daimona This is issue is fixed for suppressed users but the problem persists when the organizer is deleted (also using Special:CentralAuth). See Event:V-suppress-test-4 where user V-suppress-test-4 enabled the registration and then that account was deleted by a steward:

Oh, you mean when actually deleting the global account? If so, that is indeed true. I've created T318125 as a follow-up, probably lower priority. I've also created T318124 as a related follow-up.

T318125 has now fixed the issue of what to display when an organizer is deleted by a steward.

Also note that the language has now been changed in T318450 to say Username suppressed instead of Username removed.

Hey there, @vaughnwalters and @Daimona! I just tried to test this by looking at the following events:

• https://en.wikipedia.beta.wmflabs.org/wiki/Event:V-suppress-test-3
• https://en.wikipedia.beta.wmflabs.org/wiki/Event:V-suppress-test-4

And I got this:

Is there another example that is better for testing or a reason why it's currently displaying the way it is?

In T316294#8312942, @ifried wrote:

Hey there, @vaughnwalters and @Daimona! I just tried to test this by looking at the following events:

• https://en.wikipedia.beta.wmflabs.org/wiki/Event:V-suppress-test-3
• https://en.wikipedia.beta.wmflabs.org/wiki/Event:V-suppress-test-4

And I got this:

Is there another example that is better for testing or a reason why it's currently displaying the way it is?

@ifried That bug was introduced earlier this week, but there's already a patch for review to fix that right now at T290248#8308512 - once that is merged in then the more details modal will be displaying the organizer correctly again (including for suppressed or deleted organizers)

For now, the other place you can test it is to look under organizers on Event Details:
suppressed organizer example here
and deleted organizer example here

Thank you, @vaughnwalters!

This looks good in EventDetails (as shown in the links you shared), and I'll mark this as Done when the fix is ready for testing in the 'more details' modal.

In T316294#8314371, @ifried wrote:

Thank you, @vaughnwalters!

This looks good in EventDetails (as shown in the links you shared), and I'll mark this as Done when the fix is ready for testing in the 'more details' modal.

@ifried The patch was merged, and this is now working correctly on beta.