#217 - Security Realms
We need to be able to divide the users, groups, and roles into independant realms. Each realm would be administered by it's owner and other users within the realm that have admin permissions.
Realm admin would be able to add new users, define new groups, and set their own security policy.
Users, groups and roles from other realms would never appear as choices on drop-down lists or selects or list views.
This would allow a single sugar instance to support multiple communities on a single host. This would be very useful to developers who want to support many small communities on an identical code / configuration base. It allows you to share the same code and even the same database.
To keep login simple, user names would be globally unique throughout all realms
11 years ago
I like the idea, but honestly don't want to touch this with a ten foot pole. It opens up a whole can of worms that can easily spell disaster. Supporting this will be a nightmare and I'd definitely would need to increase the cost of this add-on substantially to cover it.
11 years ago
The downside is high I suppose for a full-blown solution, but the cost of keeping N versions up to date for my user groups is worse!
I'm thinking about adding a Realms module, then relating it to the Users table. Then I just limit user lists and selects to those within the same realm as the session. Your group admin stuff already limits group owners to managing their own groups. I can rely on your group and role permissions for securing access.
11 years ago
There are a couple of user list functions that could be key for you to touch in include/utils.php. Look for get_user_array and getUserArrayFromFullName.
11 years ago
modules/Users/metadata/popupdefs.php has a where clause.
any others you can think of? I wish I could set a break point on reading the users table
11 years ago
modules/Users/views/view.list.php to always have the User search auto filter. Copy this to custom/modules/Users/views/view.list.php if that file doesn't exist yet. Try to avoid core file changes as much as possible. It'll help down the road.
11 years ago
what does securitysuite_filter_user_list control?
11 years ago
Non-admins can only assign users who are a member of the same group(s) as the user doing the assigning. High level description of the options are here: https://www.sugaroutfitters.com/docs/securitysuite/options#filteruserlist.
The 2 functions I mention above in utils.php are touched for this purpose.
11 years ago
maybe this is all that I'm looking for!!
Of course, I couldn't use a default group with a default role for for all users, but I have a trigger for that anyway.
11 years ago
Sweet. Sounds like I can implement my hierarchy with this.
I just need to define a "Group" for each "Realm" and stuff every single member into that group.
Then the admin user can see those users whenever setting up teams.
Each team can be sub-divided in to smaller teams using groups. If the admin user for the entire team is a member of every group, then he can select any team member from any group.
Roles can set the global access policy based on what each kind of member a team has, sales/management etc.
LOVE IT
11 years ago
The best line of code is the one that you DO NOT write.
11 years ago
I think I found a bug in your implementation.
For non-admin users, the link index.php?module=Users&action=index will bring up the current user's detail page.
But the link index.php?module=Employees&action=index&return_module=Employees&return_action=DetailView will list all Employees, even those not in the group!
Better behavior would be to give
11 years ago
For the original purpose of that option, it still meets the need. For your requirement for realms, yes that would be an issue. SugarCRM is a beast under the hood.
11 years ago
Since sugarcrm is open-source, you cannot count on the user not being able to conjure up their own links.
11 years ago
Probably need to just restrict this list of users like you did elsewhere.
11 years ago
In case it ever gets that far custom/modules/Employees/views/view.list.php:137