Users are created by those first signing up for an account with a particular instance of Manifold—or by an existing Administrator on behalf of one who doesn’t yet have an account. User accounts provide credentials along the following lines:
Abilities. All menus, settings, and actions available in the backend can be attended by an Administrator. Only those who have installed the instance and can access it through a command line interface (CLI) can exercise more control over an instance.
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.
Abilities. Editors can create, modify, or delete Projects, Maker records and an installation’s Pages, regardless of who originally created them. Editors do not have access to an installation’s global settings, cannot manage Features, nor can they create, modify, or delete user accounts. Editors, however, can grant other users permissions to modify specific projects.
Use Cases. Editor permissions would be used for those in DH Centers, publishing units, and libraries where staff with this permission designation need full control over all the projects and Maker records within an instance.
Abilities. Can access the backend and modify all elements of those projects they’ve created or those for which they have been scoped
Can Modify Project permissions. Project Creators likewise have the authority to extend permissions to other users over those projects they manage. Additionally, Project Creators can create new and modify existing Maker records; however, they cannot delete any Maker record, even those they created.
Use Cases. The Coordinator role can be granted 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 role allows members of 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.
Abilities. Marketeers can modify all existing Projects and Maker records, as well as create, modify, or delete an installation’s Pages and Features. However, they cannot extend permissions to other users on a project-by-project basis, nor can they create new or delete existing Maker records, nor can they.
Use Cases. For those who are charged with maintaining the identity, voice, and branding of the instance. At a university press this role would granted to staff from the marketing and sales departments.
Abilities. The default user role. When logged in a Reader can highlight, annotate, comment, make use of sharing functionalities, and customize email notifications, all of which are described in detail in the Reading section. Readers don’t have native access to the backend in any capacity, but they can be scoped permissions to perform certain actions in the backend (e.g., adding resources to a project or modifying metadata). Readers can also be classified as project authors, which distinguishes their interactions with their text from other readers. For more about what permissions can be scoped to the Reader role on a project-by-project basis, see the Access section.
Use Cases. All users signing up for the first time to an instance are granted a Reader role. Users who have authored materials on the platform should come into the system as Readers and be granted further permission to access and engage with their project. See the Abilities section below for more details.