User Roles

Users are created by those first signing up for an account with a particular instance of Manifold—or by an existing user with Administrator credentials on behalf of one who doesn’t yet have an account. User accounts carry different CRUD (Create, Read, Update, Delete) permission credentials according to the following roles:

Administrator

Has full CRUD permissions within a specific instance and Read access to the (forthcoming) Analytics menu item.

Use Cases. Administrator permissions would be assigned to the person (or team members) overseeing a Manifold installation at an institution or publishing unit. Within a university press, this permission designation would be assigned to one or a subset of the following: a digital editor, someone from either the editorial or production departments, or, in some cases, an IT manager.

Editor

Has full CRUD permissions within an instance, except in the Settings and Analytics menus, the latter of which they can see (Read) but nothing else. This role also cannot CRUD user accounts and is limited to Maker records. If a project has been deleted from the system, this user will not be able to delete any Maker records that were unique to that project.

Use Cases. Editor permissions would be used for those in DH Centers, publishing units, and libraries where staff with this permission designation would have full control over all the projects within an instance but not be able to affect the instance’s global settings.

Project Creator

Has creation permissions (C) for the Projects and People menus—and by default will have the “Can Modify the Project” permission toggled on, allowing those assigned this role the ability to not only create new projects but have the rights to modify them.

Have CRU permissions for Maker records generally but can only delete Maker records that are associated with projects where the user has Can Modify Project permissions. As such it’s possible for this user to permanently delete a Maker record associated with a project they can modify that is also associated with a project they cannot.

For more about how to assign permissions to a user, see the Permissions section.

Use Cases. Coordinator permissions could be assigned to (acquisitions) editorial and production staff, within a university press, to manage their specific projects and the people contributing to them. At other publishing centers this allows distinct units to control their own projects without affecting the instance as a whole or the publishing work of other units on the same instance.

Marketeer

Has RU (not C or D) permissions for only Projects and Content menus and Read access to the (forthcoming) Analytics menu item. This role also cannot CRUD user accounts and is limited to Maker records. If a project has been deleted from the system, this user will not be able to delete any Maker records that were unique to that project.

Use Cases. For marketing staff at a university press to add and update project copy and imagery across an instance, as well as pages and feature content items in service to promotion, branding, etc.

Reader

The default user role. When logged in a Reader can highlight, annotate, comment, and use share functionality. This user doesn’t have native access to the backend in any capacity but can access the Author Dashboard on projects where Is a Project author permission is toggled on for that user.

For more about what permissions can be scoped to the Reader role, see the Permissions section.

Table 1. Inherent backend permissions for global roles

  Projects People Content Settings Analytics Author Dashboarda
Administrator CRUD CRUD CRUD CRUD R
Editor CRUD CRUDbc CRUD R
Project Creator CRUDd CRUDcde
Marketeer RU CRUDbc CRUD R
Reader

aAccess to the Author Dashboard is not inherent to any role. Only Readers who have the “Is a Project Author” permission toggled on will be able to access the dashboard.
bIf a project has been deleted from the system, this user will not be able to delete any Maker records that were unique to that project. cPermissions are specific to Maker records and do not include any CRUD permissions for User accounts.
dAccess to RUD functions is not inherent to the role but provided through the “Can Modify the Project” permission, which will be toggled on by default to the role.
ePermission to delete Maker records is (1) granted by the “Can Modify the Project” toggle and (2) specific to only those records where the user has said permission.