In T434691#12216798, @Rmaung wrote:

Hi @Daimona ! Multiyear grants can be up to 3 years in length, but the activities of a grant can last beyond the official funding year. If it is easy enough to do in the code, a 4 year window rather than 2 would work for our purposes.

First, for the different error messages: assuming you tried this with https://meta.wikimedia.org/wiki/Special:EventDetails/4297 on August 11 on wikidata, I see from the logs that there has been a timeout while trying to contact Fluxx, and that would explain the first error message you got. It's a message that really should indicate that type of transient issues.

In T426102#12209329, @Ladsgroup wrote:

What I‌usually would do is to revert it on the branch but not master. Just an idea for future train blockers.

In T426102#12208569, @brennen wrote:

I spoke with Kosta who was deployer for that window. We agreed that we would like to have a DBA around for the migration just in case. Also potentially to confirm that the plan in T426102#12185841 is OK to execute.

That seems sensible, but it would be much better not to have the train blocked at testwikis this far into Wednesday. Is there a revert that can be applied instead to unblock the train, if this isn't going to be handled shortly?

Per above, we have decided not to do this, at least for the time being.

In T426102#12206426, @brennen wrote:

Thanks @Daimona for clarification. I mistakenly assumed recently merged patches linked here represented an unblock, and should instead have waited for a response - apologies.

Create a feature flag to only track the views and clicks if it is on default value = false

In T426102#12203343, @brennen wrote:

Should this still be considered blocking for T430834: 1.47.0-wmf.15 deployment blockers?

I have manually verified ✅ all the AC, although the intent was to replace the implementation as a no-op change, so I have mostly focused on verifying that the new implementation matches the old one, modulo some minor changes (like CSS progress variables and spacing) due to Codex styles that we should accept anyway. The only thing worth noting is the lack of bottom padding due to T347205, but that's OK.

Deployment scheduled for tomorrow at 13:00Z.

This was discussed a bit, the current version only supports entering articles in the local wiki for UI simplicity. I thought we had a task for the follow-up work but that wasn't the case. However:

Yeah, this is actually something we talked about and meant to implement, I think it just fell through the cracks. I'm not sure if we should allow the non-canonical form in the page content itself, but the worklist edit helper should canonicalize the titles before saving them.

Marked T426102 as a tentative blocker because it contains a backwards-incompatible DB table rename. The change needs to be backported, and the data migrated as described in the subtask, ahead of the train rollout.

@Ladsgroup @Marostegui The patch has landed in master. There are quite a few changes to the table due to field prefixes changing: before, after. I have included code for migrating the records (it's not a maintenance script as it's trivial). I can copy the function and run it via shell.php or something if that works for y'all. I'll need to do it during a backport window as that involves backporting the updated code that reads from and writes to this table.

Confirmed that one of the queries on Special:EventDetails is now gone.

You might wanna make sure that the default configuration makes sense given this is a chapter wiki. Other than that, no objections.

This can be achieved via page protection in specific cases. We chose not to implement event-based restrictions because 1) worklists aren't necessarily attached to a specific event, and 2) they can be attached to multiple events, which makes the restriction useless. Also, there are many reasons why someone might want to edit a worklist (fixing redirects, dropping deleted pages, claiming articles as in T433903, ...). These use cases don't necessarily have a shared user group.

A list of articles can already be pasted into the "add articles" dialog in Special:EventDetails. That already reports back invalid titles (non-existent ones are allowed) and deduplicates the input. What would CSV import add to the existing features? We would need to require that the CSV has a specific format anyway and discard anything but the page titles. So, why can't users copy the "titles" column from their CSV and paste it into the dialog?

In T431572#12173057, @JFernandez-WMF wrote:

i've been testing on patchdemo and have some suggestions for the promotion dialog:

1. for promotions with one event only, can the event name be in bold?

• When a registered participant edits a page during an ongoing event that has contributions enabled, and that page is on that same event’s worklist, the post-publication association modal must not be shown and the edit must count as a contribution automatically (equivalent to confirming association in the modal), without further user interaction on that step.

• Following the post-edit dialog link routes the editor to the event page, not the event details view.

Done just now, also in a bit of a rush, to fix T433429.

I have created the tables as part of T429339.

Ugghhh apologies, we forgot a feature flag check in the database access code. We could add some feature flag checks where needed, but it probably would be easier to just go ahead and create the tables in production (T429339).

I'd forgotten to post QA results for this because it had a dependency on the dialog.

• The dialog appears only when the backend has signalled it (Patch 2).