@ifried There are no image suggestions on in beta cluster or testwiki. Best way to do this would probably be on cswiki, as it has image suggestions.

✅ Letters with diacritics should be sorted in the appropriate order.

Given that a user is viewing the contributions table in Special:EventDetails
✅ Then the content of the "Wiki" column should be the localised name of the wiki (e.g., "Spanish Wiktionary") if available, and the wiki ID (e.g., "eswiktionary") otherwise, for example locally

Functionality surrounding address field working as expected, sending to product sign off

@Daimona is there anything here to further test besides just making sure that functionality around address fields is working as expected?

heya @Jdforrester-WMF would you like me to work on this? The tests will need upgraded at the same time as the wdio-mediawiki version

✅ Release Collaborative Contributions MVP to all wikis with CampaignEvents extension

Working as expected now in prod, thx @egardner! This can be closed out now

In T408822#11385111, @Daimona wrote:

In T408822#11384694, @vaughnwalters wrote:

What is meant by not properly localised (numbering system) in the AC though @cmelo?

I meant numeral system, I didn't actually check how the thing is called. In particularly verifying those other than arabic numerals.

Maybe all that needed to be tested is the thousands separators?

In theory, and off the top of my head, it'd be: numeral system, thousands separator (also the positioning as in e.g. the indian system), and decimal separator. But really, all these things are handled internally, so you can assume that if any one of them is working correctly, all the others do too, so no need to test more I think.

In T408822#11354970, @cmelo wrote:

In T408822#11332805, @vaughnwalters wrote:

Heya @cmelo how do I test this one?

Hi @vaughnwalters, to test this you need to have a big number of participants or Wikis edited or articles created or articles edited, it will basically format the number like in the image below:

For Slovak language (sk: slovenčina), change:

✅ Move Edit Count to be between Articles edited and Bytes changed

✅ Slovak aliases for Special pages of CampaignEvents Extension have been added into the fileCampaignEvents.alias.php

✅ The cea_country column is dropped from the database schema and the code no longer references it
✅ The cea_country_code column is made not nullable

If a user removes all of the edits that they are associated with then the actions column will still display until page refresh. Should we hard refresh the page after all events that are associated with a user are deleted so that the actions column is removed?

In T410327#11381851, @Daimona wrote:

In T410327#11381824, @vaughnwalters wrote:

In T410327#11381463, @Daimona wrote:

This seems really hard to fix right now given core limitations: T410328, T410329. Perhaps we should consider removing cross-wiki support from the endpoint...

Why is this currently working on betacluster cross wiki in the UI though? I would think if it is not working in the API it should also not work when associating an edit cross wiki using the UI?

When you use the UI (post-edit dialog) you are not associating an edit on a different wiki: you're associating an edit on the current wiki.

✅ Should be able to read all the text in the header, as you can in light mode:

In T403124#11381781, @vaughnwalters wrote:

Acceptance Criteria:

• Given that a user is on the Contributions tab,
  • ❓ They should see a new "Actions" column in the table view, QA note - this column is only shown if the user has edits on the table, and it is not shown to logged out users. If this is expected, can we change this AC?
    

In T410327#11381463, @Daimona wrote:

This seems really hard to fix right now given core limitations: T410328, T410329. Perhaps we should consider removing cross-wiki support from the endpoint...

• Given that someone is viewing the summary on the Contributions tab,
  • ✅ Then they should see a new card/data point called 'Edit count'
    

In T404899#11381421, @Daimona wrote:

In T404899#11380820, @vaughnwalters wrote:

I am able to correctly associate an event with an edit that is on a different wiki through the API, but then those edits do not show in my collaborative contribution table. I have associated edits on arwiki, eswiki, and dewiki with an event that i created on enwiki, but none of the edits display on the collaborative contributions table.

That is a different issue, most likely T410327 which I just filed.

So... since this ticket is for the API, it doesn't seem to be working correctly, even though I am getting a success message from the API. But when I use the UI, it is working correctly, and page titles are correctly formatted in the collaborative contributions table. Thoughts? I have been testing using this event: https://en.wikipedia.beta.wmcloud.org/wiki/Special:EventDetails/1265 and all contributions that are displaying were created using the UI.

If title normalization is correct, I think that's enough for this task. I'll take care of the error in the other task.

Acceptance Criteria:

• Given that a user is on the Contributions tab,
  • ❓ They should see a new "Actions" column in the table view, QA note - this column is only shown if the user has edits on the table, and it is not shown to logged out users. If this is expected, can we change this AC?
    
    • ✅ And the column should be the last column in the table view,
      
  • And if they are an organizer of the event,
    • ✅ They should see a trash icon for each edit in the Actions column,
      
    • ✅ And the icon has a tooltip with the message "Remove contribution" on mouse over
      
  • And if they are a participant who made an edit during the event,
    • ✅ They should see a trash icon for each edit they made in the Actions column,
      
    • ✅ And the icon has a tooltip with the message "Remove contribution" on mouse over
• And if they click on the trash icon,
  • They should see a dialog to verify their choice,
    • And the dialog should have the following text:
      • ✅ Header: "Remove this edit from [event name]"
      • ✅ Line 1: "Are you sure you want to remove this edit from the event?"
      • ✅ Line 2: "It won't be deleted, but it will no longer be associated with the event."
    • And the dialog should have the following options as buttons:
  • ✅ Cancel
  • ✅ Remove (in red)
    
• And, if they select "Remove,"
  • ✅ The association should be hard deleted
    • Note: This may be changed to soft deletion when we enable logging (see T406633)
  • ✅ The user should get a confirmation message informing that their edit was removed from the event, with the following text: "The edit was removed from the event."
    
• And, if they select "Cancel,"
  • ✅ The dialog should disappear and no other action will need to occur
• If there is an error when trying to delete
  • ✅ The user should get an error message with the following text: "Error removing contribution."
    
• ✅ The new DELETE endpoint should be documented

Acceptance criteria:

Given a user is associating an edit with an event using the API
And the edit was made on another wiki
❌ Then the edited page's title is correctly formatted in the contributions tab, according to the configuration of the other wiki (w.r.t, for example, custom namespaces and namespace translations)

✅ Move lock icon for private participants to left side

Title is wrapping correctly now, AC met 🎉 , sending to product sign off

✅ API should not be able to associate edits with events that have not yet started OR that have ended
✅ The following error message will be shown: "This event is not currently active, so you cannot associate this edit with it."

In T401208#11359827, @ifried wrote:

Thank you!

• The following AC has been removed so it is no longer valid: " Validate that the event is still ongoing within a reasonable time window"
• T408960 has been taken on.

For these reasons, I think all issues have been resolved, so moving back to QA for a final okay.

While this ticket will solve the issue in T408257 that this is a follow up ticket for, I'm wondering if it the lock icon should then be moved to the left side everywhere else that it is used in the extension, for consistency? For example, the lock icon is still on the on the right side of the username in the participants tab.

In T408257#11359803, @ifried wrote:

Task to move icon: T409757.

In that case, would this work now pass QA, @vaughnwalters?

In T408267#11374379, @Daimona wrote:

In T408267#11373059, @egardner wrote:

In T408267#11373031, @Daimona wrote:

Yeah, it's odd because I just tried this locally and it reproduces the issue, with the exact same steps. Not sure why beta is different though...

Can you pull down https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1204976 and see if that fixes things in your local env? If so I'm happy to move it forward.

Yep, it seems to fix it for me. I'll let @vaughnwalters do more testing and someone more familiar with MF approve, but the fix makes sense to me.

In T408855#11366366, @Daimona wrote:

In T408855#11364160, @cmelo wrote:

Hi @vaughnwalters, I have tested it on the maser branch, and I was not able to reproduce it anymore, I think this was fixed in some of the other tasks we did, let me know if you can still reproduce it, thank you!

Are you sure? I can still reproduce in master using the instructions in the task description. I don't think this can have been fixed without a core change.

In T400722#11345324, @JFernandez-WMF wrote:

thank you! @cmelo, one question: is the pagination going to be at the bottom? is there a task for this?

✅ If someone can see private participant data, there should be the lock icon next to private participant usernames in the collaborative contributions table view

This column wraps now correctly on full size desktop view, but breaks the layout on mobile. Note the "Article edited" header on mobile skin, or smaller breakpoints on desktop view.

Confirming that it is is enabled in beta, sending to product sign off.

In T408923#11331590, @Daimona wrote:

I mentioned this in T400722#11126865 and following comments, it's not really possible to change this given what's currently supported by the IndexPager hierarchy. All the sort keys will need to use the same direction.

Keeping this in QA until I can test on betacluster

Heya @cmelo how do I test this one?

The API should:

✅ A given edit should only be associated with a single event. User should be able to associate edits on same article with different events, if the edits are different.

In T400722#11331174, @cmelo wrote:

In T400722#11308584, @vaughnwalters wrote:

In T400722#11305536, @cmelo wrote:

QA note - the timestamp is correctly used as a secondary sort key, but it is currently used as a secondary sort key in ascending order, whereas when timestamp is used as the default, it is used in descending order. I >>feel this secondary timestamp sort key should also be descending, as it is when the default view for the contributions tab is viewed. This would make the experience more consistent, IMO. Thoughts @cmelo? see >>current behavior below

I agree, I will take a look to understand the reason why, thanks!

Okay thanks @cmelo. I can create a new ticket too if that is easier.

Thanks @vaughnwalters, yes another ticket would be good, thanks!!!

In T408855#11331990, @SLong-WMF wrote:

@vaughnwalters Are there automated tests to validate navigation on this? Either UI, integration or unit tests? If we can set up data appropriately for this situation in Catalyst this would be a decent opportunity to create a test automation ticket for future work to make sure it doesn't happen again