Uploaded image for project: '[Read Only] - Hippo Repository'
  1. [Read Only] - Hippo Repository
  2. REPO-2294

Autoexport overrideresidualchildnodecategory from content to config causes existing content siblings to be exported as config too

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • None
    • 14.1.0
    • None
    • None
    • Platform 222 - 14.0 Hangover, Platform 223 - 2019 Follow-up

    Description

      This is a special/edge case bug which was discovered while testing alternatives for CMS-11702 to override the residual child node category for updater scripts from content to config.

      But it may also be effective elsewhere, I just didn't test/verify that, yet.

      The problem and reproduction case is as follows:

      1. first either manually or using autoexport create a category content updater script called "foo" under /hippo:configuration/hippo:update/hippo:registry
      2. then, add "/hippo:configuration/hippo:update/hippo:registry: config" as entry to autoexport:overrideresidualchildnodecategory in hippo:configuration/hippo:modules/autoexport/hippo:moduleconfig
      3. restart (when the previous step is done through the console, autoexport config changes do require a restart)
      4. add a new sibling updater script called "bar" through the console or CMS
      5. expect only the new updater script "bar" to be exported (as config), but actually also the foo script gets exported as config
      6. result: "foo" script is now stored as both config and content in the bootstrap (and thereby effectively has become category config)

      The above behavior may cause several problems:

      • on a new deployment the content foo script will cause a warning to load, as that node already has been loaded as config
      • autoexport may get confused if/when somebody tries to modify it at runtime (I haven't tested that yet, but I wouldn't be surprised if it did)
      • the originally category content foo script now may get changed/updated (and even deleted) after a subsequent deployment when a developer changes it,  which may be undesired, or at least unexpected 

      The underlying root cause for this problem is captured in REPO-2300, but the more narrow use-case of this issue (as one effect of that problem) is solved separately, and more downstream in the DefinitionMergeService, post-processing the output of the AutoExportConfigExporter.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              adouma Ate Douma
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: