LinkBack URL
About LinkBacks
PATCH: Role/Team/Hierarchy Security
This patch implements a flexible security system, based on pre-defined user privileges. It works in two different modes:
ROLE SECURITY
This is more flexible approach where you can setup rights without taking care of hierarchy. The idea is very simple, but effective. Go to "Administration, Roles" and create a role that exactly matches the user name or the user's department (or you can setup both). Then, simply add the users of whom the role user can see the data. For example, John must see Mary's and Mark's records. Create a role named "John", add "Mary" and "Mark" on the list of users. Notice that John will see their records but the opposite is not true. For a quicker team setup, name the role as a team name, for example, "Support", add the users and then type the team name on the user's department field. Users of that department or team will have access to records of all users on the list. Do not use this kind of role for the tabs hiding purpose!
HIERARCHY + COMMON TEAM
This functionality works like the "User Hierarchy" scheme, setup by Badarinath, with one additional feature. It allows you to type in a common name on the field "Department" for each user and then have users "sharing" the same records. For example, if you want two people on tech support to see each others records, just type "Support" on the department field of both users records. So, they will see records from the people who reports to them, plus, records from people on the same "team" (you can rename the field "department" to "team" if you want).
LIST, VIEW, EDIT & DELETE CONTROL
Sugar has so many modules, panels, subpanels, views, lists, etc, that is impossible to setup a scheme that will fit everyone's needs. For example, should the project tasks be viewable by anyone who works on the project? Should an account be hidden from the people out of its team or region? What if someone duplicates it? When I see a contact history, should I see other user's meetings? Well, well.. I won't answer and don't even feel like discussing this complex thing. I'll let you decide what is best for you.
INDEPENDENT SETUP BY MODULE
Open the file modules/Users/Team.config.php. You will see the whole list of modules and their settings, something like this:
The first item is for choosing the security method. It can be "role" or "hierarchy". The other settings can have the value 'public' or 'restricted'. This has effect only for those records that a user is usually NOT allowed to see. The user can do anything on the records where he/she is the "assigned user" and on records where the "assigned user" is someone of his/her hierarchy/team/role.PHP Code:'mode' => 'role',
'account' => array (
'listview' => 'public',
'detailview' => 'public',
'editview' => 'restricted',
'assign_user' => 'restricted',
'filter_user' => 'restricted',
'subpanel' => array (
'contacts' => 'restricted',
'opportunities' => 'restricted',
'leads' => 'restricted',
'cases' => 'restricted',
'accounts' => 'public',
'bugs' => 'restricted',
'project' => 'restricted',
'calls' => 'restricted',
'meetings' => 'restricted',
'tasks' => 'restricted',
'notes' => 'restricted',
'emails' => 'restricted',
),
),
listview
If you set to "public", all records for the module WILL be shown on the listviews for any user. This is the same effect of "disabling" the security, but only for this module (and only for the listview). A setting "restricted" will show listview records respecting the security scheme.
detailview
If you set to "public", everyone will be able to access the detailview with any record of the module. Theoretically, setting listview to "restricted" and detailview to "public" would make the record unacessible, but this is not really true, since the user can access the detailview by a backdoor (a direct link). Setting to "restricted" will block unwanted access even through links on the subpanels.
editview
I think many people will enjoy this. Setting to public, everyone edit, delete and duplicate any module's record. Setting to "restricted" will not allow users to click on those buttons (which are found on the detailview). This will also get rid of the checkboxes and disable the mass-update for not-allowed records. So, you can setup a public listview and restricted editview to allow readonly access to anyone who's out of the team.
assign_user
Setting to "restricted" will make the lists of users found on the module's EditView have only the users on the team. Public will fill in the list with all users. This could make, for example, an Assistant, who's not allowed to see your records to assign an account to you.
filter_user
This is for the users lists on the search forms. Public will let anyone select any username to do a query (that might be blocked by the listview settings). Restricted will show only the team users.
subpanels
For each subpanel you see on every detailview you will find a setting. It is even more flexible than that. You can say, for example, that meetings of other users (out of your team) must be shown on the accounts history. Calls must not. Accounts might show it all, contacts might shown only projects, it is up to you!
INSTALL
I spent most of the time to make this patch change the minimum number files possible within Sugar. Everyone knows the nightmare we go through when there is an upgrade and we have dozens of "customized" files. So, only 5 Sugar files were changed (and 2 new files were included). To install, you'll have to replace your files or do the manual "merge".
Reply With Quote
Re: PATCH: Role/Team/Hierarchy Security
Re: PATCH: Role/Team/Hierarchy Security
Originally Posted by jenny16 
Re: PATCH: Role/Team/Hierarchy Security
Re: PATCH: Role/Team/Hierarchy Security
Bookmarks