#1861 - Doubt with data sharing within a group
Hi all, not new to SugarCRM, more or less new to SuiteCRM, absolutely new to SecuritySuite. I read everything I could find, got to make everything more or less work, but have one doubt (using the scenario from your example): Group: East Sales Manager: Will, role "Group" assigned directly to him, he sees every record with that security group (SG from now on) assigned. Team members: A, B, C. They belong to this group, the group has a Role "Owners" assigned so they only see their own records. So far, everything working fine. Now: - what if someone wants to make a record visible to every other member of that group? (ie: A wants B and C to be able to see one of his contacts) - what if someone wants to make a record visible to only some of the members of that group? (ie: A wants B to be able to see one of his contacts)
The way I was thinking to deal with this is to create a SG for each member and assign the Group role to that SG, of course make every member a member of his own group and have the owner of a specific record share that record with others by adding their own SG. For this to work I assume also the configuration of SecuritySuite should have the "Strcit Rights" selected. Am I doing something wrong? is there an easier way of achieving this? Thanks a lot in advance. MG
8 years ago
If A could conceivably allow B to see his one contacts then why not just make the group role Group level access for List/View and then Owner for Edit? No need for extra layers of security when there isn't a true reason to have it. List views can still be filtered to "My Items" only so that in general A and B would only see their own records. Then if they need to see some other contact in their group they can clear the search and see all contacts in their group(s).
In practice, this is how businesses are using SecuritySuite. They utilize it to lock down records that other groups should never have access to from a policy perspective.
Does this help?
8 years ago
Hi Jason, probably I wasn't clear, the case is that someone wants to make "a record", not every record visible to the rest or some of the rest of the members... It's something like this, the group manager sees and is able to edit everything, each member can choose on the visibility of his records thus being able to decide wether to share it with others or not (and also with whom within the group) Is it clearer now? Thanks again!
8 years ago
I understand that, but what is the business reason behind that model? That was what I was trying to convey. Why is it that members of a group can't see all other records in the group if you are already empowering any member of a group to give access to specific records to other members of a group? If that's the case, then setting the rights to Group for List/View should work from a security standpoint. What you are trying to specifically allow just isn't possible with SecuritySuite as it never empowers individual group members to pick and choose and break a security model. In typical uses that could open the company up to data security liability issues.
8 years ago
I see your point, maybe I'm not using the team concept right. I thought of a team as a group of sales reps working on the same project (selling bicycles for example) while there's another team working on another project (selling houses) and there are many times in which sales reps are not willing to share with their peers their own contacts, but sometimes yes. What is important to us is to let them have that privacy when they want it but at the same time letting them share information with their peers when they are working together, but at the same time keep all the information in one place. Anyway, let me "double think" about your point of view. And really I appreciate your time and help.
8 years ago
Got it now. It sounds like what would be useful for you would be a multiple assigned user option. This is a big limitation in Sugar/Suite and I would love to add that ability this year. For the base SecuritySuite, groups/teams are usually structure based on the organizational hierarchy instead of teams working on a project. I can see why you would want something like that though. Would multiple assigned users solve the issue for you?
8 years ago
yes i think it would, could be multiple owners, or multiple assigned to users and roles related to assigned users.