This could be way harder than it sounds, basically boiling down to the question of how to detect a test event in a robust way (that doesn't depend on language or project conventions). It could maybe be generalized to a new status (in addition to "open" and "closed") which, when set, has the effect of excluding an event from AllEvents and similar lists.

@Daimona Thanks for providing this feedback! This is helpful. Can you explain a bit more about how the new status could work? I'm a bit confused by this. Thanks!

In T364353#9779353, @ifried wrote:

@Daimona Thanks for providing this feedback! This is helpful. Can you explain a bit more about how the new status could work? I'm a bit confused by this. Thanks!

In addition to "open" and "closed", you would have a third status (maybe "draft"? Unsure if we should add a "test" status for this) that works exactly the same as "open", but prevents the event from being listed in AllEvents.

I'm not saying this is the best solution, there are surely other options. But the point is, we need a project- and language-independent way of identifying test events.

In T364353#9779409, @Daimona wrote:

In T364353#9779353, @ifried wrote:

@Daimona Thanks for providing this feedback! This is helpful. Can you explain a bit more about how the new status could work? I'm a bit confused by this. Thanks!

In addition to "open" and "closed", you would have a third status (maybe "draft"? Unsure if we should add a "test" status for this) that works exactly the same as "open", but prevents the event from being listed in AllEvents.

I'm not saying this is the best solution, there are surely other options. But the point is, we need a project- and language-independent way of identifying test events.

@Daimona, @ifried, Not sure if a status is a good way to go with it, I mean if we do that, we will need to block the test events from changing its status from open to close or close to open, because if not the organizer of a sandbox event could still change it, making it to display on Special:AllEvents again.

Other option could be:

• Create a new column on the db like "sandbox" and we set it to false by default and for sandbox events we set it to true.
• Add a logic on the backend side to check if the event is a sandbox event and remove it from the list.

Thank you for sharing these ideas, @Daimona & @cmelo!

I will add this ticket to the agenda for our next sprint planning meeting.

We should probably not use a live wiki for testing events moving forward. It adds complexity like what we are dealing with in this task.

In T364353#9813496, @VPuffetMichel wrote:

We should probably not use a live wiki for testing events moving forward. It adds complexity like what we are dealing with in this task.

I think we should still allow it, as it's common practice with other things (normal pages, templates, modules, etc.). Identifying test events does add complexity, though, and I can't think of examples in MW itself where something is try to decide whether a certain page is a test page or not.

Then it seems useful for an organizer to create events and hide them until they are ready to show them to everyone. (a different twist on the "draft" proposal Emanuele mentions above)

It should be a different field than the status (open / close)

Making an event invisible would mean that they would not show up in the event list but an organizer could set it up, play with the content etc.

We could also use this to hide all the test events.

In T364353#9813629, @VPuffetMichel wrote:

Then it seems useful for an organizer to create events and hide them until they are ready to show them to everyone. (a different twist on the "draft" proposal Emanuele mentions above)

Agreed.

It should be a different field than the status (open / close)

Maybe it could be a new field (checkbox?) in the registration form, checked by default, along the lines of:

[] Show this event in a public list of all events

Wording and scope TBD, but you get the idea.

Discussed today with @cmelo @MHorsey-WMF and @VPuffetMichel. Our current proposal is to:

• Add a checkbox to the registration form for users to specify that the event is actually a test event; off by default.
  • This would be backed by a new field in the DB, separated from the event status
• Indicate that an event is a test events in various places (e.g., event page, MyEvents, AllEvents)
• Add a way to display test events in AllEvents (could be a new filtering option, off by default)

Thanks for this explanation, @Daimona! I like this proposal more than adding a new status (such as open, closed, test). This new proposal makes sense to me. I'll update the AC and then share it with the team for estimation.

Change #1101041 had a related patch set uploaded (by Mhorsey; author: Mhorsey):

[mediawiki/extensions/CampaignEvents@master] add database column for test event

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

Change #1101042 had a related patch set uploaded (by Mhorsey; author: Mhorsey):

[mediawiki/extensions/CampaignEvents@master] Add data layer and update rest handlers

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

@MHorsey-WMF, hey there! I added to the AC that this work should be behind a feature flag, after discussing this with @cmelo. Sorry for not writing this in advance!

Change #1105672 had a related patch set uploaded (by Mhorsey; author: Mhorsey):

[mediawiki/extensions/CampaignEvents@master] Add UI field for test events and remove test events from collaboration list.

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

Change #1101041 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] add database column for test event

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

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

[mediawiki/extensions/CampaignEvents@master] Make event_is_test_event a boolean

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

Change #1111332 abandoned by Daimona Eaytoy:

[mediawiki/extensions/CampaignEvents@master] Make event_is_test_event a boolean

Reason:

Booleans are not properly supported under postgres, see T381759#10461839

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

Change #1101042 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add "event_is_test_event" field to campaignEvents data layer

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

Change #1105672 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add UI field for test events and remove test events from collaboration list.

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

Acceptance Criteria:

• Given that an organizer is creating or editing Event Registration
  • ✅ They should see a new field at the bottom of the form, below "Grant ID"
  • ✅ The field title should be: "Is this a live or test event?"
    • And there should be a dropdown with 2 options:
      • ✅ Live event
      • ✅ Test event
    • ✅ And the default should be set to "Live event"
  • If the user picks "Live event"
    • ✅ Behavior remains the same for the event page (no changes)
  • If the user picks "Test event"
    • ✅ The event should not display in the Collaboration List
    • ✅ The event should display in all other places

All AC met, working as expected, sending to product sign off.