Skip to content

Support enable/disable rules on request configuration rules#12702

Open
offtherailz wants to merge 1 commit into
geosolutions-it:masterfrom
offtherailz:security-rules-enabled
Open

Support enable/disable rules on request configuration rules#12702
offtherailz wants to merge 1 commit into
geosolutions-it:masterfrom
offtherailz:security-rules-enabled

Conversation

@offtherailz

@offtherailz offtherailz commented Jul 21, 2026

Copy link
Copy Markdown
Member

Fixes #12704

Summary

  • Entries in requestsConfigurationRules (and legacy authenticationRules) can now declare an enabled property: a plain boolean or a plugin expression string (same syntax as cfg.disablePluginIf), e.g. "{includes(state('usergroups'), 'editor')}".
  • Rules without enabled keep the current behaviour (always applied).
  • Reuses the existing PluginsUtils.handleExpression/getMonitoredState machinery, no new expression syntax introduced.
  • Docs updated in local-config.md.

Test plan

  • Added tests in SecurityUtils-test.js: no enabled property, enabled: false, expression resolving false, expression resolving true against state('usergroups').
  • Ran the full SecurityUtils-test.js suite locally via karma (chrome headless) — 59/59 passing, no regressions.

Each entry in requestsConfigurationRules (and legacy authenticationRules)
can now set enabled to a boolean or a plugin expression string, evaluated
the same way as cfg.disablePluginIf (e.g. via state('usergroups')). Lets
an auth/header rule apply only to matching user groups.
@tdipisa

tdipisa commented Jul 21, 2026

Copy link
Copy Markdown
Member

Converted to draft waiting for 2026.02.00 to be out

@tdipisa
tdipisa marked this pull request as ready for review July 22, 2026 16:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support enable/disable rules on request configuration rules

3 participants