In this topic
NVivo Server supports authenticated user access—users are authenticated by their Windows user accounts, so you do not need to manage user passwords inside NVivo.
NVivo Server provides role-based security to control user access to the server and access to the project.
The NVivo Server allows concurrent multi-user access—this means that everyone in your team can work on the same project at the same time. Team members can code, annotate, and link source content at the same time.
Each user can set their own NVivo application preferences—for example, you can choose to hide the waveform in audio/video sources, to use a larger font for viewing dataset sources, or to open nodes in Summary View. Your settings can be different from another user's settings, even when you are both working in the same project. Refer to Set application options for more information.
NVivo Server 9 can host projects in NVivo 9.0, 9.1 and 9.2 formats, however projects in a later format cannot be opened using an earlier version of the NVivo software. Everyone working in a shared project should be using the same version of the NVivo software. You can check which version of the software is installed on your computer. NVivo 9.2 is a free update to your NVivo 9.0 or 9.1 software—refer to Software updates for more information.
When more than one user is working in a project, NVivo Server manages any potential conflicts between the users.
'Edit mode' ensures that team members do not make conflicting changes to source content. You must have a source open and be in edit mode, if you want to modify the content—for example, edit the text in a document source, or add transcript rows to a video. When you have a source open in edit mode, other users can view the source, but they cannot edit, code, annotate, or link the content. Edit mode also prevents conflicting changes to models and reports.
Users can annotate, code and link sources without being in edit mode—any conflicts are resolved by the NVivo Server. For example, if two users try to edit an existing annotation, the first user to complete their changes is successful. The second user's changes are discarded, and the screen is refreshed to show latest version of the annotation.
Similarly, if two users try to change project properties, the first user to complete their changes is successful. The second user's changes are discarded, and the screen is refreshed to show latest version of the project item.
A Project Owner can choose to open a server project exclusively, locking out all other users. This is necessary when importing structure or content from another project. It can also be useful if you are making large scale changes, and want to be certain you can reverse your changes using the undo function.
Using NVivo Server, teams of researchers can collaborate on the same project at the same time.
If you are working in an NVivo Server project, NVivo automatically refreshes your view of the project as you work, so that you can see your team members' latest changes.
When NVivo is 'idle' the workspace does not automatically refresh. NVivo refreshes your workspace whenever you perform common actions such as navigating to a different folder or opening a source or node in Detail View.
To manually refresh your NVivo workspace—click Refresh, in the Workspace group, on the Home tab.
If you attempt to make a change that conflicts with a recent change made by another team member, then NVivo will inform you of the conflict and refresh your workspace so that you can try again.
In a server project, your project user profile is created from your Windows user account—it is not based on your default NVivo user profile. All the work you do in the project is tracked against your project user profile.
The server administrator controls access to the server, by assigning users to server user groups—these groups control what the group members can do on the server. All server user groups can connect to the server, but only members of certain server user groups can create new projects.
The server administrator does not control access to projects. Access to projects is controlled within the projects, by Project Owners—refer to How Project Owners control access to a project for more information.
If you are the Project Owner, you can control access to your project by adding users to project user groups, and by enabling or disabling 'guest access'.
A project user group is a collection of users who are permitted to do the same things within the project. By adding a user to the appropriate group, you control what they can do in the project.
There are three project user groups in an NVivo project; Readers, Contributors and Project Owners:
Readers have the least permissions—they can only view the project.
Contributors can view and modify the project, but they cannot do 'project management' tasks.
Project Owners have the most permissions. They can modify project content and they can perform project management tasks— for example, modify project properties, and manage user access.
Refer to Group permissions: Readers, Contributors and Project Owners, for detailed information on project user group permissions.
If you create a new server project, you automatically become a Project Owner. There can be more than one Project Owner. If you want another team member to assist you with project management tasks, you can add the team member to the Project Owners project user group.
When you create a new server project, you are the only user. As Project Owner, you can give other team members access to the project by adding them to the Readers or Contributors project user groups—refer to Manage users in a server project for more information.
'Guest access' allows any user who has access to the NVivo server to view the project. By default, guest access is enabled, but the Project Owner may choose to disable 'guest access' to the project. If the Project Owner disables guest access, only members of the Readers, Contributors or Project Owners project user groups can access the project.
Project Owners can give access to the project to individual users, or to groups of users.
You can give an individual user access to your project by adding their Windows user account to a project user group.
You can give a group of users access to your project, by adding a Windows group account to a project user group. For example, if you want everyone in your department to be Contributors in your project, you can add the department's Windows group account to the Contributors project user group. New department member get access to your project, when they are added to the department's Windows group account.
Each project user group has an associated set of permissions. For example, if you are a member of the Readers group you can view but not modify the project.
Project user group permissions are listed below:
Action | Readers | Contributors | Project Owners |
View the project | Yes | Yes | Yes |
Copy the project | Yes | Yes | Yes |
Change the project (add and delete project items, edit, code, annotate etc) | No | Yes | Yes |
Modify project properties | No | No | Yes |
Manage project users | No | No | Yes |
Clear the project event log | No | No | Yes |
Import structure or content from another project | No | No | Yes |
Export the project | No | No | Yes |
Compact and repair the project | No | No | Yes |
Delete project | No | No | Yes |
If you are a Project Owner, you can open the project exclusively, locking out all other users.
You must open the project exclusively, if you want to import content or structure from another project.
You might want to open the project exclusively, if you want to make large scale changes to the project. In a shared server project, you cannot undo recent actions, when other users have made conflicting changes. Open the project exclusively, if you need to be certain you can undo your changes.