Change Details

**Context**: by adding a config setting that determines the namespaces where event registration is allowed, we introduce the following scenario: if someone creates an event with registration in namespace X, and then administrators remove namespace X from the list of allowed namespaces, we're left with an event in an inconsistent state. For simplicity, these events will be referred to as "zombie events". This should be a relatively rare occurrence, but still something we need to handle somehow. This task is about figuring out the how, and implementing it. ===Acceptance criteria=== **To be determined.** The following user experiences are affected: - Event pages (the event info header) - Special:AllEvents & Special:MyEvents, local and foreign events - Special:RegisterForEvent & Special:CancelEventRegistration - Special:DeleteEventRegistration - Special:EditEventRegistration (NB: **not** Special:Enable-) - Special:EventDetails - Special:GenerateInvitationList - Most, if not all, [[https://www.mediawiki.org/wiki/Extension:CampaignEvents/Api | API endpoints ]] Also, we are currently preventing users from moving event pages (with registration enabled) outside the event namespace. This was done last year in T358704. As part of this task, we can lift that restriction, and treat the event as a zombie after the page move instead. Zombie events are somewhere between normal events and deleted events. It is effectively a new state. The main question is what exactly this new state will look like: should it be closer to the normal state (so, for example, you could still see the event details and participants, but people would not be able to register) or the deleted state (and so you would only see an error message, and nothing else)? From a technical point of view, there should be minimal differences between these options. This is really more of a product question along the lines of "what is most useful and least confusing?". For example, if we do not show event details/participant, could organizers lose information in the process? What about retaining data for historical purposes? After all, it's MediaWiki we're talking about, with logs, page histories, etc. That is why I have a preference for displaying information unless there's a reason not to. Nonetheless, my only technical recommendations would be: - For global event lists (AllEvents, MyEvents), we have no way to tell if a foreign event is in a valid namespace. [That is to say, unless we waste a lot of time implementing this at the DB level, which is simply not worthwhile] - The registration header should not be shown in event pages. Partly for the obvious usability reasons. But also because that would force us to intercept each and every page view to see if we have an event linked to that page, which we should avoid if possible. - Not really a technical recommendation, but Special:DeleteEventRegistration should probably be usable regardless of everything else. Ditto for Special:CancelEventRegistration, especially if we decide to still show the list of participants. And finally, as noted above: zombie events should be a rare occurrence. I would aim for maximum simplicity; and possibly maximum consistency, especially when it helps with simplicity.

**Context**: by adding a config setting that determines the namespaces where event registration is allowed, we introduce the following scenario: if someone creates an event with registration in namespace X, and then administrators remove namespace X from the list of allowed namespaces, we're left with an event in an inconsistent state. For simplicity, these events will be referred to as "zombie events". This should be a relatively rare occurrence, but still something we need to handle somehow. This task is about figuring out the how; the implementation will be done in T387974. The following user experiences are affected: - Event pages (the event info header) - Special:AllEvents & Special:MyEvents, local and foreign events - Special:RegisterForEvent & Special:CancelEventRegistration - Special:DeleteEventRegistration - Special:EditEventRegistration (NB: **not** Special:Enable-) - Special:EventDetails - Special:GenerateInvitationList - Most, if not all, [[https://www.mediawiki.org/wiki/Extension:CampaignEvents/Api | API endpoints ]] Also, we are currently preventing users from moving event pages (with registration enabled) outside the event namespace. This was done last year in T358704. As part of this task, we can lift that restriction, and treat the event as a zombie after the page move instead. Zombie events are somewhere between normal events and deleted events. It is effectively a new state. The main question is what exactly this new state will look like: should it be closer to the normal state (so, for example, you could still see the event details and participants, but people would not be able to register) or the deleted state (and so you would only see an error message, and nothing else)? From a technical point of view, there should be minimal differences between these options. This is really more of a product question along the lines of "what is most useful and least confusing?". For example, if we do not show event details/participant, could organizers lose information in the process? What about retaining data for historical purposes? After all, it's MediaWiki we're talking about, with logs, page histories, etc. That is why I have a preference for displaying information unless there's a reason not to. Nonetheless, my only technical recommendations would be: - For global event lists (AllEvents, MyEvents), we have no way to tell if a foreign event is in a valid namespace. [That is to say, unless we waste a lot of time implementing this at the DB level, which is simply not worthwhile] - The registration header should not be shown in event pages. Partly for the obvious usability reasons. But also because that would force us to intercept each and every page view to see if we have an event linked to that page, which we should avoid if possible. - Not really a technical recommendation, but Special:DeleteEventRegistration should probably be usable regardless of everything else. Ditto for Special:CancelEventRegistration, especially if we decide to still show the list of participants. And finally, as noted above: zombie events should be a rare occurrence. I would aim for maximum simplicity; and possibly maximum consistency, especially when it helps with simplicity.

**Context**: by adding a config setting that determines the namespaces where event registration is allowed, we introduce the following scenario: if someone creates an event with registration in namespace X, and then administrators remove namespace X from the list of allowed namespaces, we're left with an event in an inconsistent state. For simplicity, these events will be referred to as "zombie events". This should be a relatively rare occurrence, but still something we need to handle somehow. This task is about figuring out the how,how; andthe implementing it. ===Acceptance criteria=== **Toation will be determined.**one in T387974. The following user experiences are affected: - Event pages (the event info header) - Special:AllEvents & Special:MyEvents, local and foreign events - Special:RegisterForEvent & Special:CancelEventRegistration - Special:DeleteEventRegistration - Special:EditEventRegistration (NB: **not** Special:Enable-) - Special:EventDetails - Special:GenerateInvitationList - Most, if not all, [[https://www.mediawiki.org/wiki/Extension:CampaignEvents/Api | API endpoints ]] Also, we are currently preventing users from moving event pages (with registration enabled) outside the event namespace. This was done last year in T358704. As part of this task, we can lift that restriction, and treat the event as a zombie after the page move instead. Zombie events are somewhere between normal events and deleted events. It is effectively a new state. The main question is what exactly this new state will look like: should it be closer to the normal state (so, for example, you could still see the event details and participants, but people would not be able to register) or the deleted state (and so you would only see an error message, and nothing else)? From a technical point of view, there should be minimal differences between these options. This is really more of a product question along the lines of "what is most useful and least confusing?". For example, if we do not show event details/participant, could organizers lose information in the process? What about retaining data for historical purposes? After all, it's MediaWiki we're talking about, with logs, page histories, etc. That is why I have a preference for displaying information unless there's a reason not to. Nonetheless, my only technical recommendations would be: - For global event lists (AllEvents, MyEvents), we have no way to tell if a foreign event is in a valid namespace. [That is to say, unless we waste a lot of time implementing this at the DB level, which is simply not worthwhile] - The registration header should not be shown in event pages. Partly for the obvious usability reasons. But also because that would force us to intercept each and every page view to see if we have an event linked to that page, which we should avoid if possible. - Not really a technical recommendation, but Special:DeleteEventRegistration should probably be usable regardless of everything else. Ditto for Special:CancelEventRegistration, especially if we decide to still show the list of participants. And finally, as noted above: zombie events should be a rare occurrence. I would aim for maximum simplicity; and possibly maximum consistency, especially when it helps with simplicity.