Default Policy Initialization

[mariajgrimaldi]

Description

The service must ensure that the default policies defined in authz.policy are available in the backend datastore (MySQL). These policies should be loaded exactly once during service initialization. Re-running the initialization should not create duplicates or alter the datastore if the default policies are already present.

Problem

• Initialization dependency: The enforcer relies on default policies being present in the datastore to enforce rules immediately after startup.
• Duplicate risk: If initialization is run multiple times, current behavior inserts policies again, potentially creating duplicates.
• Consistency requirement: The database state should remain stable across runs; initializing twice should have no side effects.

Requirements

1. Load the default policies from authz.policy into the datastore during service initialization.
2. Ensure idempotency: re-running initialization when defaults already exist must result in no changes.
3. Confirm that after initialization, the service always has access to the required default policies for enforcement.

Acceptance Criteria

• On first initialization, all default policies from authz.policy are inserted into the datastore.
• On subsequent initializations, no duplicates are created and the datastore state remains unchanged.
• The service can immediately enforce policies using the default set after startup.

Notes

• This issue is separate from runtime lifecycle management of policies, but complements it by ensuring a consistent baseline.
• Duplicate handling here is preventive: initialization should be idempotent by design, not by relying on duplicate cleanup later.

[bmtcril]

We should remember as part of this that there can be many processes starting up around the same time, each trying to initialize the datastore. So there is a potential for race conditions and database contention there, as well as cache sync issues. I'm almost thinking that we should do this as a migration instead, then work out the complexities of overriding the default policy separately. I'm still not 100% sure we want to support overriding the default policy, since a number of assumptions will be baked into the default system checks.

[mariajgrimaldi]

@bmtcril I was thinking about doing this as a tutor init job, what do you think? I already implemented the loading logic here: https://github.com/openedx/openedx-authz/pull/75/files#diff-cbf73ef2fd449694410706af530d33652270cccd5a9c4cf56b49c14ce4c87581

[bmtcril]

@mariajgrimaldi I think that makes sense as long as we can do it in a way that is:

• Idempotent
• Non-destructive of non-default permissions (or capable of restoring that state)
• Does not leave orphans