In your company or organization, among the people who use the Coveo Cloud administration console, few need to access all its features. Depending on how responsibilities are delegated, some users may only need to access a service or perhaps even a single page of the administration console to accomplish their tasks. Similarly, the Coveo Cloud API keys you create may only need to have access to a specific domain of your Coveo Cloud organization to serve their purpose (see Adding and Managing API Keys).
As an administration console user allowed to create or edit groups or API keys, you may want to prevent users from viewing or editing features or resources that are not relevant to their tasks (see Adding and Managing Groups, Adding and Managing API Keys, and Principle of Least Privilege). The group and privilege features allow you to customize user and API key access to your Coveo Cloud organization.
The operation of granting privileges is not to be taken lightly, as insufficient privileges can hinder task accomplishment, while inadequate or unnecessary privileges could lead to accidents or misuse. When allowed to delegate powers, you should have a good understanding of how the Coveo Cloud privilege system works and be well aware of the implications of each choice you make. In this regard, Coveo strongly recommends thoroughly reading its privilege documentation before granting privileges or editing a privilege set, and enforcing the principle of least privilege, i.e., granting just enough privileges for the grantee to perform their task (see Privilege Management and Principle of Least Privilege).
Privileges have nothing to do with access permissions on source items (see Coveo Cloud V2 Management of Security Identities and Item Permissions). Coveo Cloud organization privileges allow you to control what grantees can do through the Coveo Cloud administration console or APIs, while permissions on source items are dependent on your source configuration and determine which items each end user can see as search results in a Coveo search interface.
A privilege is an ability applied to a domain. This combination determines what a user can do in the administration console. Abilities are represented by verbs, such as view, edit, and create, while domains are a subset of data and features of a Coveo Cloud organization. Most of the pages in the Coveo Cloud administration console are named after an organization domain, but not all domains correspond to a page.
Beside administration console pages, domains can also correspond to actions or sets of data available in the console, such as Execute queries, View activities, and View all content. Moreover, since domains do not represent pages of the administration console, one often needs more than one privilege to access a single page or all the features and panels of a page.
For an administration console user to create a new field in the Fields page, they need the following privileges:
- The ability to view data in the Fields domain, as one cannot edit content without having access to it.
- The ability to edit data in the Fields domain.
- The ability to create data in the Fields domain.
- The ability to view data in the Organization domain (see Minimum Privilege).
Moreover, the Fields page contains a button allowing users to view activities related to fields. To review these activities as part of their field management duties, a user would also need the privilege to view activity data in addition to the privileges listed above.
The example above shows that several abilities may be required to edit the data of a single page of the Coveo Cloud administration console. So, to simplify the task of granting privileges to a user or API key, the Coveo Cloud administration console uses access levels to combine abilities related to a domain. In this regard, access levels are described as lower (or of lesser importance) if they represent fewer abilities than another level for the same domain, or higher (or of higher importance) if they represent more abilities.
For the Fields domain, the View access level represents the view ability only, whereas the Edit access level combines the view, edit, and create abilities. Therefore, users granted the View access level on the Fields domain can view the content of the Fields page, while users that rather have the Edit access level on Fields are not only allowed to view the fields in the page, but also to edit and create new fields. Because it represents three abilities, the Edit access level is of higher importance than the View access level, which only represents one ability.
However, the abilities combined vary depending on the domain. For most domains, including the Fields domain, the Edit access level includes the ability to create resources while the View access level does not include it. You therefore do not have any decision to make as to whether the grantee is allowed to create new resources. Conversely, in domains that offer a Custom access level option, the ability to create new resources is not included in the access level and can rather be granted separately (see Understanding the Custom Access Level). So, when you select the View all or Custom access level, you must decide whether the grantee should also be able to create new resources in this domain. For instance, you can decide that a group of users should be able to edit only certain sources (Custom access level) and to create new sources as well, while another should only be able view sources and not to create any. For further information on the Can Create ability, see About the Can Create Ability.
Finally, when you do not want users or API keys to access the content related to a domain at all, you can also choose to grant no ability by selecting the None access level.
Since the Coveo Cloud administration console is mainly access level oriented, the Coveo Cloud administrator documentation, by extension, refers to the combination of a domain and an access level as a privilege (see Coveo Cloud V2 for Administrators).
Although, as stated before, having the View access level on a domain does not necessarily guarantee that the page with a similar name will be visible for the grantee, the administration console Privileges tab is made so that most domains can be associated with a section of the administration console (see Navigating the Privileges Tab).
Remark: Conflicting Access Levels
When a user is a member of groups that have conflicting access levels, the highest access levels granted to this user apply. In other words, for each domain, the access level that includes the most abilities is enforced, while the lower access levels are ignored.
John Smith is a member of the built-in
Analytics Viewers group, as well as the custom-made
Limited Administrators group (see Built-In Groups and Create a New Group). The following table shows some of the privileges granted to both groups.
Since, for the first three domains, the access levels granted to the
Limited Administrators group are higher than those granted to the
Analytics Viewers group, these
Limited Administrators access levels apply to John Smith. Therefore, John Smith has the privilege to edit dimensions, for instance, even though he is also in the
Analytics Viewers group, which is not allowed to perform this operation.
As for the Impersonate domain, however, the
Analytics Viewers group has the Allowed access level while the
Limited Administrators group does not. Consequently, John Smith is granted the Allowed access level.
The following tables shows the resulting privileges granted to John Smith.
John Smith can therefore, as a member of the group
Limited Administrators, edit dimensions, and, as a member of the
Analytics Viewers, he can also use the user impersonation feature. As for the Named filters domain, there is no conflict, since both groups are granted the View access level.
Some domains offer an additional access level option for custom, granular access to domain resources (see Understanding the Custom Access Level).