List view columns order changes when using My Filters

Hi everyone!

Me and my customer users noticed strange behavior with list view for all modules:

  • when using list view without a filter I have one columns order
  • when using My Filter (created in Advanced Filter section) filters from the dropdown the order of column changes
  • when I turn off filter column order remains as it was in that custom filter
  • if I use another custom filter, order changes and when that other filter is turned off, column order remain as it was in that another custom filter

These changes confuse users and is a quite large problem in using the system…

I could not find a relation in saving custom filters and column order changes save whatsoever.

It would be great to have the possibility for each custom advanced filter to have different column order, but I do not know how to achieve that.

Any immediate suggestion/help is highly appreciated.

Version: 7.11.8
Platform: LINUX hosting account

Regards,

Mario

I think the filters do store the list and order of columns, apart from the search criteria, of course.

If you look in the database it might help to make sense of what’s happening:

Table saved_search
Row(s) that corresponds to your module

Grab the “contents” field and decode it here: https://www.base64decode.org/

There you can see the column list inside.

So the fact that these change when you apply a filter sounds good to me.

The bug seems to be when clearing a filter, then the default column order is not being applied, and it should.

Do you agree with my reading of the case? Or am I missing something?

1 Like

Hi!

I confirm behaviour you described.

And also confirm that after turning off the saved filter the columns order does not revert to default, but remains as it was in the last used custom saved filter.
This I see as a bug and please consider to resolve this at earliest convenience - in the next update if possible…

Many thanks in advance!

Best regards,

Mario Arbanas

Can you please report it on Github, with nice “steps to reproduce” and maybe add a few screenshots?

Hi pgr,

for the record, this is related to this issue.

My question is: why do you think it’s a good idea that filters store the column layout too? I’d think that filters and columns are “orthogonal” concepts

This is arguable, of course, and it might depend on the usage in particular cases.

I just think that it makes some sense to specify the columns I want to see with a certain filter.

For example, if I have a list with a column “type”, and then I filter it by a specific type=“rejected” value, then I don’t need the type column anymore (it would be always the same, “rejected”), and maybe I want an extra column “Rejection reason” to show.

I see, thanks for the clarification :slight_smile:

Here’s a patch for those who’d prefer that saved filters wouldn’t change che column layout :slight_smile:

--- modules/SavedSearch/SavedSearch.php
+++ modules/SavedSearch/SavedSearch.php
@@ -535,5 +535,13 @@
                 $_GET[$key] = $val;
             }
         }
+
+        if (isset($this->contents['search_module'])) {
+            $q = new StoreQuery();
+            $q->loadQuery($this->contents['search_module']);
+            $_REQUEST['displayColumns'] = $q->query['displayColumns'];
+        } else {
+            LoggerManager::getLogger()->warn("SavedSearch populateRequest: search_module not specified");
+        }
     }
 }
1 Like

This bug still exists in version 7.11.15

@Airbus yes, it seems there is a fix in the post above, but it was never proposed as a PR on GitHub, so it didn’t go into the product.

If you have any valuable feedback on it, like saying if the fix works and is satisfactory, you might want to comment on the GitHub issue linked above.

@pgr I’m not sure if I remember correctly, but I’d say my patch was of the “works for me”-kind and not ready for general use, mainly because it looked like the previous behaviour was intentional and someone may be relying on it. So I’m not sure how the SuiteCRM developers would prefer to handle this, maybe a new option?

Yes you’re right, it may need to be configurable. Maybe configurable per-filter? That would require an extra check box in the filter dialog box.

Sometimes a good option if we don’t have time or resources to build the entire UI is to use a setting in the database, so that people can tweak it, even if there is no UI for it. It becomes a “power-user” setting.