[MGNLRES-323] Automatically remove outdated JCR hotfix overrides Created: 11/Mar/19  Updated: 28/Jun/22  Resolved: 28/Jun/22

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Major
Reporter: Christopher Zimmermann Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLRES-324 Manually remove outdated JCR hotfix o... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: LD2021
Team: Nucleus

 Description   

User Story:

As a developer or administrator I want to ensure that any JCR hotfixes are removed when I deploy a new version of my project, so that the resource changes that are in my new version take effect as expected. 

Problem Details:

A common problem is that authors override a file-provided resource (for example a YAML app definition) in AdminCentral Resources app by "editing it" which creates a JCR item, a "hotfix". This JCR Item overrides the YAML file. So far so good. The problems come next:

  • Development team then makes a change to the YAML app definition, these changes are not reflected on the website. Why? (Oh yeah, that file is being overridden.)
  • What is the best route to get that "hotfix" out of JCR and into the YAML definition? (So the fix is not forgotten.)

Suggested Solution:

  • RemoveAndBackupResources UpdateTask 
    • Provide a convenient update task which scans all resources (or you can limit it to certain paths), removes JCR "hotfixes", and optionally saves them to a specific directory location with a timedate and maybe version stamp.
    • It must take effect on Author and public instances.

Generated at Mon Feb 12 06:49:34 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.