Control what your users can access and save time, money, and frustrations. Lock down sensitive data in 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.
#2218 - Custom Layouts Always Saving As Default
Hello, We have recently upgraded to SuiteCRM 7.11.7 and Upgraded our Security Suite to 3.1.17. When we try to create a new layout for a security group the changes we make to the layouts always save as the default.
Here's an example of what happens: 1. Open the Leads module in the Studio and click "Layouts" 2. Create a layout for our group I'll name "Training" for the purpose of this. 3. Open the newly created "folder" that shows up under Layouts and edit the Edit View. I can see the breadcrumbs correctly show my group name. "Studio > Students > Layouts > Training > Edit View" 4. Click Save & Deploy. I get the generic message about required fields being hidden. At this point, I can still see that it says "Studio > Students > Layouts > Training > Edit View". Once I press "Ok" I notice that it refreshes as it normally goes and gives me the popup "This operation is completed successfully". However, it has now sent me to the Default view, with the changes I tried to do with Training. The breadcrumbs also now indicate "Studio > Students > Layouts > Default > Edit View". If I go back to the Training view, the changes aren't there. (But are there for the default view).
We've tried to quick repair, rebuild roles, rebuild relationships with no luck. The layouts never worked for us but they did save. We were hoping by upgrading it would've resolved any problems however it wasn't the case. Any help would be appreciated.
-
"The add-on itself was already a must for my SuiteCRM, which was missing this very important security feature. However, what surprised me the most was ..." - Davint
Read More Reviews
Larry Rudd
5 years ago
Hello,
This has happened before a few times and each time it was due to file permissions not being correct. So when you save and deploy it isn't able to actually create the new layouts. To correct permissions look for points 4 and 5 under the Copying SuiteCRM files to web server at https://docs.suitecrm.com/admin/installation-guide/downloading-installing/.
If you still have issues try opening permissions wide open to 777 on the custom and cache directories simply to test a save and deploy and see if it works. Then dial it back and find out what is the correct permissions and file/directory ownership for your server.
Hope this helps! -Jason
5 years ago
Hi, Unfortunately, it did not. I even changed the entire directory to 777, did the repairs including the one for JS, made sure apache has access to the files. It's still producing the same issue. It's not that it's not saving at all, it's saving the default view instead of the security group's view (which does appear in the list of layouts).
5 years ago
When you save and deploy check the following folder to see if your group layout is actually saving:
/custom/modules/Leads/metadata/{group_id}/editviewdefs.php, etc
The {group_id} will be the database ID for your security group that you are creating the layout for. If that is not there then for whatever reason it is not able to create the directory along with the files there.
If it is there and you go to access the edit view as a user in that team it should then create the cached version in:
/cache/modules/Leads/{group_id/EditView.tpl, etc.
Let me know what you find around that.
5 years ago
It is not saving the /custom/modules/Leads/metadata/{group_id}/editviewdefs.php file when I deploy, it's saving the changes in /custom/modules/Leads/metadata/editviewdefs.php which is the default view. Just as a test I removed a field manually from the /custom/modules/Leads/metadata/{group_id}/editviewdefs.php and it removed it properly from studio/the view so its definitely a saving issue.
5 years ago
Tried replicating this on a 7.11.7 instance and it is working with every scenario I can think of for the Leads module. Could you list what you have installed in Module Loader? I wonder if there is a conflict somewhere causing the deploy to not create the directory. I still lean towards the permission/ownership side though. The user/group that Apache is running under may not have appropriate permissions to overwrite the editviewdefs.php file.
Another possibility is that the install of SecuritySuite 3.1.17 didn't copy all files over due to permissions. Could you check /modules/ModuleBuilder/parsers/views/DeployedMetaDataImplementation.php and see if there is a /* BEGIN - SECURITY GROUPS */ on line 404? If not, an install will need to be done again. This will require tricking SuiteCRM by unzipping the SecuritySuite install zip, editing manifest.php, changing the version number to 3.1.17_1, saving, rezipping, and uploading. Otherwise it will act like it installed again, but actually doesn't as it sees that the same version number is already installed.
5 years ago
That editviewdefs file and directory is set to 777 and both files have the same permissions as the default files. I've also looked at our logs and I don't see anything in the suitecrm.log or sugarcrm.log or even our PHP logs. I do see the BEGIN - SECURITY GROUPS.
As for what we have installed, its: SQL Query Lion Solution CRM Defender SecuritySuite - Enhanced, Professional, and Enterprise tagMe Analytic Reporting French (Canada)
5 years ago
Is there any way that I could help debug this? If so, please email solutions@eggsurplus.com with both a temp SuiteCRM admin account and SSH access. The focus will be on figuring out why Save & Deploy isn't writing to that specific file. No changes to permissions outside of /custom/modules/Leads and possibly /cache/modules/Leads will be made. All work done will be recorded and shared.
5 years ago
This happened recently with another user. What was found was that a custom theme was being used that had the following file:
\themes\SuitePImproved\modules\ModuleBuilder\tpls
The solution was to merge in the code from:
modules/ModuleBuilder/tpls/layoutView.tpl
Look for the following chunk of code on line 239:
{* BEGIN - SECURITY GROUPS } { END - SECURITY GROUPS *}
However, this specific SuitePImproved is now included in SecuritySuite as of 3.1.18. As long as SecuritySuite is installed after the SuitePImproved theme is installed then this issue will be fixed automatically.
Hopefully this helps someone else who runs into this issue.