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

New configuration properties with category system and initial value(s) are NOT added to existing nodes

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • None
    • 14.0.0
    • None
    • None
    • Platform 221 - 14.0 CodeFreeze

    Description

      The logic in ConfigurationConfigService to add/apply properties with category system (having an initial value) turns out to be unexpected flawed to only do this for new (jcr) nodes.

      The expected logic (and something we now depend on for v14 upgrade) is that it would do so even when that (jcr) node exists but the property is new, and also only when that property is newly introduced through the bootstrap.

      With the current behavior, critical additions in our new v14 security model (and specifically the new hipposys:userrole properties in AuthRole nodes) will not be added to already existing (jcr/configuration) nodes, thereby breaking the new security setup, when upgrading to v14.

      Initial testing didn't discover this, yet, because we also retain the existing users/groups on an AuthRole, and as our (test) users are typically also (still) members of those groups, the domain security configuration still 'works' as expected, but not in the intended new way!

      Fixing this is relatively trivial though. I'll adjust the current behavior as follows (and as IMO was intended/expected from the beginning):

      • apply a configuration property
        •  when
          • using force apply
          • or for new configuration properties (not in baseline yet)
          • or when configuration property is different from baseline
        •  and
          • property category is config (.meta:category: config)
          • or (.meta:category: system)
            • the property doesn't exist in the repository
            • or for multi-valued properties with .meta:add-new-system-values: true

      Attachments

        Activity

          People

            Unassigned Unassigned
            adouma Ate Douma (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: