[sebhofmann]

Link to jira.

Creating a derivate only checked the pool privilege create-{base} / create-derivate, which is not bound to an object. The permission create-derivate is now checked on the parent object, so ACL rules can allow or deny it per object. The writedb check on the parent object is unchanged, so the new permission can only restrict.

Changes:

• MCRMetadataManager.create(MCRDerivate): checks create-derivate on the parent object instead of the pool privilege.
• MCRCreateDerivateServlet and MCRDefaultUploadHandler: check create-derivate on the object.
• MCR.Access.Strategy.CreatorPermissions now contains create-derivate, so creators can still add derivates to their objects.

Rules are resolved by the configured strategy. MCRDerivateIDStrategy (default) only looks at rules for the exact object ID, strategies with fallbacks (e.g. MIRStrategy) also resolve default_{base}, default_{type} and default.

Pull Request Checklist (Author)

Ticket & Documentation

• The issue in the ticket is clearly described and the solution is documented.
• Design decisions (if any) are explained.
• The ticket references the correct source and target branches.
• The fixed-version is correctly set in the ticket and matches the PR's target branch (main).

Feature & Improvement Specific Checks

• Instructions on how to test or use the feature are included or linked (e.g. to documentation).
• For UI changes: before & after screenshots are attached.
• New features or migrations are documented: MCR-3856 Migration 2026.12: create-derivate wird am Elternobjekt geprüft mycore-website#182
• Does this change affect existing applications, data, or configurations?
  • Yes: Is a migration required? If yes, describe it.
    Rules for the permission create-derivate have to be defined for objects (or via default* rules, depending on the strategy). Existing pool rules no longer apply to derivates. The migration guide entry is documented in MCR-3856 Migration 2026.12: create-derivate wird am Elternobjekt geprüft mycore-website#182.
  • Breaking change is marked in the commit message.

Testing

• I have tested the changes locally.
• The feature behaves as described in the ticket.
• Were existing tests modified?

MCR Conventions & Metadata

• MCR naming conventions are followed
• Java license headers are added where necessary.
• No default properties are hardcoded — all set via mycore.properties.

Multi-Repo Considerations

• Is an equivalent PR in MIR required?
  • If yes, is it already created?
    Not yet. modsdetails-external.xsl checks create-derivate as pool privilege and has to check it on the object.