Migrate Research Update collaborators property from a list with one string value to just a string.

[pizzaisdavid]

As a developer, I want the database schema to be easy.

On Research Updates, the collaborators property is a list, but it should really be a string. source.

The idea:

• Confirm on all production instances via one-time script that the collaborators property is always a list with exactly one string value.
• Make all usages of collaborators for Research Updates, first check for a property called author, if it doesn't exist, use the collaborators value as a backup. Make it so new updates set both properties.
• Deploy that to all instances.
• Create a one-time migration script. For each Research Update: if the author property does not exist, take the first collaborator value and jam dat in der.
• Run the script on all production instances.
• Remove references to collaborators for Research Updates, use the author property directly.
• Deploy that to all instances.
• Create script to check that author always equals the first item in the collaborators list.
• Run that on all instances (this and the previous step may be overkill.)
• Create script to delete the collaborators list.

...well, I see why we just live with this mild inconvenience.

This process could be simplified with a maintenance downtime, but I'll think about that later.

[pizzaisdavid]

simpler way:

• Create pull request with a one-time script for checking that the collaborators property is always a list with exactly one string value.
• Create pull request with one-time database migration script, moving that value into a property called author. Also create a script for deleting the collaborators property.
• Merge and deploy that.
• Create a pull request that replaces the usages of collaborates with author.
• Merge that, but don't deploy.
• Have a scheduled downtime, during that: put the sites in "maintenance mode" (idk if that's a thing here), make a back-up, run the one-time script, confirm it worked.
• Deploy the change and take the site out of maintenance mode.
• Run the script that deletes the collaborators property.

The scripts could be combined.

[mariojsnunes]

A bit confused, you mean that for ResearchUpdate the collaborators property can be removed?
If that's the case, we can simply change the code to only use the author property, deploy and then use Retool to migrate/cleanup wherever necessary. No downtime needed.

[pizzaisdavid]

It can't really be completely removed, but the data structure can be simplified.

What it is:

what it could be:

Note: in the screenshots, these are on individual Research Update Entries, not the Research Article root object (hope that terminology isn't too confusing.)

[pizzaisdavid]

For each Research Update Entry, there will only ever be one person given credit. Different Updates can have different creators, so individual Updates still need a field.

source

I think there is no author field currently, but that is something I made up, for this simplification. If a person makes an Update for their own Research Article, they are considered a collaborator (see screenshot above.) It kinda doesn't make sense to be a "collaborator" on your own Research Article, that's why to go for a change to "author" instead of "collaborator". But we can still show "collaborator" on the user interface.

We would still want to display all the individual people who contributed, this ticket is meant to be a refactoring that simplifies the data model.