Bug: Global Templates not migrated

[sbishel]

I actually don't think we need to do anything for this issue, but wanted to bring it to attention.

Because we use INNER JOIN channels AS C ON C.Id=B.channel_id on our migrations templates do not get migrated. However. we do delete the template boards from the blocks table.

DELETE FROM {{.prefix}}blocks WHERE type = 'board';

As part of the start up process global templates are checked and re-added. Therefore, everything works fine.

This leaves orphaned block records in the database, which really causes no issues, however, it just makes counting for post conversion a bit more complicated.

We could... 1 - Fix in migration code to migrate templates, then won't need re-added

• risky, changes to migration code

2 - Remove template blocks in migration code, allow new templates to be created

• remove orphans, there may be other orphans that we remove and counts still wouldn't match up.

3 - Do nothing. Causes some additional rows we would need to account for during migration testing, otherwise no harm.

• probably the best action for now is no Action.

[wiggin77]

While I would prefer we fix the migration so we are not stuck with it after shipping, I also think we need an orphan cleanup task as well.

[mgdelacroix]

Templates were supposed to be migrated in a data migration, as we needed to duplicate them for every team that exists, and then removed in the SQL migration. At some point the code for this was removed, as the TemplatesToTeamsMigrationKey still exists in the current codebase. This would cause the migration to delete templates that the user might have created as well, right? If that's the case we would be losing data, which potentially changes the severity of the issue

@jespino

[wuwinson]

@wuwinson Test board templates on public and private channels.

[wiggin77]

Templates were supposed to be migrated in a data migration, as we needed to duplicate them for every team that exists, and then removed in the SQL migration.

@mgdelacroix the global templates are in team_id=0 and we do not duplicate them to each team.

[wiggin77]

To address this I would add a cleanup service that runs on startup and detects then removes any orphaned records. Question is, should this be for 7.2, 7.3 or never? @wuwinson @sbishel

[wuwinson]

@wiggin77 What are the downsides, if any, of leaving orphaned records?

[wiggin77]

@wiggin77 What are the downsides, if any, of leaving orphaned records?

The card counts will be off by the number of orphaned card blocks. Basically all the cards in the templates before migration. Note, there are already a lot of orphaned blocks in community for any boards that have been around for multiple releases.

Other than counts, I don't see any downside. We can create a cleanup service in any release to clean them up.

[wuwinson]

Got it, thanks @wiggin77. Will we need to do cleanup work to verify if our migrations are successful or are we able to factor in the orphans as part of the verification?

[wiggin77]

I'm not sure what the post migration checks involve. I think they are scripts that counts various entities pre and post migration so those numbers won't add up. However we can figure out how many template cards get orphaned and still reconcile.

[wuwinson]

Thanks for clarifying @wiggin77! I don't see any benefits of doing the clean up work in that case. Closing this out. @sbishel Feel free to re-open if there are other reasons we may have missed. Thanks

[wiggin77]

@wuwinson I think we need to do something in a future release to clean up the orphans. I think this ticket should remain open and deferred to 7.3

[sbishel]

@wuwinson @wiggin77 - I can make the adjustment between pre and post migration counts. That is how I found the issue existed. Otherwise, everything works fine. But agree, we should keep this ticket open for a future release to remove orphan records.

[wuwinson]

Sounds good, re-opening and tentatively queueing it up for 7.3.

[wuwinson]

Tracked on this card. Closing out this ticket.