Allow system policies to enforce an explicitly configured default value
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 68/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- php
- Domain
- authorization
Research direction
Start at PolicySource::loadSystemPolicy() and trace how explicit system configuration becomes a PolicyLayer in direct and bulk policy loading. Add coverage for absent, default-valued, and non-default values with both override settings, including conflicting group or user layers and rule counts. Done means explicit default values preserve their configured override rule while absent configuration keeps the fallback behavior.
Written by the indexing model from the issue text.
Description
Context
The policy framework currently cannot fully distinguish these two system-level states:
- the policy was never configured and uses its built-in default;
- an administrator explicitly saved that same default value and disabled lower-scope overrides.
This became visible while implementing #8423, but it is a generic policy framework problem.
For example, if a boolean policy has:
default = false
an administrator should be able to save:
value = false
allowChildOverride = false
This should mean that the policy stays disabled and lower scopes cannot enable it.
Current behavior
PolicySource::loadSystemPolicy() checks whether the system value was explicitly persisted.
However, when the stored value is equal to the default and allowChildOverride = false, the loaded PolicyLayer still becomes overridable.
As a result, an administrator cannot enforce an explicitly selected default value.
This affects the generic policy framework, not only signature rejection.
Goal
Keep the distinction between:
no explicit system policy
and:
explicit system policy whose value is equal to the default
An explicitly persisted system policy must keep its configured override rule even when its value is equal to defaultSystemValue().
Expected behavior
No explicit system configuration
When the policy key has never been configured:
value = defaultSystemValue()
allowChildOverride = true
scope = system
The built-in default remains a fallback.
Explicit value different from the default
Keep the current behavior.
Explicit value equal to the default
If the administrator explicitly saves:
value = <default>
allowChildOverride = false
the resolved system layer must keep:
allowChildOverride = false
If the administrator explicitly saves:
value = <default>
allowChildOverride = true
the resolved layer must remain overridable.
The fact that the value matches the built-in default must not remove the administrator's choice.
Acceptance criteria
- The policy runtime distinguishes an absent system configuration from an explicitly persisted default value.
- An explicitly persisted default value with
allowChildOverride = falsecannot be overridden by lower scopes. - An explicitly persisted default value with
allowChildOverride = trueremains overridable. - A policy that has never been configured keeps the current fallback behavior.
- Non-default system values keep their existing behavior.
- Resolution remains consistent between direct policy reads and bulk policy loading.
- Rule counts continue to recognize an explicitly configured system policy even when its value equals the default.
Tests
Cover at least:
| Explicit system value | Equals default | allowChildOverride | Expected |
|---|---|---|---|
| no | n/a | n/a | built-in default, overridable |
| yes | yes | false | enforced |
| yes | yes | true | overridable |
| yes | no | false | enforced |
| yes | no | true | overridable |
Also verify resolution with a conflicting group or user layer so the test proves that the override rule affects the effective policy, not only the serialized PolicyLayer.
Related
#8405
#8423
Out of scope
- rejection-specific exceptions in the policy framework;
- changes to policy precedence;
- changes to the meaning of
defaultSystemValue(); - new policy scopes.
- Dominant language
- PHP
- Stars
- 818
- Forks
- 146
- Avg merge
- 6h 48m
- Merged PRs (30d)
- 622
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from LibreSign/libresign
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
LibreSign/libresign#8284 · 5 comments ·
Maintainers usually reply within 1 day
-
backend enhancement php
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
backend php
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
frontend javascript
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
frontend javascript
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
All issues in LibreSign/libresign
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
sync-en
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
sync-en
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Yoast/wordpress-seo#23658 ·
Maintainers usually reply within 3 days
-
fixed
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
firefly-iii/firefly-iii#12934 · 2 comments ·
Maintainers usually reply within 1 day