Support Fine-Grained SharePoint Permissions

[christopinka]

Support Fine-Grained SharePoint Permissions via Graph API

Problem

Graph API's /drive/items/{id}/invite endpoint only supports basic read and write roles. This is insufficient for migrating from systems like Quip that have granular permissions (Owner, Edit, Comment, View).

Currently, we must use SharePoint REST API for fine-grained control, requiring:

• Separate authentication flow
• Breaking permission inheritance per file
• Managing SharePoint-specific role definition IDs (e.g., 1073741827 for Contribute)

Proposed Solution

Extend Graph API to support SharePoint's native permission levels:

Current:

POST /sites/{site-id}/drive/items/{item-id}/invite
{
  "roles": ["read", "write"]
}

Proposed:

POST /sites/{site-id}/drive/items/{item-id}/invite
{
  "roles": ["read", "write", "contribute", "fullControl", "viewOnly", "design"]
}

Or support custom permission levels:

{
  "customRole": {
    "basePermissions": ["viewListItems", "addListItems", "editListItems"]
  }
}

Use Case

Migrating from Quip to SharePoint requires preserving:

• Owner → Full Control
• Edit → Contribute/Edit
• Comment → Custom (View + Add Comments)
• View → Read

Current Workaround

Use SharePoint REST API /_api/web/lists/.../roleassignments/addroleassignment with hardcoded role IDs, requiring dual API integration.

Impact

• Simplifies migration tooling
• Maintains Graph API as single source of truth
• Avoids mixing Graph + SharePoint REST APIs
• Aligns with Graph API's comprehensive coverage of other Microsoft 365 services (Teams, Exchange, Planner all expose fine-grained permissions)

Inconsistency

Graph API exposes detailed permission models for mailbox folders, Teams channels, and printer shares, but not for SharePoint—despite SharePoint being a core Microsoft 365 workload.