Generic filter value gets stuck after detail view (v3.0.1)

Support
1

A user reported a strange problem that I can reproduce, but have not been able to find the cause. The problem was not reported in prior versions of jmix (only since upgrade to v3 or 3.0.1).

>>> See update in next post! <<<

Short Description

On list view with custom data loader, filter by name, edit one entry, back to list, filter by different name, now list is empty and you can only fix it by leaving the screen and returning.

Long Description

It starts on a standard list view, but this view has a custom CollectionLoader because I sometimes need to filter by a dynamic value (expiration date > “today - 90 days”). This logic only comes into play when a checkbox on the view is checked. For this problem, the checkbox is unchecked and the custom loader does not change the WHERE clause.

On the list view’s generic filter, filter by <last name starts with “lane”>, tab out of filter field and the list is refetched and correctly shows only members with matching last name.

If you change the last name filter at this point, it works correctly and refetches according to the new last name value.

However, if you edit one of the members (i.e. go to detail view, then cancel) and return to the list, you initially see the correct filtered list. The URL now looks like this:

http://localhost:8080/memberses?genericFilter_genericFilterConfiguration=Number-NameYSISVuFH&genericFilter_genericFilterCondition=property%3AmemberNumber_equal_&genericFilter_genericFilterCondition=property%3AlastName_starts-with_lane&pagination_maxResults=50&pagination_firstResult=0

If I now change the last name filter to “mey”, the list reloads and is empty. The query generated by the fetch is (removed column list for readability):

SELECT * 
FROM MEMBER t1 LEFT OUTER JOIN SCHOOL t0 ON (t0.ID = t1.SCHOOL_ID) 
WHERE (LOWER(t1.LAST_NAME) LIKE ? ESCAPE ? AND LOWER(t1.LAST_NAME) LIKE ? ESCAPE ?) ORDER BY t1.MEMBER_NUMBER DESC, t1.ID ASC LIMIT ? OFFSET ?

bind => [lane%, \, mey%, \, 50, 0]

Notice the WHERE clause now has the last name value twice and the bind values are from the URL (lane) and the value from the current search (mey).

The only way we have found to get out of this condition is to navigate to a different screen, then back.

I have not been able to reproduce this on a list view without a custom data loader. Not sure if I need to change the way the loader is handled, or if something in jmix changed.

Thanks for your help!

-Jeff

3

Major update - I have been able to reproduce the problem on the standard user list view.

Here are the steps I used. Some of them may not be necessary, but I wanted to record everything just in case:

  1. Navigate to user list view
  2. Add generic filter on first name and last name
  3. Change comparison to “starts with” for both (probably not significant)
  4. Save the filter
  5. Make the filter the default
  6. Navigate away from the user view, then come back
  7. Filter by last name starts with “m” (or whatever matches your data)
  8. List view shows only matching users
  9. Edit a user, then click Cancel to return to list view
  10. Change last name filter value “m” to another letter that matches some data
  11. When the list reloads you get no records
4

Yes, we’ve confirmed and reproduced the problem on our side. Your custom loader has nothing to do with
it — it reproduces with a plain one as well.

Conditions: returning to the list view from a detail view when the URL already carries filter parameters
and the filter configuration is your personal default (the one you made default for yourself). What
happens: the filter value from the URL stays in effect in addition to the new one, so the list comes up
empty after you change the value. Navigating to another view and back resets the state.

This is a regression in 3.0.1; 3.0.0 is not affected.

We’ve created an issue for it: GenericFilter: a condition restored from the URL is duplicated in the data loader and freezes its value · Issue #5586 · jmix-framework/jmix · GitHub

Until the fix is released, one line in the list view controller works around it:

@Subscribe
public void onInit(final InitEvent event) {
    membersesFilter.setCurrentConfiguration(membersesFilter.getEmptyConfiguration());
}

Filter parameters in the URL, your default configuration and filtering all keep working as before. We
verified this against your scenario.