Issue Summary

Admins need to understand why a user lost access to a specific page. Today, when access changes are caused indirectly (e.g., global/space permission changes or parent restrictions), there is no clear trace on the affected page itself. This makes root cause analysis and compliance reporting difficult.
We’d like to enhance the audit log so that effective access changes are visible at the page level when they are caused by:

• Global permission added/removed (including anonymous)
• Space permission added/removed (including anonymous)
• Content restriction added/removed on ancestor pages
  Reference:  View the audit log

Current Behavior & Gap

Audit logs currently show:

• Global permission changes
• Space permission changes
• Content restriction changes (on the item where the change occurred)
  But they do not clearly show:
• When a page’s effective access changed because of:
• Global/space permission updates
• Restrictions added/removed on a parent page
• Moving a page under a different parent/space with different permissions
  From the page’s perspective, access “just disappears” with no local audit entry explaining why.

Requested Behavior

For any permissions-related event that changes effective access to pages:
Record an entry at the page level indicating:

• That effective access changed (e.g., “group X lost read access”)
• The timestamp
• A reference to the triggering event (e.g., link/ID of the global, space, or parent restriction change)

Include page-level entries when:

• Global permissions change
• Space permissions change
• An ancestor page’s restrictions change
• (Nice-to-have) A page is moved and its effective permissions change as a result

Outcome

From a page’s audit history, an admin should be able to answer:
“Did access to this page change?”
“When did it change?”
“Which higher-level permission or restriction change caused it?”
This would significantly improve debuggability, admin trust in the audit log, and support for compliance requirements.