Page MenuHomePhabricator

Prevent participants from answering again if their answers were already aggregated
Closed, ResolvedPublic5 Estimated Story Points

Description

From T328032#8936008:

Acceptance Criteria:

  • Participants are informed that, once they answer the participant questions and the data has been aggregated, they cannot edit their response
  • After answers are deleted for a participant, if the user goes to the form, they do not see fields to collect participant answers. The user should see a notice that they cannot provide participant answers. the notice should read "Your responses have been aggregated and deleted per the data retention information."
  • Note that the requirement applies to both the form in the event page (when the user clicks 'register') and in the special page (Special:RegisterforEvent)
  • If someone registers via the API after their answers have been deleted and they provide answers again, they should get an error message

Design
Design specs

Screenshot 2023-07-11 at 10.22.44.png (970ร—720 px, 137 KB)

Event Timeline

Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptJun 20 2023, 11:15 PM

@Daimona Is this on a question-by-question basis?
For example, if a participant only answers 2 questions and those responses are aggregated they can't answer those same two again after aggregation but they can answer the other questions they haven't answered previously.
OR
Once they have answered any question and their responses have been aggregated they can't answer both the ones they answered previously and the ones they haven't answered at all

@Daimona Is this on a question-by-question basis?
For example, if a participant only answers 2 questions and those responses are aggregated they can't answer those same two again after aggregation but they can answer the other questions they haven't answered previously.
OR
Once they have answered any question and their responses have been aggregated they can't answer both the ones they answered previously and the ones they haven't answered at all

Ah, good point. No, it's not on a question-by-question basis. Having chosen option 2A in T328032#8936008 (as opposed to 2B) means that all answers are treated as a whole. So if you only answer 2 questions and those are aggregated, you can't answer any question anymore, including those that you never answered in the first place.

Daimona renamed this task from Prevent participants from answering again any questions whose answers were already aggregated to Prevent participants from answering again if their answers were already aggregated.Jun 21 2023, 12:33 PM

At the end of the event for participants who answered the registration form questions, their responses would be replaced by a notice informing them that their data has been aggregated and deleted

Screenshot 2023-07-07 at 18.26.46.png (1ร—1 px, 289 KB)

Screenshot 2023-07-10 at 19.47.01.png (1ร—1 px, 315 KB)

LGTM, just one comment: the message there says "our privacy information", but I'm wondering if it could be unclear who "our" refers to: the organizers of the event? Some other users? Whoever runs the site (e.g., WMF)? I don't know if it's just me, but maybe it could be made a bit more impersonal?

LGTM, just one comment: the message there says "our privacy information", but I'm wondering if it could be unclear who "our" refers to: the organizers of the event? Some other users? Whoever runs the site (e.g., WMF)? I don't know if it's just me, but maybe it could be made a bit more impersonal?

I can change that.

LGTM, just one comment: the message there says "our privacy information", but I'm wondering if it could be unclear who "our" refers to: the organizers of the event? Some other users? Whoever runs the site (e.g., WMF)? I don't know if it's just me, but maybe it could be made a bit more impersonal?

I can change that.

I agree

ifried updated the task description. (Show Details)
ifried added a subscriber: gonyeahialam.
ifried updated the task description. (Show Details)
ifried set the point value for this task to 5.Jul 27 2023, 2:48 PM

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

[mediawiki/extensions/CampaignEvents@master] Prevent participants from answering after aggregation (special page)

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

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

[mediawiki/extensions/CampaignEvents@master] Prevent participants from answering after aggregation (event page)

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

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

[mediawiki/extensions/CampaignEvents@master] Prevent participants from answering after aggregation (backend)

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

Change 953712 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Prevent participants from answering after aggregation (special page)

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

Change 953713 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Prevent participants from answering after aggregation (event page)

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

Change 953726 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Prevent participants from answering after aggregation (backend)

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

โœ… Participants are informed that, once they answer the participant questions and the data has been aggregated, they cannot edit their response
โœ… After answers are deleted for a participant, if the user goes to the form, they do not see fields to collect participant answers. The user should see a notice that they cannot provide participant answers. the notice should read "Your responses have been aggregated and deleted per the data retention information."
โœ… Note that the requirement applies to both the form in the event page (when the user clicks 'register') and in the special page (Special:RegisterforEvent)
โœ… If someone registers via the API after their answers have been deleted and they provide answers again, they should get an error message

On Event details dialogOn Special:RegisterForEventRegistering with API after aggregation
Screenshot 2023-08-31 at 11.09.21 AM.png (1ร—1 px, 178 KB)
Screenshot 2023-08-31 at 11.08.27 AM.png (874ร—2 px, 164 KB)
Screenshot 2023-08-31 at 4.31.44 PM.png (1ร—2 px, 252 KB)

@Daimona, Noting here that if the event ends and then aggregation occurs, there is no additional aggregation message that displays in the API. I think this is probably fine since the user can still not register, but maybe it would be worth mentioning that not only has the event ended but aggregation has also occurred and answers have been deleted?

Registering with API after event ends and aggregation
Screenshot 2023-08-31 at 4.22.19 PM.png (1ร—2 px, 244 KB)

Another question, If the event has already ended (and data has been aggregated, or has not been aggregated), a participant can still cancel their registration, but can not change their registration status from public to private. Is there a reason for this and is there a reason to show the Manage registration option at all, instead of just the Event ended? Right now, trying to change registration in the event dialog after the event ends is a weird UX flow as it sends the user to Special:RegisterForEvent, where you can again try to change registration from public to private and then it will show the error of `This event registration period has already finished. See the gif below:

Screen Recording 2023-08-31 at 11.23.59 AM.gif (1ร—2 px, 871 KB)

@Daimona, Noting here that if the event ends and then aggregation occurs, there is no additional aggregation message that displays in the API. I think this is probably fine since the user can still not register, but maybe it would be worth mentioning that not only has the event ended but aggregation has also occurred and answers have been deleted?

Unfortunately, the REST API framework does not support multiple error messages AFAIK. But I think in this case it makes sense to only mention that the event is already over, as that's a stronger cause of failure that the user can do nothing about, and for which retrying does not help.

Another question, If the event has already ended (and data has been aggregated, or has not been aggregated), a participant can still cancel their registration, but can not change their registration status from public to private. Is there a reason for this and is there a reason to show the Manage registration option at all, instead of just the Event ended?

That's a good question, but I don't have an answer to it.

Right now, trying to change registration in the event dialog after the event ends is a weird UX flow as it sends the user to Special:RegisterForEvent, where you can again try to change registration from public to private and then it will show the error of `This event registration period has already finished. See the gif below:

Yeah, this is happening because the API request for editing the registration fails with a 4xx, but API errors are not handled in the interface (once again, because of a limitation of the API framework, and more specifically T269492). Instead, we just fall back to the special page, which has fully working error handling.

Another question, If the event has already ended (and data has been aggregated, or has not been aggregated), a participant can still cancel their registration, but can not change their registration status from public to private. Is there a reason for this and is there a reason to show the Manage registration option at all, instead of just the Event ended?

That's a good question, but I don't have an answer to it.

Right now, trying to change registration in the event dialog after the event ends is a weird UX flow as it sends the user to Special:RegisterForEvent, where you can again try to change registration from public to private and then it will show the error of `This event registration period has already finished. See the gif below:

Yeah, this is happening because the API request for editing the registration fails with a 4xx, but API errors are not handled in the interface (once again, because of a limitation of the API framework, and more specifically T269492). Instead, we just fall back to the special page, which has fully working error handling.

tagging in @ifried here for thoughts on that first question above? It makes more sense to me that we should have an Event ended message here instead. Particularly since it would eliminate the UX flow mentioned. Probably out of scope for this ticket though.

It is worth noting that this is only in the case of aggregation after an event ends - In the case of aggregation after the 90 days of first answering participant questions, if the event is still open, then the user can correctly change from private / public, even though the aggregation has already occurred.

Another question, If the event has already ended (and data has been aggregated, or has not been aggregated), a participant can still cancel their registration, but can not change their registration status from public to private. Is there a reason for this and is there a reason to show the Manage registration option at all, instead of just the Event ended? Right now, trying to change registration in the event dialog after the event ends is a weird UX flow as it sends the user to Special:RegisterForEvent, where you can again try to change registration from public to private and then it will show the error of `This event registration period has already finished. See the gif below:

Screen Recording 2023-08-31 at 11.23.59 AM.gif (1ร—2 px, 871 KB)

Why does it take you to the special page after you have already made your registration private on the modal? @Daimona
@vaughnwalters
I believe we are still giving the participant the option to Cancel registration or change the registration privacy status even after the event has ended. @ifried
So the flow should be -
The participant clicks on the Manage registration and then clicks on Edit registration
The modal opens and the participant switches to private registration and then saves.
The modal closes and the label on the event page changes from you are registered publicly to privately.

Why does it take you to the special page after you have already made your registration private on the modal? @Daimona

See

Yeah, this is happening because the API request for editing the registration fails with a 4xx, but API errors are not handled in the interface (once again, because of a limitation of the API framework, and more specifically T269492). Instead, we just fall back to the special page, which has fully working error handling.

Thanks for the clarification on why the user is redirected to the special page, @Daimona.

While I was out of office during the end stages of the epic to allow a participant to register privately (T319454), I do remember from previous conversations that we want to allow participants to change their registration status after an event ends. This way, if they later feel uncomfortable with their username being publicly displayed on the event page (for example, if there is a change in the political or social environment where they live that would make it unsafe or uncomfortable for them to publicly state their participation in an event), they don't need to completely cancel their registration to protect themselves; they can simply change the registration status from public to private. So, yes, @gonyeahialam, we want people to be able to change their registration status or cancel their registration after an event ends.

As for the user flow, I understand that there are some technical limitations, so I am fine with the registration status changing on the special page, so long as the user is allowed to change it.

Does this need to be a separate ticket, or can it be handled in this same task?

[...] we want to allow participants to change their registration status after an event ends. This way, if they later feel uncomfortable with their username being publicly displayed on the event page (for example, if there is a change in the political or social environment where they live that would make it unsafe or uncomfortable for them to publicly state their participation in an event), they don't need to completely cancel their registration to protect themselves; they can simply change the registration status from public to private.

Thanks for weighing in, I also remember this. However, before T319454, participants weren't able to change their visibility at all. If they wanted to change visibility, the only way was to cancel registration and then registers again. In the specific case of events that have already ended, this effectively meant that someone who wanted to "hide" their name had no option but to cancel their registration, without being able to register again.

This behaviour hasn't changed since then (that is, we didn't change it when implementing T319454). The only difference is that we now display the "manage registration" button for past events, which I guess makes this bug more prominent. However, it has nothing to do with this task, or with participant questions in general.

Does this need to be a separate ticket, or can it be handled in this same task?

I think it should be a separate ticket, for the reasons above.

Does this need to be a separate ticket, or can it be handled in this same task?

I think it should be a separate ticket, for the reasons above.

Separate ticket created T345735 - Allow participants to switch between public/private registration after the event ends


All AC has been met in T339981#9135607 and I am moving this to design sign off.

@vaughnwalters @Daimona As shown in the design, we don't need the 'Clear form' button after answers are deleted

@vaughnwalters @Daimona As shown in the design, we don't need the 'Clear form' button after answers are deleted

Thanks @gonyeahialam - I just created T345770 as a follow up for that