Add display placeholder for EAA edits in production

[mwiencek]

Problem

This is a prerequisite step for IMG-84 / PR #3150.

If you were to submit any of the new EAA edits on the beta server once it's deployed there, and then try to load any of those edits in production (whether directly or via an edit listing), then it would cause an ISE in production.

Pulling all of the display code for these new edit types would basically mean having to merge a very large chunk of the event-art-archive branch, as they depend heavily on changes to the Data:: and Entity:: layers.

Solution

This patch just adds a placeholder component, BetaOnlyEdit, which links to the edit on the beta server (saying that it can only be viewed there temporarily).

Testing

Tested manually on my local development server.

[yvanzo]

• The code looks good. I also checked the diffs to the branch mwiencek/event-art-archive.
• But the commit message(s)/pull request description(s) are lacking context and references to the main pull request and ticket.
• Also the deployment plan is unclear as we might want to keep the React component BetaOnlyEdit and its translations in the final release, but not the rest of the code, which is either temporary or borrowed (and would be missing the context of their original commits.)

I would suggest to split into two different pull requests:

The 1st PR:

• would contain the added file root/edit/details/BetaOnlyEdit.js only,
• would target the branch production (still),
• could be merged and then immediately carried forward to the other branches for translations, since this change would neither rely on nor conflict with anything else.

The 2nd PR:

• would contain the rest of the (borrowed/temporary) code,
• would target the branch production (still),
• could be merged only after carrying the changes from the 1st PR forward to the other branches for translations (as suggested above),
• could be reverted on final release time from the branch production before merging the branch beta into production.

For deployment, with two such pull request, I would suggest to:

1. Merge the 1st PR into the branch production
2. Merge the branch production into master
3. Merge the 2nd PR into the branch production
4. Build production images
5. Update prod containers
6. Merge the main PR into the branch master
7. Release beta (which includes updating the POT files with the source string for the React component BetaOnlyEdit)

On final release time:

1. Revert the 2nd PR from the branch production
2. Release production (which includes merging the branch beta into production)

[mwiencek]

Thanks for checking this. Regarding the deployment, I wasn't planning to revert anything per se:

1. First I'd merge this PR into production,
2. then deploy production containers,
3. merge production into master,
4. rebase the event-art-archive branch on top of master,
5. merge event-art-archive into master,
6. then do the beta release process.

I don't see any need to revert anything in this scenario because step 4 would completely supplant the borrowed/temporary code (while leaving the BetaOnlyEdit component in place for later use). No need to worry about conflicts even, since I know the versions in the event-art-archive branch are correct, and can just use git checkout --theirs.

Edit: I updated the commit message and PR description to include a reference to IMG-84 and PR #3150. I cancelled both the CircleCI and Selenium test runs, since I only changed the commit message. (Both were passing earlier.)

[yvanzo]

I don't see any need to revert anything in this scenario because step 4 would completely supplant the borrowed/temporary code (while leaving the BetaOnlyEdit component in place for later use). No need to worry about conflicts even, since I know the versions in the event-art-archive branch are correct, and can just use git checkout --theirs.

One of the motivations was:

code […] borrowed […] would be missing the context of their original commits

Won’t step 4 remove the borrowed code from the original commits in the main pull request?

After the final release, won’t git blame show the stub commit from this pull request instead of the original commits from the main pull request?

[mwiencek]

Won’t step 4 remove the borrowed code from the original commits in the main pull request?

After the final release, won’t git blame show the stub commit from this pull request instead of the original commits from the main pull request?

That sounds right, although I also split the commits here so that they'd point to a commit specifically introducing the stub edit classes. Does that seem okay?

If you'd prefer reverting so that the files are removed and re-added, I'm okay with that too, as having split the commits should make that easier.

[yvanzo]

Thank you for having split into 3 commits with proper messages, no need for a separate PR indeed. Yes, I would still prefer reverting the 2 stub commits in master rather than cutting a part of the original commits in the main pull request.

[mwiencek]

OK, I will try to follow the detailed deployment process you outlined. 👍