custom groups layouts not working correctly

Support October 6th, 2017 @ 7:51 am

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?

View Comment

custom groups layouts not working correctly

Support September 20th, 2017 @ 8:09 am

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.

View Comment

custom groups layouts not working correctly

Support September 19th, 2017 @ 2:52 pm

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

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 .

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 .

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.

View Comment

custom groups layouts not working correctly

Support September 18th, 2017 @ 8:30 am

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.

View Comment

custom groups layouts not working correctly

Support September 13th, 2017 @ 5:47 pm

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.

View Comment

custom groups layouts not working correctly

Support September 13th, 2017 @ 4:47 pm

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

View Comment

custom groups layouts not working correctly

Support September 13th, 2017 @ 3:32 pm

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.

View Comment

custom groups layouts not working correctly

Support September 12th, 2017 @ 3:13 pm

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.

View Comment