Locking one component to one team
Legal-approved content sometimes has to be editable by one group only, while the rest of the page stays open. AEM has no built-in way to do that, so we built one that can’t take a repository down.
Client
- Enterprise client
- Name withheld
Our role
- Architecture
- Implementation
Stack
- Java / OSGi
- Jackrabbit access control
- Sling filters
- Touch UI
The challenge
AEM permissions are path-based: you can lock a page, but not “this one component on this page”. Locking the component type everywhere only hides it from the insert list; it doesn’t stop edits to existing instances.
The lesson
The first version set permissions at startup with repoinit. On an environment where the target page didn’t exist yet, that failed hard enough to stop the repository from starting. Node names also differ between environments. So permissions moved into a normal OSGi service that finds the component by type and applies access rules safely, logging instead of crashing if anything is missing.
The approach
- One small config per rule: page, component type, allowed group
- A request filter rejects saves with a readable message
- Blocked authors see a stand-in dialog instead of editable fields
- A post-processor acts as the final backstop
- Group permissions defined as code per environment
Getting the author experience right meant reading Adobe’s own editor code: saves expect a particular HTML response, and a custom dialog needs one case-sensitive class name or the whole page locks.
Results
- Reviewable, server-enforced governance per component
- No risk to repository startup
- Reusable notes for any custom dialog or save error
Is your platform telling you something?
An AEM health check is the fastest way to find out what’s fragile before it breaks.
Book a health check