Merged, tests made:

UPDATE ce_participants SET cep_unregistered_at = NULL WHERE cep_event_id = 3804 AND cep_unregistered_at = '20260602150230';

In T426102#11940340, @Marostegui wrote:

In T426102#11925563, @Ladsgroup wrote:

One way you can do it in mw, is to create a table with a new name, write a script to duplicate the table (it's rather easy) and drop the old one. It's a bit of work for you but could work. Regarding renaming in production, if you insist, I bring @Marostegui to check if there are other considerations beside the mw update breakage.

This is the ideal way of doing this.
However, having said that, the table is pretty small (9k rows) and just 9MB on disk. We can easily rename it in production but plenty of things can break from this (expected and unexpected).
@cmelo in order to understand the process better, how would your team monitor this operation and address breakages?

@ifried We are wondering if we will show the username who added the article int the worklist tab for the MPV, because if we do we will need to not only store it now but also listen and react to username changes.

we added it to this task T423318

we added it to this task T423318

In T425582#11895812, @Ladsgroup wrote:

I applied it as emergency but you need to follow the process + the ticket should have these fields set. See example: T419635

In T425475#11891678, @brennen wrote:

@cmelo thoughts here?

Tests Made:

Tests made:

In T420040#11840434, @Daimona wrote:

Checking in on this, what kind of feedback would you like?

Tests made:

Tests made:

In T423322#11826932, @Daimona wrote:

Have alternative storage solutions been considered? It looks like none of this was discussed in advance. Given that the data is non-critical, and also bound to expire, and a general argument in favour of simplifying the storage layout, I would consider other storage solutions before the database; at least mainstash or user preferences. Session storage might be interesting too, but that's more short-lived and probably not what we want.