Acceptance Criteria:

@zeljkofilipin The documentation that I mentioned in our meeting was for setting up a wikifarm, not explicitly setting up central auth. But check out this comment from @Daimona as I think it is what you will need to get central auth working.

✅ The copy "This participant's responses have been aggregated and deleted" should not display vertically in far right side of the participants table on Special:EventDetails

In T361159#9742990, @Daimona wrote:

In T361159#9742971, @vaughnwalters wrote:

Hey @cmelo I am seeing this behavior for user Vdubs61 on betacluster currently

If you're talking about the page title itself, this seems to be a bug in (legacy) vector. Maybe worth filing under Vector (legacy skin), but it's not on us.

Hey @cmelo I am seeing this behavior for user Vdubs61 on betacluster currently

In T362400#9739066, @vaughnwalters wrote:

Opening this back up. @cmelo check out the following two examples. While this patch does fix the problem of really long words wrapping, it also introduces the issue of shorter words wrapping where they shouldn't.

log in	log out

Special:EditEventRegistration now shows the updated form upon successful submission.

Given an event organizer goes to Special:MyEvents and clicks on the three dots
✅ They should not see open/close registration in the kebab menu
✅ And this applies to whether they are on the wiki where the event was created or a foreign wiki/a wiki where the event was not created

@cmelo for logged out users and for some logged in users this issue is fixed, but for some logged in users this issue is still present. In this example below, the user does not have an "Add languages" dropdown beside of the title and the overflow problem is still present.

✅ Using navigation bar no longer causes validation error. The error "There are problems with some of your input" no longer appears

Given I am on Special:MyEvents
And I see the Number of participants column
✅ Then it should have correct values in it

Opening this back up. @cmelo check out the following two examples. While this patch does fix the problem of really long words wrapping, it also introduces the issue of shorter words wrapping where they shouldn't.

✅ Event name should wrap in confirmation dialog

✅ The text is correctly wrapping now. Marking as done / resolved

✅ The error message is not part of the grid layout.

✅ The URL https://testchat.com/Iñtërnâtiônàlizætiønمثال字ッ was accepted as valid in Meeting URL and Group chat invite. Marking this as done/resolved.

Because T363193, T363200 and T363211 have been created to fix issues found in this ticket and everything else is working as described in the AC, I am sending this to design sign off.

Acceptance Criteria:

• If an organizer has selected any Participant Questions when configuring registration,
  • And if event registration has not yet closed,
    • ✅ Organizers of the event should be able to remove any Participant Questions
      • 
      • ✅ And all new participants will see no longer see the removed Participant Questions when they register
        • 
        • ✅ And organizers will no longer see the data collected from before the change in the Participants and Response Statistics tabs
          • ✅ And all data from deleted participant questions will be deleted as per the retention period guidelines
          • ✅ And all data from deleted participant questions will be aggregated
            • 
          • ( note that T363200 has been filed to address the This participant's responses have been aggregated and deleted copy remaining after participant questions have been removed)
        • ✅ And registered participants who answered a Participant Question prior to having the question removed can still view and edit their response before the event ends, but they will no longer see the question if they blank their former response or if they unregister and then re-register for the event
          • ✅ And there is a final aggregation that occurs when the event is over
            • And if there is any data associated with questions that were removed,
              • ✅ We should remove this data from the final aggregation
                • ❓ Data is removed from aggregation, but there is a notice that Participants' responses will be aggregated and made available here shortly.
                • 
                • Created followup task for this T363211
• If an organizer has not selected any of the Participant Questions when configuring registration,
  • And if event registration has not yet closed,
    • ✅ Organizers of the event should be able to add any Participant Questions
      • • 
      • ✅ And all new participants will see the newly added Participant Questions when they register
        • 
      • ✅ And responses to the newly added Participant Questions from those who registered before the questions were added will be recorded as No Answer
        • Note that we can perhaps later distinguish between No Answer due to the question not being available vs. the participant explicitly choosing to not answer the question, but this is not required for MVP
        • 
      • ✅ And registered participants who answered a Participant Question prior to having the question added can see the new question(s) with No response when they edit their selection, and they will have option to answer the newly added Participant Questions when editing their registration
        • 
• If an organizer has removed a question and then re-added the question,
  • And if event registration has not yet closed,
    • ✅ Organizers of the event should be able to see previous responses to the re-added participant question
      • 
• If an event ends,
  • ✅ Organizers will not be able to edit their selection of Participant Questions
    • 

I have checked each special page in the campaign events extension to make sure that data is correctly displaying. Tested together with subtask T361026 - see testing notes at T361026#9728078. Marking as done / resolved.

In T361026#9699457, @cmelo wrote:

Hi @vaughnwalters just a note, on this task the changes were more technical changes on the code base, but it basically involves how we communicate with the DB, same for T360517, so the tests I think you could do here could be a general check on every special page to check it the data is being correctly shown.

Hey Michelle, here are some QA findings:

Acceptance Criteria

• ✅ Organizers should always be able to see the aggregated non-PII responses of their event in the Response Statistics tab, whether or not they have accepted the clickwrap agreement

have not accepted clickwrap	have accepted clickwrap

• ✅ Organizers should not be able to see the aggregated PII responses of their event in the Response Statistics tab until they have accepted the clickwrap agreement
• The three flows for how this will work is as follows:
  • If the event has PII & non-PII questions:
    • ✅ Organizers of the event should be able to see non-PII data in the Response Statistics tab, but they need to agree to the clickwrap agreement in the response statistics tab to see PII data
    • 
  • If the event has only PII questions:
    • ✅ Organizers of the event need to accept a clickwrap agreement in order to display any data on the Response Statistics tab
    • 
  • If the event has only non-PII data:
    • ✅ Organizers of the event can open the Response Statistics tab and see the non-PII data, with no need to accept a clickwrap agreement (so no clickwrap agreement in the UI)
    • 
• ✅ Note that, unlike in the designs below, the "Q" in "Questions" should not be capitalised
• 

@Daimona this is working as stated in the Description. However, I don't think this flow makes as much sense on Special:EnableEventRegistration, because once the event is enabled, then the EnableEventRegistration form no longer works for that event. It could redirect to Special:EditEventRegistration or if we want to remain on this page after the event is enabled, then the Enable registration button should be disabled. But even this I don't think is a UX improvement on what was happening before this patch (as far as Special:EnableEventRegistration is concerned). While I do agree with the action of keeping the user on the page for EditEventRegistration, I think for EnableEventRegistration it just adds confusion.

In T358781#9709769, @cmelo wrote:

@vaughnwalters

❌ And this new error should be documented on mediawiki.org
@cmelo Please delete your event registration on XXX, the wiki where the event was created. needs to be added to the Delete a registration documentation on mediawiki.org

Done, thank you!

Docs have been updated and link text is now bold, so I am sending this to design sign off

Testing AC on betacluster:

Acceptance Criteria:

Acceptance criteria for first iteration

• ✅ Organizers are able to choose to include any of the available participant questions when enabling registration (as of 2024-02-20, these are: age, gender, profession, wiki skill level, affiliates)
• Organizers are able to modify the question selection when enabling registration only
  • QA note - This has changed with T354880 and organizers are now able to modify the question selections after the the event has been enabled
• Organizers cannot add or remove questions after registration is enabled, for instance on Special:EditEventRegistration.
  • Note: this will be changed with T354880 <-- is merged, so the AC above is no longer applicable
  • Note: We can potentially explore differentiating between the participant explicitly choosing to not answer vs. not having the option to answer in the future, but I don't think is high priority for the MVP.
• ✅ Note that "Questions" should not be capitalized in section headers, unlike in the design specs. Also, it should always be "Personally", not "Personal" (when referring to PII).
  • 
• ✅ Organizers see participant data in the Participants tab and Response Statistics tab that matches their selection

PII only gif	non PII gif	PII and non PII gif

• ✅ The following text should be displayed to organizers after the PII questions section:

✅ Generic version

To view aggregated responses of participants which contain personal information, you will be asked to handle participant information, including participant personally identifiable information, collected during event registration with care.

In T358782#9705375, @vaughnwalters wrote:

Given a user goes to Special:RegisterForEvent/{eventID}
And the event ID does not belong to the wiki where the user is trying to access the page
✅ Then we display the following text: "Please complete your event registration on [wiki name], the wiki where the event was created."
✅ Hyperlink to the proper wiki Special:RegisterForEvent/{eventID} on the following text: "complete your event registration on [wiki name]"
Note that the wiki name should be displayed as a URL (such as en.wikipedia.org) rather than the DB name

(Note that the link will be correctly made bold to match the comp when this patch is merged.)

---

Given a user tries to register using the "Register for event" API endpoint
And the event does not belong to the current wiki
✅Then they should receive a 4xx response with an error message similar to the one above

❌ And this new error should be documented on mediawiki.org
@cmelo Please set organizers on arwiki, the wiki where the event was created needs to be added to the Register as a participant documentation on mediawiki.org

In T358781#9705378, @vaughnwalters wrote:

Given an event organizer goes to the Special:DeleteEventRegistration/{eventID}
And the event ID does not belong to the wiki where the user is trying to access the page
✅ Then we display the following text: "Please delete your event registration on [wiki name], the wiki where the event was created."
✅ Hyperlink to the proper wiki Special:DeleteEventRegistration/{eventID} on the following text: "delete your event registration on [wiki name]"
Note that the wiki name should be displayed as a URL (such as en.wikipedia.org) rather than the DB name

(Note that the link will be correctly made bold to match the comp when this patch is merged.)

Given a user tries to delete an event using the "Delete a registration" API endpoint
And the event does not belong to the current wiki
✅ Then they should receive a 4xx response with an error message similar to the one above

❌ And this new error should be documented on mediawiki.org
@cmelo Please delete your event registration on XXX, the wiki where the event was created. needs to be added to the Delete a registration documentation on mediawiki.org

In T359493#9705384, @vaughnwalters wrote:

Given a user tries to change the organizers using the "Update the list of organizers" API endpoint
And the event does not belong to the current wiki
✅ Then they should receive a 4xx response with an error message similar to that used in T358781

❌ And this new error should be documented on mediawiki.org
@MHorsey-WMF Please set organizers on XXX, the wiki where the event was created. needs added to Update the list of organizers endpoint on mediawiki.org

In T359492#9705381, @vaughnwalters wrote:

Given a user tries to remove participants using the "Remove participants from an event" API endpoint
And the event does not belong to the current wiki
✅ Then they should receive a 4xx response with an error message similar to that used in T358781

❌ And this new error should be documented on mediawiki.org
@MHorsey-WMF The error message Please remove participants on XXX, the wiki where the event was created. needs to be added to the Remove participants from an event documentation on mediawiki.org

In T359491#9705401, @vaughnwalters wrote:

Given a user tries to email participants using the "Email participants" API endpoint
And the event does not belong to the current wiki
✅ Then they should receive a 4xx response with an error message similar to that used in T358781

❌ And this new error should be documented on mediawiki.org
@cmelo The error message Please email participants on XXX, the wiki where the event was created. needs to be added to the Email participants documentation on mediawiki.org

Given a user tries to email participants using the "Email participants" API endpoint
And the event does not belong to the current wiki
✅ Then they should receive a 4xx response with an error message similar to that used in T358781

Given a user goes to Special:RegisterForEvent/{eventID}
And the event ID does not belong to the wiki where the user is trying to access the page
✅ Then we display the following text: "Please complete your event registration on [wiki name], the wiki where the event was created."
✅ Hyperlink to the proper wiki Special:RegisterForEvent/{eventID} on the following text: "complete your event registration on [wiki name]"
Note that the wiki name should be displayed as a URL (such as en.wikipedia.org) rather than the DB name

Given an event organizer goes to the Special:DeleteEventRegistration/{eventID}
And the event ID does not belong to the wiki where the user is trying to access the page
✅ Then we display the following text: "Please delete your event registration on [wiki name], the wiki where the event was created."
✅ Hyperlink to the proper wiki Special:DeleteEventRegistration/{eventID} on the following text: "delete your event registration on [wiki name]"
Note that the wiki name should be displayed as a URL (such as en.wikipedia.org) rather than the DB name

Given a user tries to change the organizers using the "Update the list of organizers" API endpoint
And the event does not belong to the current wiki
✅ Then they should receive a 4xx response with an error message similar to that used in T358781

Given a user tries to remove participants using the "Remove participants from an event" API endpoint
And the event does not belong to the current wiki
✅ Then they should receive a 4xx response with an error message similar to that used in T358781

This looks correct on English betacluster now. On spanish betacluster (for example), it is not bolded, but I think this is out of scope for this ticket as this will be up to the translator to follow the correct formatting. Is this correct @cmelo?

en betacluster	es betacluster

In T324259#9657572, @cmelo wrote:

In T324259#9640185, @vaughnwalters wrote:

✅ This is working correctly and acceptance criteria is met in both Special:EditEventRegistration/{eventID} and Special:MyEvents (Kebab menu "Edit Registration")

---

@cmelo two things though:

1. The linked text should be a stronger font weight. Note the difference between the comp and the build :

comp	build

2. I noticed on spanish betacluster that the url was not linked. I am assuming this is a limitation of the translation (or possibly just because it hasn't been translated yet), but wanted to check with you here to make sure.

Hi @vaughnwalters, thank you.
For item 1 I will check if it is doable, I think it is the default style of this ooui component, not sure if I will be able to change it.

For item 2 I will take a look, but I think you are right, the issue might be related to the missing translation and should be solved as soon as it is translated.

In T360440#9664627, @Peter wrote:

Ok, the server is setup and works. I need help to make sure everything in the GUI works as expected. Maybe @vaughnwalters can help me when you have time? The server is accessible using https://pixel-production.wmcloud.org/

Checked the GUI for campaign events, and it works as I expected it to.

This is done for now, but as it will likely be added to in the future I am putting it in my personal backlog and will add the project tags back in once additional functionality is necessary.

In T348043#9671332, @ifried wrote:

Thanks for flagging this! We should go with the standardized copy.

The url for the link to the event is missing the https and this messes up the formatting (sometimes it displays as a link, sometimes it doesn't) @Daimona

Whoops, made a patch for that.

✅ Fixed

In T360396#9647194, @vaughnwalters wrote:

This is working correctly in betacluster now using this event with this p&e dashboard program

---

Keeping this in QA until after it is released in meta. Can test with this event and this p&e program.

For instance, take this URL: https://zh.wikipedia.org/wiki/永不放弃你. Phabricator does recognize it as a link, and if you open the page, you will see the exact same string in your browser's address bar (at least in chrome and firefox). However, if you then copy the URL again from the address bar and paste it elsewhere, e.g. here on phab, it will come out as https://zh.wikipedia.org/wiki/%E6%B0%B8%E4%B8%8D%E6%94%BE%E5%BC%83%E4%BD%A0 (percent-encoded). That's because your browser has transparently encoded the URL under the hood, and is only using the non-encoded version for presentational purposes.