Feature Better configuration management

[mohityadav766]

Adding a configSource property to OpenMetadata settings that lets operators control where
configuration is read from:

• ENV - Always read from YAML/environment variables (UI shows read-only indicator, API rejects
  updates)
• DB - Always read from database (current default behavior)
• AUTO - Last-write-wins based on timestamps

Problem solved: Previously, settings stored in the database on first startup would ignore
subsequent ENV/YAML changes, confusing operators who expected config file changes to take effect.

Scope:

• Dual-source settings (auth, email, SCIM, etc.) default to AUTO mode
• DB-only settings (login config, search settings, etc.) default to DB mode
• UI shows "Managed by Environment" indicator and hides edit buttons for ENV-managed settings
• Backend validates and rejects API updates when configSource=ENV

[github-actions]

TypeScript types have been updated based on the JSON schema changes in the PR

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	65.87% (55672/84517)	44.97% (28795/64030)	47.83% (8763/18323)

[github-actions]

TypeScript types have been updated based on the JSON schema changes in the PR

[gitar-bot]

Reviewing your code

Code Review 👍 Approved with suggestions 1 resolved / 3 findings

Well-designed configuration source management feature with ENV/DB/AUTO modes. Both previous findings remain unresolved: envSyncTimestamp parameter still always null, and IllegalArgumentException still used for config protection (HTTP 400 vs 403).

💡 Bug: envSyncTimestamp parameter is always null in shouldUseEnvValue call

📄 openmetadata-service/src/main/java/org/openmetadata/service/resources/settings/SettingsCache.java

In the syncConfigWithSource method, shouldUseEnvValue is called with null for the envSyncTimestamp parameter (4th parameter), but envSyncTimestamp is never retrieved from the database even though the column exists and a getter method getEnvSyncTimestamp is defined.

boolean shouldUseEnv =
    ConfigSourceResolver.shouldUseEnvValue(
        configSource,
        currentEnvHash,
        storedEnvHash,
        null,  // envSyncTimestamp is always null
        dbModifiedTimestamp,
        applicationStartTime);

While the current implementation of shouldUseEnvValue doesn't use envSyncTimestamp (it's accepted but not referenced in the method body), passing null suggests this was either forgotten or left for future implementation. If this parameter is intended to be used, the method should retrieve it via Entity.getSystemRepository().getEnvSyncTimestamp(settingsType.toString()).

Impact: Low currently since the parameter isn't used, but this could cause issues if the logic is extended to use envSyncTimestamp in the future.

💡 Quality: IllegalArgumentException may not be appropriate HTTP status for config protection

📄 openmetadata-service/src/main/java/org/openmetadata/service/resources/system/SystemResource.java 📄 openmetadata-service/src/main/java/org/openmetadata/service/resources/system/SystemResource.java

When a user tries to update an ENV-managed configuration, the code throws IllegalArgumentException which typically maps to HTTP 400 (Bad Request). However, this scenario might be better represented as HTTP 403 (Forbidden) or HTTP 409 (Conflict) since:

1. The request format is valid (not a "bad request")
2. The user is authorized but the operation is forbidden due to configuration policy
3. There's a conflict between the requested action and the system's configuration state

Suggested fix: Consider using a more specific exception that maps to the appropriate HTTP status code, such as:

• Custom exception mapped to 403 Forbidden, or
• Use jakarta.ws.rs.ForbiddenException if the intent is to indicate access denial
• Use a custom exception mapped to 409 Conflict if indicating a state conflict

This would provide clearer semantics to API consumers about why their request was rejected.

✅ 1 resolved

✅ Edge Case: Incomplete SettingsType handling in convertToOpenMetadataConfig

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/SystemRepository.java
The convertToOpenMetadataConfig method has a switch statement that only handles 8 SettingsType values (EMAIL_CONFIGURATION, AUTHENTICATION_CONFIGURATION, AUTHORIZER_CONFIGURATION, etc.) but returns null for all other cases via the default branch.

This means configurations like LINEAGE_SETTINGS, LOGIN_CONFIGURATION, OPEN_LINEAGE_SETTINGS, and ENTITY_RULES_SETTINGS (which also have configSource added in the schema changes) will bypass the ENV protection check in isUpdateAllowed() because convertToOpenMetadataConfig returns null, causing isUpdateAllowed() to return true.

Impact: Users could potentially modify settings via API even when they should be protected by configSource=ENV.

Suggested fix: Add all configuration types that implement OpenMetadataConfig to the switch statement, or use reflection/interface detection to handle all types generically.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud