Suitecrm: Favorites Doesn't work after upgrade from (at least) 7.3.1

Created on 25 Aug 2016  路  20Comments  路  Source: salesagility/SuiteCRM

Issue

When upgrading to 7.4.4 from 7.3.1 (the only available upgrade path to 7.7.2) the favorites functionality doesn't work in basic or advanced search. This is not resolved even after taking the next two upgrades to get to 7.7.2.

Expected Behavior

When you click "My Favorites" checkbox, then click search, the checkbox should stay checked and the results should only include favorites.

Actual Behavior

When you click "My Favorites" checkbox, then click search, the checkbox is unchecked on refresh, and all records are shown (not just favorites).

Possible Fix

Steps to Reproduce

  1. Install 7.3.1 with data in it
  2. Upgrade to 7.4.4
  3. Add "My Favorites" to search layout (basic and/or advanced)
  4. Mark a record as favorite
  5. Search for favorite records, using the checkbox.

    Context

This is high priority to me, because I cannot upgrade to 7.7.2 from 7.3.1 until this is resolved for fear it'll be harder to resolve after the upgrade. According to the forum, I'm not the only one experiencing this problem.

https://suitecrm.com/forum/suitecrm-7-0-discussion/6904-7-4-favourites-how-do-you-filter-listviews

Your Environment

  • SuiteCRM Version used: 7.3.1 then 7.4.4 (eventually 7.7.2)
  • Any Browser
  • MySQL
  • PHP 5.6
  • CentOS
Moderate Requires Updates Bug

All 20 comments

This issue relates to issue #2030
it appears this is duplicate of 2030

@ijdavie & @shogunpol, this is not a duplicate of #2030. For one thing, that issue was not introduced until 7.7.2. For another thing, a fix was provided on that issue, which I have applied to my 7.7.2 installation and it does not fix this issue.

This issue is specifically related to the available upgrade path for users/admins prior to 7.4.4 trying to get to 7.7.2. Checkout the form post I referenced for more information.

Please do not mark this as duplicate, and please do not close it, as I need some attention to this issue to allow me to catch up to the current version.

I have looked through the issues addressed in 7.3.2 to see if possibly there was something changed there that made the 7.4.4 upgrade work for people who had applied 7.3.2, but not for people who were still on 7.3.1, but I didn't find any issues that seem like they would have / could have been related.

I have reopened this and removed the duplicate tab for the time being, @shogunpol will follow the steps to reproduce and apply this fix for 2030. He will keep you updated on how he gets on.

Thanks @shogunpol & @ijdavie!

I'm going to follow the steps I indicated, and verify the issue is in fact reproduced that way. The reason being, it is possible that my installation is not exactly the same as a 7.3.1 fresh install since it started on an earlier version and was upgraded, plus has data on it. Please standby for more information.

Well, that didn't really work out, because I'm not getting a good install of 7.3.1... the CSS basically isn't working right and I have a mess after install even though I don't get any errors and it seems to technically run OK after. Weird. Is it possibly my PHP verison 5.6.24? Was that supported on 7.3.1? The compatibility matrix only goes back to 7.4.4.

Other information that may be relevant....
I have custom modules deployed (some I created as well as KReporter). If things like this are creating the issue, I have no way of knowing if a default install of 7.3.1 followed by an upgrade to 7.4.4 will reproduce the issue or not.

Also, I would be willing to try and track this down with some assistance from development team. I have compared the HTML Source through the browser on a 7.7.2 clean install with the HTML of my upgraded-to-7.7.2 install and they are the same, so I know the issue must come after that. I just don't know what files to go look at next for differences. I don't know what functions (and what files host those functions) on a form submit. For example, I haven't found where this function is defined: <input tabindex="2" title="Search" onclick="SUGAR.savedViews.setChooser();" class="button" type="submit" name="button" value="Search" id="search_form_submit"/>&nbsp;

Hi @sieberta,

you want to look at the file
include/MVC/View/views/view.list.php around line (256). this line should return the $where_clauses which should contain the where for the favourites, depending on what is returned here will depend on where next to look.

We have followed your steps and so far not been able to replicate this after we have put the fix given in #2030 of course. Let me know how you get on.

Ian.

Thanks @ijdavie,

That led me down a never ending rabbit hole, but I did find some interesting information. Favorites search WORKS on calls. A couple of things different about calls than accounts/projects for me.

  1. Calls doesn't have any custom fields
  2. The "My Favorites" option, I think, might have been auto-added during upgrade, rather than added by me after the fact.

I'm leaning toward custom fields being the culprit. I'm wondering if /custom/modules/Accounts/metadata/SearchFields.php isn't properly merged with /modules/Accounts/metadata/SearchFields.php (which contains the definition for the where clause for favorites).

I have sorta confirmed this by deleting SearchFields.php from /custom/modules/Accounts/metadata/SearchFields.php and not doing a repair/rebuild then doing a search for favorites and it works!

Any suggestions for me based on this additional information?

OK, more info.... I see that if I add a custom field in my clean install of 7.7.2 the SearchFields.php file in the custom directory contains this code, whereas mine does not:

array ( 'query_type' => 'format', 'operator' => 'subquery', 'checked_only' => true, 'subquery' => 'SELECT favorites.parent_id FROM favorites WHERE favorites.deleted = 0 and favorites.parent_type = \'Accounts\' and favorites.assigned_user_id = \'{1}\'', 'db_field' => array ( 0 => 'id', ),

So now, other than going through all of my custom SearchField.php files, and adding this code, how do I fix it?

OK, so apparently that has nothing to do with custom fields, and instead has to do with custom layouts. When I add "My Favorites" to Basic or Advanced Search (at least for accounts & projects) the associated snippit of code referenced above doesn't get inserted.

I have upgraded and it is working. I manually copied and pasted the necessary information from the /modules/[module]/SearchForm.php to the /custom/~

I see others on the forum that had to do the same...

I am in an OK place with my running system at the moment, but it seems like this might need addressed in future versions.

@sieberta ,is this issue appear only when you try to implement favourites in custom modules? Or it also happens in core module, i am unable to replicate this issue in the core modules, but i can on custom modules.
We have labelled this is as a bug, due to this.

Good morning (in the US :)). This is a problem in core modules as well. Calls & Meetings were no problem, but Accounts & Contacts both required this fix. I noticed yesterday that I, at some point, loaded a hotfix that I wonder if could be part of the problem.

Details on the Hotfix are Here:
Bug 57145+64058 6514-6517 (ALL)
module
1407516766
11/06/2014 03:17pm
HotFix: Labels not being changed if a custom package is loaded / Labels Do Not Change in Studio when Created Via Extensions

Interestingly, I have lower case and upper case (i.e. projects and Projects) for projects, accounts, and contacts in custom/modules which were the three problematic modules. I'm not sure when these showed up... if this is something related to an upgrade along the way, or perhaps something else...

I wonder if this might not be related.

@sieberta, have you upgraded to the latest version of SuiteCRM ? and does this issue still occur ?

@ijdavie
I don't know ijdavie. I'm on the latest version, but I manually copied the information... as mentioned in previous posts... so I don't know if any upgrade would've fixed it.
sieberta

The issue has been tested in recent version of SuiteCRM(7.7.8), and not appear,
@sieberta , please confirm and if, can you close an issue.

@shogunpol,

Thank you for investigating. As you see in my prev. post, because I manually fixed the issue, I cannot report if any newer version fixes the issue.

Sincerely & Happy New Year!
sieberta

This issue is not fixed by an upgrade.

For anyone upgrading you need to copy the SearchFields.php from the [Module]/Metadata/ folder to custom/[Module]/Metadata/

Many thanks sieberta

Was this page helpful?
0 / 5 - 0 ratings