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.
#609 - custom groups layouts not working correctly
Hi,
we have SecuritySuite installed in our SuiteCRM system and are having problems using custom group layouts.
We have SecuritySuite installed on two instances of SuiteCRM - test and live. In test everything is working fine and the custom group layouts we have created are working as expected. However in live the custom layouts are showing some strange behaviours.
We have created our custom layouts for the "contacts" module. When we are in the "list" view for contacts and click the "create" button or the "create contact" from the "contacts" menu we see the correct custom "edit" layout. Before saving a new contact if we then click "create" again we are now incorrectly shown the default "edit" layout.
The same happens when viewing contacts. If we are in the "list" view and click on a contact then we are shown the correct custom "detail" layout. Now if we click the "next contact" arrow button at the top of the page or select a recently viewed contact from the contacts menu we are shown the incorrect default "detail" layout.
Basically the first contact viewed or edited directly from the contacts "list" view is shown with the correct custom layout while all other ways of navigating to a contact "detail" or "edit" layout results in the incorrect default layouts being shown.
Both the test and live instances are running the same version of SuiteCRM (7.4.3) and the same version of SecuritySuite (2.9.2). As I mentioned the test instance is fine and there are no problems with the custom layouts. I have compared the live and test instances to see what differences there are that may be causing this problem. As far as I can see test and live are very similar - one difference is that we have "SugarChimp" installed and active on our live instance but not on test.
I have reviewed the log file and cannot see any error or warning messages being generated that are related to this problem.
Could you please let me know what actions to take next to try and fix this issue.
-
"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
7 years ago
Would you happen to have some sort of opcode cache on the live server such as Memcache or APC? If so, try disabling that and see if the layouts show correctly.
The other possibility is that there are file permission issues causing the custom layouts to cache in the SuiteCRM /cache directory incorrectly. The custom group layouts live in /custom/modules/Contacts/metadata/[group ID]/. When someone first goes to a custom group layout it then gets cached by SuiteCRM to /cache/modules/Contacts/[group ID]/ for each view. There may be something in the live environment causing that not to work correctly.
Hope this helps.
7 years ago
Thanks for your suggestions.
The live and the test instances are running on the same server through the same apache2 service so I don't think it can be a php caching issue - but just to be sure I did disable the cache for a while and the problems were still present in the live instance.
I thought the suite caching and file permissions sounded a more probably cause of the problems. I have checked the "default_permissions" suite settings and they were the same for both instances. I also checked the permissions of the directories (and any contained files) you listed and could not see any differences there either.
I do think it may be still be a suite caching issue - there definitely appears to be something strange with the live instance - and the problem looks a more general problem than just related to SecuritySuite. For example often after I perform a "Quick Repair and Rebuild" and then go the security group list view all my security groups show a blank "Assigned to" user field when they are in fact all assigned to the admin user. If I perform a "Quick Repair and Rebuild" again (sometimes it has to be twice) then I get the "Assigned to" user field correctly showing the admin user again. While in this strange state the assigned user field for many of the recent contacts I have entered while testing this problem appear blank too and then also re-appear at the same time they re-appear in the security group list view. This strange behaviour only occurs on the live instance.
Any other suggestions you could provide would be greatly appreciated.
7 years ago
It sounds like you are on the right path. Sometimes running a general permissions fix script will do the trick, as long as the default_permissions are right. Here's a script that I usually recommend for getting it back to where it should be: http://shanedowling.com/sugarcrm-permissions-script/
Also be sure to check on file/directory ownership. That one can be easy to miss sometimes.
7 years ago
I applied the permissions script as you suggested but this did not fix the problem.
Today I made a clone of the live instance on the same server so I could do more testing without affecting our users. First I verified the clone instance had the same problems which it did. Having only myself as a user meant the log file was not cluttered with other users requests. I switched logging to debug level. I then went to the contacts modules and clicked the "create" button twice as previously described. The first resulting edit view page was the correct custom group layout the second resulting page was the incorrect default layout page. I then did a comparison of the two log sessions and could see that there were differences in the securitysuite module's behaviour. For example the first sql query done involving securitygroups in each create session was different:-
create1: [INFO] Query:select securitygroups.id, securitygroups.name from securitygroups_users inner join securitygroups on securitygroups_users.securitygroup_id = securitygroups.id and securitygroups.deleted = 0 where securitygroups_users.user_id='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' and securitygroups_users.deleted = 0 order by securitygroups.name asc
create2: [INFO] Query:select securitygroups.id from securitygroups_users
You can see the sql queries are quite different.
Then in the create2 session there is the log line:-
create2: [DEBUG] metadatafile=custom/modules/Contacts/metadata/editviewdefs.php
This seems to show that the default edit view is being selected. This line above does not appear anywhere in the create1 session.
I can provide the log files for you to inspect if you want.
7 years ago
Unfortunately the queries are unrelated. What version of SuiteCRM and SecuritySuite are you currently running? Is it the same version as on the test/dev site that works? You can get the SuiteCRM version on the About page and SecuritySuite version from Admin->Module Loader.
7 years ago
All instances I have been testing regarding this issue are at the same version - as I included in my first post:-
SuiteCRM version 7.4.3 SecurityGroups - Full Edition version 2.9.2
7 years ago
That would be the problem. Around that time SuiteCRM changed how themes worked which caused this exact issue. If it is not possible to upgrade SuiteCRM and SecuritySuite then I can send over a patched version for 7.4.3.
7 years ago
We are planning to upgrade suite but we cannot do so at the moment. So yes please send over a patched version that works with Suite 7.4.3. You can send it to the email address linked to this account.
7 years ago
Hi. Not sure if you have seen our last comment. Yes we would like the patched version of SecuritySuite that works correctly with Suite 7.4.3. Thanks.
7 years ago
Been trying to figure this out, but can't see a problem with the 7.4.3 version. The theme issues that did cause issues with wrong layouts being displayed wasn't introduced until SuiteCRM 7.7 or so.
What I keep cycling back on is that it works on test, but not live. That's indicative of something being different between the two environments. I know you've checked, but it has to be very likely that it is one of the following issues:
It may help you debug to point out how these custom layouts work in SuiteCRM.
When a custom layout is created in Studio a new layout gets created in /custom/modules/[MODULE]/metdata in a folder named with the security group id. For example, if an Accounts layout is created for a Global group with an ID of xxxx-yyyy-zzzz the path would be:
/custom/modules/Accounts/metadata/xxxx-yyyy-zzzz
This directory would contain the normal files (detailviewdefs.php, etc).
Whenever a user first accesses that custom layout it gets cached in SuiteCRM to:
/cache/modules/Accounts/metadata/xxxx-yyyy-zzzz
For example, the detailviewdefs.php would go to:
/cache/modules/Accounts/metadata/xxxx-yyyy-zzzz/DetailView.tpl
If a user is not in a group with a layout the it would pull up the default layout from the cache:
/cache/modules/Accounts/metadata/DetailView.tpl
With this in mind I would suggest running some tests and seeing which layout it is showing from the /cache folder. Then check the cached file to see if it includes/excludes certain fields that you expect to show/not show. If the cached file is right, but it isn't showing correctly then something is up with the server not fetching the correct cache. Usually that would be an opcode cache that would run into that problem.
Hope this helps!
7 years ago
Thanks for for feedback and explanation. I had already got a fairly good understanding of how custom layouts worked within the file structure of Suite and had been looking at how the caching of template files showed up from the different metadata directories.
I have spent so long checking for the differences (or lack of differences) between the test and live instances that I have run out of options - even though I had already checked the directory/file permissions on the live and test instances I did run the script you suggested as I wrote in my comment of 5 days ago - it made no difference. As to opcode caching - I don't have a lot of experience in this area but as both the live and test instances are running through the same apache service on the same server I would not think this is the problem?
I had done some previous monitoring of the cache directories as the cloned live instance is being used. It was this behaviour that got me to look deeply into the log file and find the differences in the sql statements and the "[DEBUG] metadatafile=custom/modules/Contacts/metadata/editviewdefs.php" line which seemed to show the wrong layout template file was being read for the second create.
Here is the relevant file listings for the /cache/modules/Contacts directory:-
du -a
4 ./c6f511e9-c8a1-96d9-3701-59b29180d76d 68 ./Contactvardefs.php 16 ./language/en_us.lang.php 20 ./language 104 .
du -a
196 ./c6f511e9-c8a1-96d9-3701-59b29180d76d/EditView.tpl 200 ./c6f511e9-c8a1-96d9-3701-59b29180d76d 68 ./Contactvardefs.php 16 ./language/en_us.lang.php 20 ./language 300 .
du -a
196 ./c6f511e9-c8a1-96d9-3701-59b29180d76d/EditView.tpl 200 ./c6f511e9-c8a1-96d9-3701-59b29180d76d 68 ./Contactvardefs.php 172 ./EditView.tpl 16 ./language/en_us.lang.php 20 ./language 472 .
Looking at the size of the EditView.tpl files show them to be different files - the custom one being slight bigger (193KB vs 172KB) which would be consistent as the custom layout is basically the same has the default one just with an extra couple of custom attributes added.
The behaviour is consistent and repeatable. If I go back to the Contacts list view and then click the "create" button again I then get the correct custom edit layout shown on the page. I can only think that some code executed during the list view sets a php session variable regarding the user's security groups (or something similar) and that particular session variable is cleared (or is set to a different value) when other pages are viewed first before clicking the "create" button.
7 years ago
This is helpful. Are you using the default theme that SuiteCRM 7.4.3 comes with? Any other modules installed in Module Loader.
7 years ago
The "Suite 7" theme is the default in our instances, the theme "Suite R" is available but I don't is being used by anyone. During all the testing of this issue I have been using the "Suite 7" theme.
The modules installed (apart from SecurityGroups - Full Edition v2.9.2) are SugarChimp v7.9.1d and some modules of our own that we have developed and deployed.
7 years ago
Have you managed to make any progress on this problem? I have been trying lots of ideas/tests to try and find out what is going on. I came across this suitecrm forum thread that seems to be same problem as we are having - https://suitecrm.com/forum/developer-help/15158-assigned-user-name-is-blank
Sometimes the "assigned to" field in modules show up blank. When we are in this situation if I list security groups then the assigned to column is blank. Normally after one or two "quick repair and rebuild" commands the problem is fixed and the assigned to values are visible again. I mentioned this behaviour in my second comment in this thread. So it might not be a securitysuite issue but something strange happening in suite in general. Have you heard of this problem before? And given this info do you have any suggestions?
7 years ago
What I do know is that around this time SuiteCRM made some significant changes around themes and how caching works. There were some bugs with it. They have since worked those out in more recent versions. Is there any way to upgrade SuiteCRM on a test instance and see if that solves the issue?
5 years ago
A similar issue was found and solved at https://store.suitecrm.com/support/securitysuite/1657.
The solution is to have the user log out so that it resets their session. Hope this helps someone else who comes across this!
Thanks, Jason