Permissions Management — User Guide¶

Cesivi v1.3 | Surface: Permissions

This guide covers managing permissions on all securable objects in Cesivi: the root web, lists and libraries, individual items, folders, and files. It also covers SharePoint Groups, Permission Levels (Role Definitions), Site Collection Administrators, and Request Access settings.

1. Where to Find Permissions Settings¶

Site-Level (Web) Permissions¶

Navigate to Site Settings → Users and Permissions → Site Permissions:

/_layouts/15/user.aspx

Or use the direct modern URL:

/Permissions

List/Library Permissions¶

From the list or library: 1. Open the list settings (gear icon → List Settings) 2. Click Permissions for this list

Or directly:

/Permissions?ListName=<ListTitle>

Item or Document Permissions¶

From the item context menu (ECB — Edit Control Block): 1. Hover over an item 2. Click the three-dot menu (…) or the chevron 3. Select Manage Permissions

Or directly:

/Permissions?ListName=<ListTitle>&ItemId=<ID>

Folder Permissions¶

/Permissions?ListName=<LibraryTitle>&FolderUrl=/<LibraryTitle>/<FolderPath>

File Permissions¶

/Permissions?ListName=<LibraryTitle>&FileUrl=/<LibraryTitle>/<FilePath>/<FileName.ext>

2. Understanding Inheritance¶

All securable objects in Cesivi can either inherit permissions from their parent or have their own unique permissions.

Object	Default behavior
Root web	Always has unique permissions
Sub-site	Inherits from parent web (can be broken)
List/Library	Inherits from web (can be broken)
Item/Document	Inherits from list (can be broken)
Folder	Inherits from library (can be broken)

Inheriting state is shown by an amber banner at the top of the Permissions page:

"This list inherits permissions from its parent web."

When an object has unique permissions, the banner changes to:

"This list has unique permissions."

3. Web-Level Permissions¶

The root web's Permissions page shows all principal-to-role assignments for the entire site.

URL: /Permissions (root web) or /<subsite>/Permissions

Adding a Permission Assignment¶

Navigate to /Permissions
Click Grant Permissions (or the + Add button)
In the dialog:
Enter a user login name or group name in the User/Group field
Select a Permission Level (Full Control, Design, Edit, Contribute, Read, Limited Access)
Click Save

Removing a Permission Assignment¶

On the Permissions page, locate the user or group row
Click the × or Remove button next to the assignment
Confirm removal

Built-in Role Assignments on Root Web¶

The root web always has HasUniqueRoleAssignments = true. You cannot restore inheritance on the root web.

4. List and Library Permissions¶

Viewing List Permissions¶

Go to the list/library
Gear icon → List Settings → Permissions for this list
Or navigate directly: /Permissions?ListName=Documents

If the list inherits from the web, you will see the inheriting banner. The Add, Remove, and Edit role assignment controls are disabled until you break inheritance.

Breaking Inheritance¶

See Section 8 — Breaking and Restoring Inheritance.

Adding Permissions to a List (after breaking inheritance)¶

Click Grant Permissions
Enter the user or group
Select a permission level
Click Save

5. Item-Level Permissions¶

Item-level permissions allow you to restrict or expand access to a single list item or document, independent of the list it lives in.

Accessing Item Permissions¶

Via the ECB (Edit Control Block): 1. Hover over the item row in the list view 2. Click the dropdown chevron (▼) 3. Select Manage Permissions

Direct URL:

/Permissions?ListName=Tasks&ItemId=42

When an item inherits, the page shows:

"This item inherits permissions from its parent list."

The inheritance break/restore controls and the role assignment table are read-only until you break inheritance.

6. Folder Permissions¶

Folders in document libraries can have their own permission sets.

URL:

/Permissions?ListName=Documents&FolderUrl=/Documents/ProjectA

For nested folders:

/Permissions?ListName=Documents&FolderUrl=/Documents/ProjectA/Reports

The folder must exist in the library. If the folder cannot be found, the page shows a graceful error rather than a crash.

7. File Permissions¶

Individual files can have unique permissions separate from their containing folder or library.

URL:

/Permissions?ListName=Documents&FileUrl=/Documents/ProjectA/Proposal.docx

The system resolves the file to its underlying list item and loads the item's role assignments. If the file does not exist, the page shows a graceful "not found" message.

8. Breaking and Restoring Inheritance¶

Breaking Inheritance¶

Navigate to the Permissions page for the object
Click Stop Inheriting Permissions (or the Break Inheritance button)
A dialog appears with two options:
Copy permissions from parent — starts with a copy of the parent's assignments (safe starting point)
Start with empty permissions — removes all inherited assignments (use with caution)
Confirm

After breaking, the amber "inherits" banner is replaced by a blue/green "unique permissions" banner, and the Grant Permissions, Add/Remove buttons become active.

Restoring Inheritance¶

On the Permissions page, click Delete unique permissions or Restore Inheritance
Confirm the prompt

⚠️ Warning: Restoring inheritance permanently deletes all unique permission assignments on this object. They cannot be recovered.

After restoring, the object reverts to inheriting from its parent.

Sub-scope Behavior (clearSubscopes)¶

When you break inheritance on a list and the list contains items that previously had unique permissions, those items are not affected unless you explicitly check Clear permissions for child objects (maps to clearSubscopes=true in the REST API). This is consistent with SharePoint Server behavior.

9. SharePoint Groups¶

Groups let you manage permissions for multiple users at once.

Gallery URL: /_layouts/15/groups.aspx

Built-in Groups¶

Three groups are created automatically when a site is provisioned: - \<SiteName> Owners — Full Control - \<SiteName> Members — Edit or Contribute - \<SiteName> Visitors — Read

Creating a New Group¶

Navigate to /_layouts/15/newgrp.aspx or click Create Group on the groups gallery
Fill in:
Group Name (required, must be unique)
Description (optional)
Group Owner (defaults to current user)
Who can view/edit the membership (configures group visibility settings)
Click Create

Adding a User to a Group¶

Open the group from the groups gallery
Click Add Members (or New → Add Users)
Enter the user's login name or display name
Click OK

Via REST API:

POST /_api/web/sitegroups(<groupId>)/users
{"LoginName": "domain\\username"}

Removing a User from a Group¶

On the group's membership page, select the user
Click Actions → Remove Users from Group or click the ✕ next to the user

Via REST API:

DELETE /_api/web/sitegroups(<groupId>)/users/removebyid(<userId>)

Deleting a Group¶

From the groups gallery, open the group
Click Settings → Delete this group
Confirm

Via REST API:

DELETE /_api/web/sitegroups/removebyid(<groupId>)

⚠️ Built-in groups (Owners, Members, Visitors) can be deleted, but this breaks the role assignments that reference them. Only delete custom groups.

10. Permission Levels¶

Permission Levels (called Role Definitions internally) define a named set of permissions that can be assigned to a user or group.

Gallery URL: /_layouts/15/role.aspx

Built-in Permission Levels¶

Level	Typical Use
Full Control	Site administrators
Design	Page layout editing
Edit	Create/edit/delete items in any list
Contribute	Add/edit items in lists the user has access to
Read	View only
Limited Access	Internal — automatically granted for item-level unique-perm access

Note: The Full Control and Limited Access built-in levels cannot be deleted.

Creating a Custom Permission Level¶

Navigate to /_layouts/15/addrole.aspx or click Add a permission level on the gallery page
Enter a name and optional description
Check each individual permission (ViewListItems, AddListItems, EditListItems, etc.)
Click Create

Editing a Permission Level¶

Click the name of the permission level on the gallery page
Modify the checkboxes
Click Submit

The edit URL is:

/_layouts/15/addrole.aspx?id=<roleDefinitionId>

Deleting a Custom Permission Level¶

On the gallery page, check the box next to the custom level
Click Delete Selected Permission Levels

Or via REST:

DELETE /_api/web/roledefinitions(<roleDefinitionId>)

Built-in levels return an error on delete attempts.

11. Check Effective Permissions¶

Use Check Permissions to see what a specific user or group can actually do on a site, list, or item — accounting for group membership and explicit assignments.

URL: /_layouts/15/chkperm.aspx

With a list scope:

/_layouts/15/chkperm.aspx?obj=/<siteUrl>,<listGuid>,LIST&otype=2

Usage¶

Navigate to /_layouts/15/chkperm.aspx
Enter a user name or group name in the User/Group Name field
Click Check Now
The result table shows each permission and whether it is granted or denied

The effective permissions are computed as the union of: - Direct user assignments - Assignments via any group the user belongs to - Cesivi's Allow + Deny ACL model (if Deny rules are configured)

12. Site Collection Administrators¶

Site Collection Administrators have Full Control over all content in the site collection regardless of individual permission assignments.

URL: /_layouts/15/mngsiteadmin.aspx

Viewing Administrators¶

The page lists all users with IsSiteAdmin = true.

Adding an Administrator¶

Navigate to /_layouts/15/mngsiteadmin.aspx
Enter the user's login name in the Add users field
Click OK

Removing an Administrator¶

Select the user in the list
Click Remove Selected Users

The provisioned admin user cannot be removed as site administrator.

13. Request Access Settings¶

When users don't have access to a site or list, they can request access if this feature is enabled.

URL: /_layouts/15/reqacc.aspx

Enabling Request Access¶

Navigate to /_layouts/15/reqacc.aspx
Check Allow requests for access
Enter the email address where access requests should be sent
Click OK

Disabling Request Access¶

Navigate to /_layouts/15/reqacc.aspx
Uncheck Allow requests for access
Click OK

When disabled, users who don't have access see a generic "Access denied" page with no option to request access.

14. Sub-Site Permissions¶

Default Behavior¶

A sub-site inherits permissions from its parent web by default.

Breaking Sub-Site Inheritance¶

Navigate to the sub-site
Go to Site Settings → Users and Permissions → Site Permissions
```
/<subsite>/Permissions
```
Click Stop Inheriting Permissions
Choose copy or empty start
Confirm

Depth-2 Sub-Sites¶

Cesivi supports permission inheritance at depth 2 and beyond:

/          (root web — always unique)
/dept/     (depth-1 sub-site — may inherit from root or have unique)
/dept/hr/  (depth-2 sub-site — may inherit from dept or have unique)

Each level independently controls whether it inherits from its parent. Breaking inheritance at /dept/ does not affect /dept/hr/ — that sub-site continues to inherit from /dept/ unless you explicitly break it too.

URL Routing for Sub-Web Permissions¶

The sub-web permissions page is reached by prefixing the sub-web path:

/<subwebpath>/Permissions
/<subwebpath>/Permissions?ListName=<ListTitle>
/<subwebpath>/Permissions?ListName=<ListTitle>&ItemId=<ID>

The server resolves the correct SPWebPath context from the URL, ensuring that list and item lookups target the correct sub-web's data store. This is the behavior that was validated by PLAN-1233 and PLAN-1629.

REST API Quick Reference¶

Operation	Endpoint
Get web role assignments	`GET /_api/web/roleassignments`
Add web role assignment	`POST /_api/web/roleassignments/addroleassignment(principalid=N,roledefid=M)`
Remove web role assignment	`POST /_api/web/roleassignments/removeroleassignment(principalid=N,roledefid=M)`
Get list role assignments	`GET /_api/web/lists/getbytitle('X')/roleassignments`
Break list inheritance	`POST /_api/web/lists/getbytitle('X')/breakroleinheritance(copyRoleAssignments=true,clearSubscopes=false)`
Restore list inheritance	`POST /_api/web/lists/getbytitle('X')/resetroleinheritance`
Get item assignments	`GET /_api/web/lists/getbytitle('X')/items(N)/roleassignments`
Break item inheritance	`POST /_api/web/lists/getbytitle('X')/items(N)/breakroleinheritance(copyRoleAssignments=false,clearSubscopes=false)`
Get role definitions	`GET /_api/web/roledefinitions`
Get role by name	`GET /_api/web/roledefinitions/getbyname('Full Control')`
Create role definition	`POST /_api/web/roledefinitions`
Delete role definition	`DELETE /_api/web/roledefinitions(N)`
Get site groups	`GET /_api/web/sitegroups`
Create group	`POST /_api/web/sitegroups`
Delete group	`DELETE /_api/web/sitegroups/removebyid(N)`
Add user to group	`POST /_api/web/sitegroups(N)/users`
Remove user from group	`DELETE /_api/web/sitegroups(N)/users/removebyid(M)`
Check effective permissions	`GET /_api/web/getusereffectivepermissions('loginName')`
Has unique role assignments	`GET /_api/web/lists/getbytitle('X')?$select=HasUniqueRoleAssignments`

WCAG 2.1 AA Conformance¶

Status: ✅ PASS — v1.4 Group A1 (PLAN-1643, 2026-05-29)

All 15 registered Permissions surface routes pass axe-core WCAG 2.1 AA scanning with zero critical or serious violations (KnownAxeAcceptances = []).

Key Accessibility Features¶

Feature	Implementation
Skip navigation	`<a class="skip-link" href="#cesivi-main-content">` on every page via `_ModernLayout`
Focus visibility	Non-zero `:focus-visible` outline via `_a11y.css`
Inheritance state banner	`role="status"` — announced without requiring a page alert
Break-inheritance modal	`role="dialog"` + `aria-modal="true"` + `aria-labelledby` — Narrator traps virtual cursor
Add-permission modal	Same pattern
Per-row Remove buttons	`aria-label="Remove {role} permission from {principal}"` — context-rich accessible name
Restore Inheritance button	`aria-label="Restore permission inheritance from parent"`
Check Permissions search	`<label for="chkperm-query">` (not placeholder-only)
Effective permissions table	`<caption class="visually-hidden">` + `scope="col"` on all column headers
Permission-level categories (Addrole)	`<fieldset class="perm-section">` + `<legend>` for List, Site, Personal
Allow access requests (Reqacc)	Radio group in `<fieldset>/<legend>`
Add Site Admin modal (Mngsiteadmin)	`role="dialog"` + `aria-modal` + label-for on login input
All admin tables	`scope="col"` on every `<th>` (Groups, Role, People, User, ChkPerm)

Test Coverage¶

Suite	File	Count	Category trait
Axe gate	`PermissionsA11yTests.cs`	5 Fact tests / 15 routes	`A11yGate`
Keyboard	`PermissionsKeyboardTests.cs`	18 tests	`A11yKeyboard`
Screen-reader	`PermissionsScreenReaderTests.cs`	17 tests	`A11ySR`

Permissions Management — User Guide¶

Table of Contents¶

1. Where to Find Permissions Settings¶

Site-Level (Web) Permissions¶

List/Library Permissions¶

Item or Document Permissions¶

Folder Permissions¶

File Permissions¶

2. Understanding Inheritance¶

3. Web-Level Permissions¶

Adding a Permission Assignment¶

Removing a Permission Assignment¶

Built-in Role Assignments on Root Web¶

4. List and Library Permissions¶

Viewing List Permissions¶

Breaking Inheritance¶

Adding Permissions to a List (after breaking inheritance)¶

5. Item-Level Permissions¶

Accessing Item Permissions¶

Item Inheriting Banner¶

6. Folder Permissions¶

7. File Permissions¶

8. Breaking and Restoring Inheritance¶

Breaking Inheritance¶

Restoring Inheritance¶

Sub-scope Behavior (clearSubscopes)¶

9. SharePoint Groups¶

Built-in Groups¶

Creating a New Group¶

Adding a User to a Group¶

Removing a User from a Group¶

Deleting a Group¶

10. Permission Levels¶

Built-in Permission Levels¶

Creating a Custom Permission Level¶

Editing a Permission Level¶

Deleting a Custom Permission Level¶

11. Check Effective Permissions¶

Usage¶

12. Site Collection Administrators¶

Viewing Administrators¶

Adding an Administrator¶

Removing an Administrator¶

13. Request Access Settings¶

Enabling Request Access¶

Disabling Request Access¶

14. Sub-Site Permissions¶

Default Behavior¶

Breaking Sub-Site Inheritance¶

Depth-2 Sub-Sites¶

URL Routing for Sub-Web Permissions¶

REST API Quick Reference¶

WCAG 2.1 AA Conformance¶

Key Accessibility Features¶

Test Coverage¶