Skip to content

Commit 3be1d43

Browse files
alverenaalverena
authored
Merge pull request #5137 from laboro/OD-227_access-roles
Od 227 access roles
2 parents eb9a96a + 9a5aa8d commit 3be1d43

File tree

70 files changed

+1468
-45
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

70 files changed

+1468
-45
lines changed

Diff for: ‎user_guide/access_management_access_levels.rst

+74
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
Access Levels
2+
=============
3+
4+
.. contents:: :local:
5+
:depth: 3
6+
7+
8+
9+
Access levels define a hierarchy of access to data. They can be envisioned as nested boxes. The smaller the box, the more limited set of data a user can access and vice verse. If a user has no box, they have no access whatsoever.
10+
OroCRM has a predefined set of access levels with ``None`` being the most limited and ``Global`` providing the widest access to the data.
11+
12+
13+
.. image:: ./img/access_roles_management/access_levels2.png
14+
15+
16+
17+
The full list of all possible access levels can be found in the following table:
18+
19+
20+
+---------------+------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
21+
| Access Level | What data a user can access? |
22+
+---------------+------------------------------+ |
23+
| EE | CE, EE with 1 organization | |
24+
+===============+==============================+===============================================================================================================================+
25+
| None | None | Access is denied. |
26+
+---------------+------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
27+
| User | User | Entity records owned by the user (providing the user has access to the organization(s) for which these records were created). |
28+
+---------------+------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
29+
| Business Unit | Business Unit | Entity records owned by the business unit(s) the user has access to or by any user that has access to the same business unit. |
30+
+---------------+------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
31+
| Division | Division | Entity records: |
32+
| | | |
33+
| | | * Owned by business unit(s) the user has access to or by any user that has access to the same business unit. |
34+
| | | * Owned by the whole chain of the business units subordinated to those the user has access to. |
35+
+---------------+------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
36+
| Organization | Global | All entity records within the organization the user has access to. |
37+
+---------------+------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
38+
| Global | | All entity records within the system. |
39+
+---------------+------------------------------+-------------------------------------------------------------------------------------------------------------------------------+
40+
41+
42+
.. Note::
43+
As you can see, the exact list of access levels available in your system depends on the number of organizations defined. If there is only one organization created (for OroCRM Enterprise Edition, since OroCRM Community Edition does not provide the possibility to create several organizations), there will be no individual **Organization** access level.
44+
45+
46+
.. Important::
47+
When a user logs into the organization with global access, all their access levels, except **Global,** are treated as **None.**
48+
49+
50+
How Are Access Levels Used?
51+
---------------------------
52+
53+
You set access levels when you configure a user role and define permissions it will include. For each action that can be performed on entity (view, create, delete, etc.) you can set an access level.
54+
55+
For example, for the **Account** entity, **Create** action, you set the **User** access level. It means that a user with such role will be able to create accounts only with themselves as an owner.
56+
If you decide to grant a user permission to create accounts withing the user's division (i.e., when creating an account, the user can set any member of the same division as the account's owner), create a role that will have the **Division** access level for the **Account** entity, action **Create**
57+
58+
For more information and examples on roles creation, see the `Roles <./access-management-roles>`__ guide.
59+
60+
.. important::
61+
There are two access levels that you can set for any entity: **None** and **Global.**
62+
63+
Ability to set other access levels depends on the entity’s ownership type. You can set an access level that is ‘higher than or equal’ to the entity’s ownership type. Thus, if an entity's ownership type is **Business Unit**, you cannot set the **User** access level for any action on this entity.
64+
65+
For more information about ownership types, see the `Ownership Type <./access-management-ownership-type>`__ guide and specifically, the `Ownership type and access levels <./access-management-ownership-type#ownership-types-and-access-levels>`__ subsection.
66+
67+
68+
69+
Links
70+
------
71+
72+
For general overview of roles, see the `Roles Management <./access-management-roles>`__ guide.
73+
For examples on roles and access settings application, see the `Access Configuration Examples <./access-management-examples>`__ guide.
74+

Diff for: ‎user_guide/access_management_examples.rst

+279
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,279 @@
1+
Access Configuration Examples
2+
=============================
3+
4+
.. contents:: :local:
5+
:depth: 3
6+
7+
8+
Sales Structure
9+
---------------
10+
11+
Let's imagine that there are two main regional divisions in the company: one in the USA, the other in the EU.
12+
13+
Each of these divisions has smaller subdivisions.
14+
In USA it is the 'Los Angeles' division, 'Dallas' division, 'New York' division.
15+
In EU it is the 'Western Europe' division and the 'Eastern Europe' division.
16+
17+
18+
Sales in this company are a structured the following way:
19+
20+
The Sales Director controls both regions. Each of the regions has its own Regional Sales Manager (RSM). Each of the subdivisions has an Area Sales Manager (ASM) who has a team of Sales Representatives as subordinates.
21+
22+
The picture bellow helps visualize it:
23+
24+
|
25+
26+
.. image:: ./img/access_roles_management/sales_structure.png
27+
28+
|
29+
30+
Goal
31+
^^^^
32+
33+
We want to configure roles and other access settings in such a way that the sales representatives could access only the data they own. ASMs must be able to access data of the their whole subdivision. RSMs—data of all areas in their region. Sales Director must be able to view all the company data.
34+
35+
Configuration
36+
^^^^^^^^^^^^^
37+
38+
Let's assume that we have already created all the required Business Units: 'Main Office' (represents the unit that has access to the whole organization), 'USA,' 'EU,' 'Los Angeles,' 'Dallas,' 'New York,' 'Western Europe,' 'Eastern Europe.' 'Main Office' does not have a parent business unit. Business Units 'USA' and 'EU' have 'Main Office' as a parent business unit. 'Los Angeles,' 'Dallas,' 'New York' have the 'USA' business unit as a parent one. 'Western Europe,' 'Eastern Europe' have 'EU' as a parent business unit.
39+
40+
|
41+
42+
.. image:: ./img/access_roles_management/sales_bu_usa.png
43+
44+
|
45+
46+
47+
48+
.. image:: ./img/access_roles_management/sales_bu_la.png
49+
50+
|
51+
52+
First, we create roles. We need 4 roles: 'Sales Rep,' 'Area Sales Manager,' 'Region Sales Manager,' 'Sales Director.'
53+
54+
Into the 'Sales Rep' role we will include permissions that will have the **User** access level.
55+
56+
|
57+
58+
.. image:: ./img/access_roles_management/sales_role_rep.png
59+
60+
|
61+
62+
Into the 'Area Sales Manager' role we will include permissions that will have the **Business Unit** access level.
63+
64+
|
65+
66+
.. image:: ./img/access_roles_management/sales_role_asm.png
67+
68+
|
69+
70+
71+
Into 'Regional Sales Manager'—permissions with the **Division** access level.
72+
73+
74+
|
75+
76+
.. image:: ./img/access_roles_management/sales_role_rsm.png
77+
78+
|
79+
80+
And into the 'Sales Director' role—permissions with the **Organization** access level .
81+
82+
|
83+
84+
.. image:: ./img/access_roles_management/sales_role_dir.png
85+
86+
|
87+
88+
89+
Second, we configure users: assign roles, define which business units the users will have access to.
90+
91+
|
92+
93+
**Sales Director**
94+
95+
Our sales director will have the following settings:
96+
97+
- **Owner**—The sales director has access to the whole organization. So we set 'Main Office' as the owner.
98+
99+
|
100+
101+
.. image:: ./img/access_roles_management/sales_user_sd_owner.png
102+
103+
|
104+
105+
- **Roles**—We select the 'Sales Director' role.
106+
107+
|
108+
109+
.. image:: ./img/access_roles_management/sales_user_sd_roles.png
110+
111+
|
112+
113+
114+
115+
- **Organization**—We select 'OroCRM'.
116+
117+
118+
|
119+
120+
.. image:: ./img/access_roles_management/sales_user_sd_organization.png
121+
122+
|
123+
124+
As the sales director will have permissions with the **Global** access level, there is no need to specify what particular business units they she must have access to.
125+
126+
127+
|
128+
129+
**Regional Sales Manager**
130+
RSMs will have the following settings:
131+
132+
133+
- **Owner**—Either 'USA' or 'EU.'
134+
135+
136+
- **Roles**—'Regional Sales Manager.'
137+
138+
- **Organization**—'OroCRM.'
139+
140+
- **Organization Business Units**—Either 'USA' or 'EU.' Regional Sales Managers will have permissions with the **Division** access level. A division is a business unit with all the chain of its sub business units and their sub business units an so on. So we need to specify only the top business unit in this chain.
141+
142+
|
143+
144+
**Area Sales Manager**
145+
ASMs will have the following settings:
146+
147+
- **Owner**—One of the business units of a lower level: 'Los Angeles,''Dallas,' 'New York,' 'Western Europe,' 'Eastern Europe.'
148+
149+
- **Roles**—'Area Sales Manager.'
150+
151+
- **Organization**—'OroCRM.'
152+
153+
- **Organization Business Units**—One of the business units of a lower level: 'Los Angeles,''Dallas,' 'New York,' 'Western Europe,' 'Eastern Europe.'
154+
155+
|
156+
157+
**Sales Representatives**
158+
Finally, sales representatives will have the following settings:
159+
160+
- **Owner**—One of the business units of a lower level: 'Los Angeles,''Dallas,' 'New York,' 'Western Europe,' 'Eastern Europe.'
161+
162+
- **Roles**—'Sales Rep.'
163+
164+
- **Organization**—'OroCRM.'
165+
166+
- **Organization Business Units**—One of the business units of a lower level: 'Los Angeles,''Dallas,' 'New York,' 'Western Europe,' 'Eastern Europe.'
167+
168+
|
169+
170+
Now we can check that when Alan Wise, sales representative in Los Angeles, creates an account, for example, he can assign only himself as an owner of this account (account belongs to him). He will also be able to see only his accounts (unless his managers share any accounts with him).
171+
172+
173+
|
174+
175+
.. image:: ./img/access_roles_management/sales_acc_alan.png
176+
177+
|
178+
179+
180+
Nina Anders, who is an ASM, can manage accounts created by sales representatives of her business unit and by herself:
181+
182+
|
183+
184+
.. image:: ./img/access_roles_management/sales_acc_nina.png
185+
186+
|
187+
188+
A USA Regional Sales Manager, Samuel Lee, can see and manage accounts of the Nina's (Los Angeles ASM) business unit and of Anthony's (Dallas ASM) business units as both of them are subunits of the business unit USA.
189+
190+
|
191+
192+
.. image:: ./img/access_roles_management/sales_acc_sam.png
193+
194+
|
195+
196+
197+
And, finally, a sales director has access to all accounts of the company.
198+
199+
200+
Multiple Organizations
201+
-----------------------
202+
203+
There are two businesses that our company runs. One of them is tea sales. The other one—clothes sales. For each business we have created an individual organization in OroCRM ('Tea Sweet' and 'Best Style').
204+
John, Jane and Jill are marketing team members. John works in 'Tea Sweet,'' Jane and Jill—in 'Best Style.'' However, being a wide-range specialist, Jill shares her attention between both businesses and thus is given access to both organizations.
205+
John, Jane and Jill are assigned the 'Marketing' role that includes organization level permissions.
206+
207+
Each of marketers creates two campaigns in OroCRM:
208+
209+
|
210+
211+
.. image:: ./img/access_roles_management/multi.png
212+
213+
|
214+
215+
216+
Let's see which data each team member can see. We know that John and Jane can log in only to the organization they work in, and Jill can log into both:
217+
218+
|
219+
220+
.. image:: ./img/access_roles_management/multi_login.png
221+
222+
|
223+
224+
225+
But what happens when the need ceases for Jill's work at 'Sweet Tea' and an administrator rejects her access to this organization? Now Jill cannot log in into 'Sweet Tea' and cannot see or modify the campaign she has created. She remains the campaign's owner though as other users with access to 'Sweet Tea' can see:
226+
227+
228+
|
229+
230+
.. image:: ./img/access_roles_management/multi_jillcannotlogin.png
231+
232+
|
233+
234+
.. caution::
235+
This mean that you must be very careful when granting or rejecting users access to organizations. Imagine that John has only user-level permissions for working with campaigns. Then there will be no one in Sweet Tea (except maybe a system administrator) who can manage Jill's account. Such situations are better to be avoided, thus try to make sure that there will be no unattended data when you change access rights.
236+
237+
238+
User Has Access to Multiple Business Units
239+
-------------------------------------------
240+
241+
The 'Sweet Tea' company has the Lead Development team which is divided into two geographically distributed units: 'Los Angeles' and 'New York.' Alex, Aaron and Anna are Lead Development Representatives. Alex has access to the 'Los Angeles' business unit, Anna—to the 'New York' unit. Aaron is an experienced employee and was asked by his management to help team members of both business units. Thus, he is granted access to both 'Los Angeles' and 'New York.'
242+
243+
Each of the team members creates a lead record in OroCRM:
244+
245+
|
246+
247+
.. image:: ./img/access_roles_management/leads_structure.png
248+
249+
|
250+
251+
Let's see which data each team member can see:
252+
253+
|
254+
255+
.. image:: ./img/access_roles_management/leads_visibility.png
256+
257+
|
258+
259+
260+
Links
261+
------
262+
263+
For general overview of roles, see the `Roles Management <./access-management-roles>`__ guide.
264+
265+
For how role is represented on the interface, see the `Roles on the Interface <./access-management-roles-inteface>`__ guide.
266+
267+
For what actions you can perform with roles, see the `Actions with Roles <./access-management-roles-actions>`__ guide.
268+
269+
270+
271+
272+
.. |IcRemove| image:: ./img/buttons/IcRemove.png
273+
:align: middle
274+
275+
.. |IcClone| image:: ./img/buttons/IcClone.png
276+
:align: middle
277+
278+
.. |IcDelete| image:: ./img/buttons/IcDelete.png
279+
:align: middle

0 commit comments

Comments
 (0)