Interface for per-DO access control in "restricted" application mode. 87 lines. The Javadoc states: "All methods of this interface should be implemented by every DOAccessControl class needed by every DO class in access-type='restricted' application mode (productive mode)." — this is for production deployments where access control must be enforced at the DO level.

Five CRUD check methods:

• checkFind(List list, PFUserDO user) — post-query filtering. The list is already loaded from the database. The implementation can remove entries the user shouldn't see (returns filtered list). This is the only method that mutates the list — all others throw exceptions on denial
• checkLoad(Object obj, PFUserDO user) — called when loading a single object by ID. If the user shouldn't see it, throws AccessException
• checkSave(Object obj, PFUserDO user) — called before INSERT. May modify object properties (e.g. set owner to current user) to satisfy access rules
• checkUpdate(Object obj, PFUserDO user) — called before UPDATE. Same modification capability as save
• checkDestroy(Object obj, PFUserDO user) — called before DELETE. No modification — just allow or deny

Design philosophy: CheckSave/CheckUpdate can mutate the object to enforce access rules (e.g. force-owning the object to the current user), while CheckLoad/CheckDestroy cannot — they either allow or throw. This is the pre-AOP era approach to access control, before @PreAuthorize annotations and Spring Security method security became standard. The interface uses raw Object types — no generics — because it operates at the framework level where DO types aren't known at compile time.

Interface for per-DO access control in "restricted" application mode. 87 lines. The Javadoc states: "All methods of this interface should be implemented by every DOAccessControl class needed by every DO class in access-type='restricted' application mode (productive mode)." — this is for production deployments where access control must be enforced at the DO level.

Five CRUD check methods:

• checkFind(List list, PFUserDO user) — post-query filtering. The list is already loaded from the database. The implementation can remove entries the user shouldn't see (returns filtered list). This is the only method that mutates the list — all others throw exceptions on denial
• checkLoad(Object obj, PFUserDO user) — called when loading a single object by ID. If the user shouldn't see it, throws AccessException
• checkSave(Object obj, PFUserDO user) — called before INSERT. May modify object properties (e.g. set owner to current user) to satisfy access rules
• checkUpdate(Object obj, PFUserDO user) — called before UPDATE. Same modification capability as save
• checkDestroy(Object obj, PFUserDO user) — called before DELETE. No modification — just allow or deny

Design philosophy: CheckSave/CheckUpdate can mutate the object to enforce access rules (e.g. force-owning the object to the current user), while CheckLoad/CheckDestroy cannot — they either allow or throw. This is the pre-AOP era approach to access control, before @PreAuthorize annotations and Spring Security method security became standard. The interface uses raw Object types — no generics — because it operates at the framework level where DO types aren't known at compile time.