by eggsurplus

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.

Cancel at any time!
Free Trial

#609 - custom groups layouts not working correctly

Closed Bug? created by admin6 Verified Purchase 3 years ago

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.

  1. eggsurplus member avatar

    eggsurplus Provider Affiliate

    3 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.

  2. admin6 member avatar

    admin6 Verified Purchase

    3 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.

    • eggsurplus member avatar

      eggsurplus Provider Affiliate

      3 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.

  3. admin6 member avatar

    admin6 Verified Purchase

    3 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.

    • eggsurplus member avatar

      eggsurplus Provider Affiliate

      3 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.

    • admin6 member avatar

      admin6 Verified Purchase

      3 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

    • eggsurplus member avatar

      eggsurplus Provider Affiliate

      3 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.

    • admin6 member avatar

      admin6 Verified Purchase

      3 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.

  4. admin6 member avatar

    admin6 Verified Purchase

    3 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.

    • eggsurplus member avatar

      eggsurplus Provider Affiliate

      3 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:

      • permissions issue causing the correct layout to not be readable so it shows the incorrect one
      • permissions issue causing the correct layout to not be able to be cached to /cache/modules/[MODULE]/metadata/[SECURITY GROUP ID]
      • some configuration on live such as a cache configuration that does not exist on test
      • a code customization exists that alters core SuiteCRM logic other than SecuritySuite

      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!

    • admin6 member avatar

      admin6 Verified Purchase

      3 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:-

      1. first logged in an administrator I perform a "quick repair and rebuild" - the cached files are cleared out

      du -a

      4 ./c6f511e9-c8a1-96d9-3701-59b29180d76d
      68 ./Contactvardefs.php
      16 ./language/en_us.lang.php
      20 ./language
      104 .

      1. then logged in as a user that is in a security group that has a custom layout for the edit view for Contacts I go to Contacts and click the "create" button - the correct custom edit layout is shown on the page

      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 .

      1. then still logged in as the user in step 2 without saving a new Contact I click the "create" button again - this time the incorrect default edit layout is shown on the page

      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.

    • eggsurplus member avatar

      eggsurplus Provider Affiliate

      3 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.

    • admin6 member avatar

      admin6 Verified Purchase

      3 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.

  5. admin6 member avatar

    admin6 Verified Purchase

    3 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?

    • eggsurplus member avatar

      eggsurplus Provider Affiliate

      3 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?

  6. eggsurplus member avatar

    eggsurplus Provider Affiliate

    2 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

This case is public. Please leave out any sensitive information such as URLs, passwords, etc.
Saving Comment Saving Comment...
Rating
  • "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