Restore old behavior for Feature Flags

[dario-daza]

Proposed Changes

• Restore old functionality for Feature Flags:

  • No flag: feature ON
  • flag OFF: feature OFF
  • flag ON: feature ON

• Add postman test to avoid future modifications

This PR fixes: #35409

[claude]

Claude finished @dario-daza's task in 1m 34s —— View job

---

Rollback Safety Analysis

• Gather context
• Read rollback-unsafe categories reference
• Get full PR diff
• Analyze diff against all unsafe categories
• Post final analysis

---

Result: Pull Request Unsafe to Rollback

• Category: M-3 — REST API Contract Change
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: This PR removes the special FEATURE_FLAG_ branch in ConfigurationResource.recoveryFromConfig() that returned a boolean via Config.getBooleanProperty(key, false). After this fix, FEATURE_FLAG_* keys fall through to Config.getStringProperty(key, "NOT_FOUND"), returning strings (e.g. "true", "false", or the properties-file default). Rolling back from this fix to the previous release reinstates the boolean return type — any Angular or headless client that has been updated to do string comparisons (=== "true" / === "false") on GET /api/v1/configuration/config?keys=FEATURE_FLAG_* responses will silently mis-evaluate every feature gate. Unconfigured flags also switch from the properties-file default (typically "true") back to the hardcoded false boolean, disabling features that should be on by default.
• Code that makes it unsafe:
  dotCMS/src/main/java/com/dotcms/rest/api/v1/system/ConfigurationResource.java, removed lines ~143–145:

  } else if (key.startsWith("FEATURE_FLAG_")) {
      return Config.getBooleanProperty(key, false);

  The Postman tests in this PR also confirm the new string contract (pm.expect(typeof value).to.eql("string")) — clients updated against this contract will break after rollback.
• Alternative (if possible): If a rollback is needed, simultaneously revert any Angular/frontend code that was updated to treat feature-flag values as strings, and verify that no headless clients are performing string comparisons on FEATURE_FLAG_* responses. After rollback, unconfigured flags will revert to boolean false — manually enable any features that rely on the "no flag = on" default.

No other unsafe categories apply: there are no database schema changes, Elasticsearch mapping changes, content model changes, push publishing bundle changes, or OSGi interface changes in this PR.

[claude]

PR Review in Progress

• Gather context
• Read changed files
• Review ConfigurationResource.java changes
• Review Postman collection changes
• Post final review

View job run

[claude]

Pull Request Unsafe to Rollback!!!

• Category: M-3 — REST API Contract Change
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: This PR removes the special FEATURE_FLAG_ branch in ConfigurationResource.recoveryFromConfig() that returned a boolean via Config.getBooleanProperty(key, false). After this fix, FEATURE_FLAG_ keys fall through to Config.getStringProperty(key, NOT_FOUND), returning strings (e.g. "true", "false", or the properties-file default). Rolling back from this fix to the previous release reinstates the boolean return type — any Angular or headless client that calls GET /api/v1/configuration/config?keys=FEATURE_FLAG_* and does a string comparison (=== "true" / === "false") will silently mis-evaluate every feature gate. Unconfigured flags would also switch from effectively "true" (properties-file default) back to false (boolean hardcoded default), disabling features that should be on.
• Code that makes it unsafe:
  dotCMS/src/main/java/com/dotcms/rest/api/v1/system/ConfigurationResource.java, removed lines ~145–147:

  } else if (key.startsWith("FEATURE_FLAG_")) {
      return Config.getBooleanProperty(key, false);

  After rollback this branch is restored, changing the JSON value type for all FEATURE_FLAG_* keys from string → boolean and the default from the properties-file value (usually "true") back to false.
• Alternative (if possible): If a rollback is needed, simultaneously revert any Angular/frontend code that was updated to treat feature-flag values as strings, and verify that no headless clients are performing string comparisons on FEATURE_FLAG_* responses.