# User Roles and Permissions

OneVision uses role-based access controls to restrict system access. There are different levels of user roles:

- Tenant-level: The tenant A tenant is an individual or organization that subscribes to and uses services provided by a cloud computing platform.-level user roles are Admin and User. The user roles determine the general access and control over the tenant.

- Project-level: A project In OneVision, a project is a collection of images and vision tools that performs different tasks, such as inspection, measurement, or identification. contains a toolchain Contains a group of tools and the sequence of execution for each tool. and an image database The set of images used to train and test your vision application.. The project-level user roles are Owner The Owner is a project-level role who can assign roles to existing tenant users and has the same access to the project as an Admin., Editor The Editor is a project-level role who can access the majority of functions of a project, including editing and sharing. The Editor cannot delete a project., and Viewer The Viewer is a project-level role who can only view the project and export the runtime toolchain. The Viewer cannot edit the project in any way.. The user roles determine the access of the user to the project.

- Workspace A workspace is a collection of projects that you can share with other users.-level: A workspace is a collection of projects. The workspace-level user roles are Owner, Editor, and Viewer. The user roles determine the access of the user to the workspace.

## Tenant-Level Roles

The tenant-level roles are:

- User:

  - All users can create new projects.

  - The user access and permissions on each project and workspace is controlled by the project-level role assigned to the user.

- Admin: The admin has complete access rights, which includes the following:

  - Accessing all aspects of the tenant.

  - Adding and removing users.

  - Modifying access to all projects.

    Note: Admins must first assign themselves a project-level role before they can modify project permissions or content. For more information on creating a project and assigning user roles, see Project Management.

  - Creating new workspaces.

## Tenant-Level User Administration

See the following dropdowns to find out more about the most frequent actions for managing tenant-level user access. For more information on actions for managing project-level and workspace-level user roles, see Project Management.

How to view users

All users can view the list of users.

To view users:

1. Click the user profile icon and select Members.

2. All users are listed under the Members tab. You can sort the list by Member name or Role.

How to add a new user

Admins can add new users. To add a user:

1. Click the user profile icon and select Members.

2. Click Invite Members.

3. Enter the e-mail address of the new user and select the role.

The e-mail invite link expires in seven days if not activated. The Admin needs to invite the new user again after the seven days have passed without activation.

How to remove a user

Admins can remove existing users. To remove a user:

1. Click the user profile icon and select Members.

2. Select the user you want to remove from the list of members. You can filter by Member name and Role.

3. Click the three-dot menu next to the user and click Remove Member.

4. Confirm your choice in the pop-up window and click Remove.

## Project-Level Roles

Users can access a project after they are assigned a role. Users can have only one role for each project.

The project-level roles are the following:

- Owner

- Editor

- Viewer

In case the Owner no longer has access to the tenant project, the Admin can reassign access.

The following table shows the roles and the level of access:

Access | Owner | Editor | Viewer
Viewing project |  |  |
Renaming project |  |  |
Adding or removing users of any role |  |  |
Adding or removing users of Editor or Viewer role |  |  |
Deleting project |  |  |
(Beta) Exporting runtime toolchain |  |  |
(Beta) Cloning project (making a copy of the project on the same tenant) |  |  |
(Beta) Exporting project archive (serialize the complete project to import into another tenant) |  |  |

## Workspace-Level Roles

Users can access a workspace and the contained projects after they are assigned a role. Users can have only one role for each workspace.

The workspace-level roles are the following:

- Owner

- Editor

- Viewer

Project-level and workspace-level roles are independent. For example, if you have an Editor role in a workspace, you can see the projects in the workspace, but you cannot edit a project unless you have Editor or Owner role for that project.

The workspace-level roles have the following levels of access:

Access | Owner | Editor | Viewer
Viewing all the projects in the workspace |  |  |
Renaming workspace |  |  |
Adding or removing users of any role |  |  |
Adding or removing users of Editor or Viewer role |  |  |
Deleting workspace |  |  |
Creating new project in the workspace |  |  |
Moving project from the workspace |  |  |
Moving project to the workspace |  |  |

Note: Whether you can move or clone a project between workspaces and root also depends on your access to the project.

## Interaction Between User-Level and Workspace-Level Roles

If a user has access to a workspace and a project moves from that workspace, one of the following can occur:

- The user retains access to the project in the following cases:

  - The user has an assigned role for a project before the project is moved.

  - The user does not have an assigned role for a project before the project is moved, but the project is moved to a workspace where the user also has access.

- The user loses access to the project if the user does not have an assigned role for a project before the project is moved, and the project is moved to the root or to another workspace where the user does not have access.

Moving and cloning projects requires the following roles for the workspace and the project:

- To move a project from root to a workspace, you need Editor or Owner role in the workspace and the project.

- To move a project from a workspace to another workspace, you need Owner role in the origin workspace and Editor or Owner role in the target workspace and the project.

- To move a project from a workspace to root, you need Owner role in the origin workspace and Editor or Owner role in the project.

- To clone a project, you need Owner or Editor role for the project. If you have Viewer access in the workspace, you can only clone the project to the root.

The following table summarizes the roles you need to move projects:

Workspace Access | Project Access | Move Project from Root to Workspace | Move Project from Workspace to Workspace1 | Move Project from Workspace to Root1 | Clone Project to Workspace | Clone Project to Root
--- | --- | --- | --- | --- | --- | ---
Owner | Owner |  |  |  |  |
Owner | Editor |  |  |  |  |
Owner | Viewer |  |  |  |  |
Editor | Owner |  |  |  |  |
Editor | Editor |  |  |  |  |
Editor | Viewer |  |  |  |  |
Viewer | Owner |  |  |  |  |
Viewer | Editor |  |  |  |  |
Viewer | Viewer |  |  |  |  |

1 You need Owner access in the Workspace from which you want to move the project.