We have written a customized application using SuiteCRM and I’m trying to wrap my head around something new we are attempting to develop as it relates to security groups. I’ll try to simplify this as much as possible but we have quite a few custom modules. For simplicity, I’ll describe two modules. We have a projects module and an items module. The items are related to the projects. Nothing real crazy going on there. Now, we have two groups that ordinarily work independently and typically wouldn’t share anything in the database. There is a new requirement where they will be working together and some entries in the projects and items modules these will need to be shared amongst both groups. Initial thought is to have 3 security groups with the collaborative projects in the middle group and the users would each be part of 2 of the 3 groups (their initial group and the collaborative group). However, we need to ensure that when a user is working in a project in their initial group, it doesn’t inherit the collaborative security group which would expose project data to the incorrect group. However, if a new entry is created in the collaborative group, it should properly inherit both security groups of the user who created it. I know we could work out some custom development to accomplish thus but in reading some of the documentation and other security examples, I’m just wondering how far we could take the built in functionality before having to go custom. Any thoughts?
Hi, welcome.
Have you considered, for the shared items, instead of using a third security group, just applying the two groups that already exist, one for each team?
Using more than one security group per item will give the teams the ability to share, but won’t make users have two groups assigned to them, so won’t interfere with inheritance.
You might need something additional (maybe custom coding, or maybe manually will work well) to add the second group to sub-items, if you can’t get it to inherit like you want. I’m not sure how this will play out, it’s better to just try it and fiddle with the security suite settings.
But it’s always better to have your additional steps or additional code ADD permissions, instead of having to chase the system’s automatic mechanisms by REDUCING permissions, you never know when you’ll miss something.
That is good to know regarding adding rights instead of removing. The challenge here is actually with inheritance. If someone from group 1 creates something new in the collaborative project, we would need it tagged with both groups so group 2 members could also see it. I think this is where we would need the custom development. Thanks for the input!