GetChanges API does not report RoleAssignmentDelete for folders when inherited permission is removed from parent library/folder

[sargis-hayrapetyan]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

SharePoint REST API

Developer environment

None

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

Request is done using Application Permissions

Describe the bug / error

When using the SharePoint GetChanges API at the list scope, I observed the following behavior:

Adding unique role assignments to a parent folder or document library automatically applies the same permission to child folders (if the child folder has broken role inheritance). This addition is correctly reported as RoleAssignmentAdd in the GetChanges API for child folder.

Removing those permissions from the parent also removes the permission from the child folder, but GetChanges does not report a RoleAssignmentDelete for the child folder.

Example:
https:///sites/mysite/_api/web/lists/GetById('driveId')/GetChanges
query:

{
  "ChangeTokenStart": { "StringValue": "<start_of_token>" },
  "ChangeTokenEnd": { "StringValue": "<end_of_token>" },
  "Update": true,
  "DeleteObject": true,
  "Move": true,
  "Restore": true,
  "RecursiveAll": true,
  "SystemUpdate": true,
  "Add": true,
  "Rename": true,
  "Item": true,
  "RoleAssignmentAdd": true,
  "RoleAssignmentDelete": true
}

Steps to reproduce

1. Create a folder inside the document library and break inheritance to give it unique role assignments.
2. Add a unique role assignment to the document library.
3. Call GetChanges at the list scope and verify that for the folder RoleAssignmentAdd ChangeType is present
4. Remove the previously added role assignment from the document library.
5. Call GetChanges again at the list scope.

Actual Result:

The folder no longer has the inherited permission, but no RoleAssignmentDelete or any other change is returned.

Expected behavior

The folder should have a RoleAssignmentDelete change returned by the API, reflecting that the permission was removed.

[Ashlesha-MSFT]

Hello @sargis-hayrapetyan,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.