Page MenuHomePhabricator

API - Delete event registration
Closed, ResolvedPublic

Description

As a Dev I want to create the API to delete the event registration data of a giving event registration ID

Background: This is for when users want to completely remove the registration experience on their event page (i.e., not when registration is closed). Since organizers will only be able to add registration to real live event pages in MVP/V1, this doesn't need to be prioritized for V0. However, it would be very useful if it is available for testing, since it will be reassuring to testers and allow them more features for testing. As for the question of hard deletion vs. soft deletion, I think there is a use case in seeing if people have removed registration for their event page, but it is more for internal team analysis than for organizers. With this data, we could see how often people are potentially not satisfied with the solution and removing it from the page. But it is only one data point around satisfaction, as we would only need to see how often people are adopting the tool in general (rather than just reverting an experience that they initially opted into).

Acceptance criteria:

The event registration must be soft deleted on the database
For V0 only the creator can delete the event registration

Event Timeline

@cmelo To confirm, are we talking about a new database field (e.g. event_deleted ∈ {0, 1}), or changing the status of the registration (i.e. event_status)? And if it's the former, do we need it for V0?

Hello @Iflorez, @gonyeahialam, @CKMIE89, @Astinson, @IBrazal

When an organizer wants to delete registration from an event page (for example, they think the registration solution doesn't fit their needs), do you think it we should do a hard delete (so there no record of the deletion in the database) or a soft delete (so there is a record of the deletion in the database). If you do think there should be a soft delete, do you think the organizer should be able to restore the registration somewhere in the UI (and, if so, where/how)? And how do you suggest we handle scenarios where some people have already registered and then the organizer performs a delete? I have some ideas, but I would love to hear your opinions. Thanks in advance!

@ifried Just for clarity, this would be different from making registration active/inactive?

@fnartey Says soft delete would be better to show people are interested and testing, even if they delete it. He also says that organizers should have a way of restoring event registration if we are storing it in the databasee.

And @CKMIE89 to answer your question: This is if an organizer adds registration to the event page and then completely removes it. This is not the same as marking registration as closed, since the registration would still be on the event page (just closed status).

Ok, so I'm not sure what scenarios might justify a hard delete (security?) But maybe this can be left as an option for the organizer?

Options could be: "permanently delete registration", or "hide registration" with text explaining they can restore later?
If participants have registered, a message box could appear prompting the organizer to send a message to those who registered. (or ignore that if they want) I'm not sure an automatic message would be helpful because of the variety of scenarios, but I guess that could be an option (I just don't think it could be very informative, unless the organizer checks a box with a reason for deleting.... but that's starting to get complicated)

~afterthought: permanently delete but after a delay? (like the 30 day trash box for emails)

Part of me is thinking from a trust and safety pesrpective, we would want all of the "deletes" to be soft deletes, with some of the soft deletes being hidden from organizers. @ifried happy to talk that through.

@cmelo To confirm, are we talking about a new database field (e.g. event_deleted ∈ {0, 1}), or changing the status of the registration (i.e. event_status)? And if it's the former, do we need it for V0?

HI @Daimona It would be a deleted_at (timestamp) field, and yes I think we should have this for V0, I mean just save the deleted_at data on the database

@cmelo To confirm, are we talking about a new database field (e.g. event_deleted ∈ {0, 1}), or changing the status of the registration (i.e. event_status)? And if it's the former, do we need it for V0?

HI @Daimona It would be a deleted_at (timestamp) field, and yes I think we should have this for V0, I mean just save the deleted_at data on the database

Ewww, sorry, I forgot about that column :-O It was pretty useless while we were creating the backend and I forgot about it.

I still have a question for everyone here though. Imagine that you have an event page, you enable registration for it, and then delete the registration. Should users be allowed to create a brand new registration for the same page? Note that we have the constraint of a single registration per event page, so if you create a new registration you can no longer restore the old one (unless you also delete the new one first).

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

[mediawiki/extensions/CampaignEvents@master] Add backend logic and REST endpoint for deleting a registration

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

Change 776242 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add backend logic and REST endpoint for deleting a registration

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

There is nothing user-facing to test, so I'm marking this as Done.