Project Roles & Permissions

1. Introduction

Access to content and administrative functions in LEAF is governed by a layered, role-based permission system that operates at two levels:

• Site level — roles that apply across the entire LEAF installation.
• Project level — roles that apply only within the scope of a specific project (research group).

This document describes each role, its intended audience, the permissions it grants, and how it relates to the broader project and site architecture. It is intended for end users, project managers, and site administrators who need to understand how access is structured and how to assign appropriate roles to collaborators.

2. Overview of Roles

LEAF defines two categories of roles: site-level roles that apply platform-wide, and project-level roles that are scoped to individual research groups. The diagram below summarises the hierarchy.

Table

A user may hold a site-level role and one or more project-level roles simultaneously. For example, a researcher who is an authenticated user at the site level might be a Project Editor in one project and a Project Viewer in another.

3. Site-Level Roles

Site-level roles govern access to platform-wide features and administration. They are assigned by a Site Administrator and apply regardless of any project membership.

3.1 Anonymous (Public) User

Scope: Platform-wide · No login required

Anonymous users are any visitors to the LEAF site who have not authenticated (logged in). They represent the general public, including students, researchers, and members of the public browsing the repository. Anonymous users cannot create, edit, or manage content, but may browse and search published collections and repository items that have been made publicly accessible.

Key capabilities

• Browse and search the LEAF repository.
• View publicly accessible repository items, collections, and site pages.
• Access public project home pages (if configured as public by the project).
• Cannot access restricted or embargoed content.
• Cannot create, edit, delete, or manage any content or users.

3.2 Authenticated User

Scope: Platform-wide · No login required

An authenticated user is anyone who has registered and logged in to LEAF with a valid Drupal account. Upon account creation, every authenticated user automatically receives a personal workspace — an Islandora Collection for their own research and annotation activities. Authenticated users are the base class for all project membership roles; a user must be authenticated before they can be added to a project.

Key capabilities

• All permissions of an anonymous user (browse, search, view public content).
• Maintain a personal user profile.
• Be added to projects by a Project Administrator or Site Administrator.
• Cannot create site pages or administer other users' accounts.

3.3 Site Administrator

Scope: Platform-wide · Can access and modify site-wide settings, manage users and all content across the platform

The Site Administrator has full access to all administrative functions across the LEAF platform. This role is typically held by a technical administrator or system manager. Due to the elevated privileges it carries, it should be assigned to only a very limited number of individuals. Site Administrators are responsible for platform configuration, user account management, and establishing site-wide defaults that projects can optionally override to some extent.

Key capabilities

• All permissions of an authenticated user.
• Create, edit, publish, and delete all content site-wide, regardless of project membership.
• Create and manage all Drupal user accounts — add, modify, cancel, and assign roles.
• Configure site-wide theme, appearance, and global settings.
• Set site-wide timed lock durations for individual content types.
• Set up and manage IP ranges for embargo access control.
• Create and manage site pages (About, Help, and other general pages).
• Create and configure new projects (research groups).
• Access and modify all project content and settings.
• Manage Drupal modules, configuration, and content types.
• Configure global search and faceting behaviour.
• Access administrative reports and logs
• Approve or deny platform account requests

4. Project-Level Roles

Project-level roles are scoped to a specific project (research group) and are assigned by a Project Administrator or Site Administrator. A user may hold different project roles in different projects. These roles do not grant any permissions outside the project they are assigned in.

Project roles are implemented using Drupal's Group module, which creates a membership and permission system within each research group independently of site-wide Drupal roles.

4.1 External Visitor

Scope: Project-scoped · Read-only access

The External visitor role is intended for collaborators, reviewers, or stakeholders who need to read project content but should not be able to modify it. An External visitor can see content that might be restricted from the general public but cannot make any changes.

Key capabilities

• View all published and draft repository items within the project.
• View project-specific pages (home page, simple pages).
• Browse and search collections within the project.
• Cannot create, edit, delete, or publish any content.
• Cannot modify project membership or settings.

4.2 Peer Reviewer

Scope: Project-scoped · Read-only access + specific workflow status

The Peer reviewer role is intended for platform authenticated users who are not direct , participating members of the project, but who are conducting a formal peer review of the project or its scholarly output.

Key capabilities

• All permissions of an External visitor.
• Apply the peer review status on project objects and collections.
• Cannot create, edit, delete, or publish any content.
• Cannot modify project membership or settings.

4.3 Contributor

Scope: Project-scoped · Content creation and editing

The Contributor is the standard working role for researchers, students, and contributors actively contributing to a project. They can create and edit repository items and project pages, but cannot manage the project's structure, membership, or technical configuration. This is the most commonly assigned role for day-to-day scholarly work.

Key capabilities

• All permissions of an External visitor.
• Create new repository items (upload files, add metadata) within the project.
• Edit metadata and content of repository items owned by or assigned to them.
• Edit project simple pages.
• Submit content for review or publication (within configured workflow states: draft, review).
• Cannot delete repository items owned by the project.
• Cannot manage project membership, collections, or technical settings.

4.4 Project Editor

Scope: Project-scoped · Content editing, editorial decisions

The Editor is the working role for lead researchers on a project. They can create and edit repository items and project pages, manage the project's structure and membership. This is the role that can publish scholarly work (by assigning it the “published” workflow status).

Key capabilities

• All permissions of a Project Contributor.
• Publish content (within configured workflow state “published”).
• Perform batch content operations.
• Delete repository items owned by the project.
• Manage project membership and nodes (pages and repository items).

4.5 Project Technician

Scope: Project-scoped · Technical configuration and batch operations

The Technician is a technical role for users who manage the structural and configuration aspects of a project's collections. They may perform batch ingests, configure collection settings, and adjust locking behaviour — capabilities that go beyond day-to-day content editing but fall short of full project administration. This role is typically held by a project's technical lead or data manager.

Key capabilities

• All permissions of a Contributor.
• Perform batch content operations.
• Override site-wide and project-wide timed content lock durations for nodes in their project.
• Manage access policies on repository items and collections within the project.
• Change default layouts on project simple pages and homepage
• Cannot add or remove project members or assign project roles.
• Cannot modify global site settings or manage users outside the project.

4.6 Project Administrator

Scope: Project-scoped · Full project management

The Project Administrator has full control over all aspects of a project — content, membership, and configuration. This role is typically held by the principal investigator (PI) or project manager of a research group. They act as the primary point of contact between the research team and the site administrator for their project's needs.

Key capabilities

• All permissions as they pertain to the project .
• Add and remove project members (invite authenticated users to the project).
• Assign and modify project-level roles for members (External Visitor, Contributor, Editor, Technician).
• Create and manage project collections.
• Create, edit, publish, and delete all content within the project, regardless of ownership.
• Create and manage project pages (project home page, simple pages).
• Configure project-level settings (collection structure, display, access policies).
• Moderate content within the project (approve, reject, or publish items in review).
• Cannot modify site-wide settings or manage users outside the project.
• Cannot create new projects (this requires Site Administrator access).

5. Permissions Reference Matrix

The following table summarises the key permissions across all roles. A tick (✓) indicates the role has the permission; a dash (—) indicates it does not. Except for the Peer reviewer role, permissions cascade upward: a role with a tick also inherits all permissions ticked for roles to its left.

TABLE

6. How Roles Are Assigned

6.1 Site-Level Roles

Site-level roles are assigned through the Drupal People administration interface (People » Roles). Only a Site Administrator can create user accounts, approve requests for accounts and assign site-level roles.

6.2 Project-Level Roles

Project membership and project-level roles are managed within the project's Group » Members settings. A Project Administrator can invite any authenticated user to their project and assign them a project role. A Site Administrator can do the same for any project on the platform.

To add a member to a project:

• The user must already have a LEAF/Drupal account (authenticated user).
• The Project/Site Administrator navigates to the project's Group » Members management page.
• They enter the user's username or email, select the appropriate role, and confirm.
• The user can immediately access the project at their assigned permission level.

7. Common Scenarios

7.1 Onboarding a New Researcher

A new graduate student joins a digital humanities project:

• A Site Administrator creates a Drupal account for the student/ or the student requests an account via the /register page.
• The Project Administrator for the relevant research group invites the student and assigns them the Project Contributor role.
• The student can now create and edit repository items within the project.

7.2 Assigning a Technical Lead

A research team needs someone to manage batch operations and complex page layouts :

• The Project Administrator assigns the Project Technician role to the relevant team member.
• The technician can now perform batch operations, configure project settings, modify page layouts, and adjust lock durations.
• They cannot add other members or assign roles — that remains with the Project Administrator and Editor.

7.3 Granting Read-Only Access to a researcher

An external researcher needs to see the project's working drafts without being able to modify them:

• The reviewer must first have a LEAF account (the Site Administrator creates one if needed or the researcher applies for one).
• The Project Administrator invites the reviewer and assigns the External Visitor role.
• The reviewer can read all content in the project, including restricted and draft items, but cannot edit anything.

7.4 Promoting an Editor to Administrator

A senior researcher takes over project leadership:

• The current Project Administrator (or a Site Administrator) navigates to the project's membership management page.
• They change the researcher's role from Project Editor to Project Administrator.
• The researcher now has full project management capabilities.

8. Notes on Governance & Best Practice

• Principle of least privilege: assign users only the minimum role needed for their work. Upgrade roles as responsibilities grow.
• The Site Administrator role is powerful and should be held by no more than one or two individuals.
• Project Administrators are accountable for their project's membership list. They should review and remove access for members who leave a project.

9. Quick Glossary

Term	Definition
Authenticated User	A Drupal user who has logged in with a valid account.
Collection	An Islandora grouping of repository items within a project or workspace.
Content Lock	A timed mechanism preventing simultaneous edits to a node.
Drupal Groups	The module used to create project-scoped memberships and roles.
Islandora	The open-source digital repository framework built on Drupal that LEAF is based on.
LEAF	Linked Editing Academic Framework - Islandora 8 based virtual research environment employed by CWRC and Confluences sites.
Node	A single piece of content in Drupal (a page, a repository item record, etc.).
Project	A research group in LEAF; a Drupal Group with project-scoped roles and collections.
Project Administrator	Project-scoped role with full project management permissions.
Editor	Project-scoped role for content management and scholarly editing.
Technician	Project-scoped role for batch operations and technical configuration.
Contributor	Project-scoped role for day-to-day content creation and editing.
Peer Reviewer	Project-scoped read-only role with specific editorial function.
External Visitor	Project-scoped read-only role.
Repository item	A digital object (image, document, audio, video, XML, etc.) stored in LEAF.
Site Administrator	Platform-wide Drupal role with full administrative access.
Site Page	A page created for all site visitors (e.g. About, Help) — managed by Site Admins.
Project Page	A page created and managed within a specific project by project-level roles.