Object Permissions

Object permissions define read and write access on individual documents or records.

When a user can see an object but cannot edit or approve it, compare object ACL, lifecycle status, workflow assignment, and role membership.

Object ACL

obj_acl is the effective access list stored on an object. It can contain user IDs, login names, role names, client roles, functional roles, or customer-specific permission markers.

Example pattern:

[
  "100",
  "400",
  "bereich_BUHA",
  "rolle_Administrator",
  "mandant - 0001 - Arlesheim",
  "show_App_Invoice"
]

The exact values depend on the installation. A user can receive access directly through their user ID or indirectly through one of their roles.

Read vs. Write Permission

Seeing a document is not the same as being allowed to change it.

Situation	Interpretation
User does not see the document	Missing read permission, missing client role, filter, or lifecycle visibility.
User sees the document but cannot edit	Read permission exists, write permission is missing.
User sees and edits metadata but cannot approve	Workflow action permission or lifecycle transition permission is missing.
Admin can process, normal user cannot	Object ACL, workflow assignment, or role-specific permission function differs.

Invoice-Specific Fields

For Invoice permission analysis, capture these fields from the affected object:

Field	Meaning
obj_id	Object ID used in logs and URLs.
obj_profile	Profile, e.g. creditor invoice, purchase order, receipt.
obj_lifecycle_state	Current processing status.
obj_assignee	Primary responsible user or group.
obj_assignee_type	Type of primary assignee, usually user or group.
obj_assignee2	Secondary responsible user or group.
obj_assignee2_type	Type of secondary assignee.
cq_client_accounting	Accounting client or mandate.
cq_accounting_area	Accounting area or business unit.
obj_acl	Effective permission list on the object.

Lifecycle and Workflow

Lifecycle state affects what actions are available. A user may have write permission in one state but not in another.

For example, an invoice approval action usually depends on:

• current lifecycle state,
• assigned approver,
• substitute logic if enabled,
• object ACL,
• client role,
• accounting area,
• configured permission function,
• workflow matrix or lifecycle transition rules.

Support Checklist

For a permission incident, collect:

• failing URL and action,
• current user and user roles,
• affected obj_id,
• obj_lifecycle_state,
• obj_assignee and obj_assignee2,
• cq_client_accounting,
• cq_accounting_area,
• obj_acl,
• relevant log excerpt,
• expected behavior,
• one working comparison object if available.

This makes it possible to decide whether the issue is caused by missing read permission, missing write permission, wrong assignment, wrong client, wrong lifecycle state, or customer-specific permission logic.