Control what your users can access and save time, money, and frustrations. Lock down sensitive data in SugarCRM or SuiteCRM to specific groups or teams. Supports unlimited assigned users, unlimited group assignments to records, custom layouts for each group, login/sudo capabilities and much more.
#1735 - Security Group can not be removed from the record by non-admin user
Hello Jason, There is a bug in SugarCRM 6.5.x which affects SecuritySuite as well. Currently, my instance is at 6.5.20 version. I think that the bug is not corrected in 6.5.22. Please see bug "Defect 64702: Ability to have Separate restrictions for the Remove Button of Relationships" https://web.sugarcrm.com/support/issues/b421db44-e253-76a2-5bb1-521cca6a1737
This is how it affects SecuritySuite: - User Role for SecuritySuite module is configured according to the guidelines https://www.sugaroutfitters.com/docs/securitysuite/faq Access: Enabled Delete: None Edit: None Export: None Import: None List: All View: None So, users are able to assign any SecurityGroup to the records (e.g. to the Account records), however they can not remove any groups from the record details (e.g. Account record details)
There are 2 ways they can remove the group from the records: - either from the list view (Account listview) with Mass update panel: find record and do MassUpdate --> Remove (selected group) - either to allow Delete access right for SecurityGroup (in the Role), so the Delete button will appear in the subpanel. However, in that case users can navigate to SecurityGroups module and permanently delete security group records.
Do you have any recommendation for the above problem?
Many thanks, Igor Vitorac
-
"Very responsive development team, both in their communication and in having improvements incorporated and issues resolved." - kevin
Read More Reviews
- Most Recent Love from Users
kacsoristvan- damien8105
- anri
- Administrador
- Stefano1
- einkauf2
9 years ago
Hi Igor,
Yes, this is a long time shortcoming with SugarCRM. I don't presently have a workaround for it. I could see adding a new column for Relate rights that determine what you can do with data in the subpanels (Add, Remove, View).
For now, if this is something critical for you then I'd recommend working back to where that show/hide button logic is and hijack it to make it work the way that you would want.
9 years ago
Hi Jason,
I don't think it is a good idea to deal with the Relate rights. We should leave that job for the guys from SugarCRM.
I would recommend that SecuritySuite prevents anybody to delete (before_delete logic_hook) any active group, i.e. group that has at least one user assigned to it. If somebody really wants to delete a group, that user would need first to remove all users from the group, and then proceed with the Delete action of the group. This principle gives enough flexibility, so that even non-admins can manage the groups (add/delete), but at the same time they will not break security roles/groups setup.
Would it be safe if I put before_delete logic_hook for SecurityGroups to prevent deletion of non-empty groups? I mean, would it have any side effects for the operation of the SecuritySuite module?
Many thanks, Igor
9 years ago
A before_delete hook is a safe and effective way of doing what you want here. That's a great idea!
9 years ago
Enabling Delete action at the Role level and checking delete action in before_delete logic_hook is proven concept that we have implemented in many modules. It simplifies Roles access management and it gives users maximum flexibility to manage dependent records.
It would be really good to see Group delete prevention for non-empty groups in your upcoming releases.
In such case, I would recommended the following Role setup for the end users (https://www.sugaroutfitters.com/docs/securitysuite/faq) Access: Enabled Delete: All Edit: None Export: None Import: None List: All View: None So, users will be able to assign any SecurityGroup to the records, and they WILL BE ABLE to remove any groups from the record details, without possibility to delete the group (if they go to the SecurityGroups module).
I hope this might be useful to somebody.
From my side, you can close this bug.
Many thanks again, Igor
9 years ago
Thanks Igor! I'm flipping this over to a feature request.