Bug 25701 - Facets display in random order
Summary: Facets display in random order
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic data support (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on: 3580 14419
Blocks:
  Show dependency treegraph
 
Reported: 2020-06-09 15:54 UTC by Fiona Borthwick
Modified: 2020-12-07 12:02 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:
20.11.00, 20.05.01, 19.11.07, 19.05.12


Attachments
Bug 25701: (bug 14419 follow-up) Always display facet groups in the same order (1.46 KB, patch)
2020-06-10 10:06 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 25701: (bug 14419 follow-up) Always display facet groups in the same order (1.50 KB, patch)
2020-06-10 10:25 UTC, David Nind
Details | Diff | Splinter Review
Bug 25701: (bug 14419 follow-up) Always display facet groups in the same order (1.56 KB, patch)
2020-06-10 11:00 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 25701: Remove sort on removed field (847 bytes, patch)
2020-06-10 11:00 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Fiona Borthwick 2020-06-09 15:54:07 UTC
This issue has been raised by our customers following an upgrade to 19.11 but I can still reproduce at 20.05.

It is also apparent on both the OPAC and the staff interface.

Search the catalogue and see the results page. Facets on the left appear in one order.
Repeat the same search immediately and the facets appear in a different order.

There is no consistency to this random order.

For example - search one:

Holding Libraries
Series
Topics
Authors
Item types
Places 
Locations

Search two:

Holding Libraries
Topics
Item types
Series
Authors
Places
Locations

Each search we carry out seems to yield different facet orders.

Whilst possibly cosmetic, our customers would like to see consistency - especially for the OPAC as it can cause confusion for end users.

We have toggled use_zebra_facets between 0 and 1 in koha-conf.xml but makes no difference.

Testing on a live server at 18.11, we can confirm that the order the facets appear remains consistent.
Comment 1 Jonathan Druart 2020-06-10 10:06:37 UTC
Created attachment 105679 [details] [review]
Bug 25701: (bug 14419 follow-up) Always display facet groups in the same order

It seems that this regression comes from bug 14419, but I have not found
a logic reason behind that.
This patch restores the behaviour we always had: facet groups must be
displayed in a given order: the Zebra index (au, ccode, holdingbranch,
etc.)

Test plan:
Apply this patch, restart all and confirm that the facets are not moving
up and down when you refresh your search result page.

QA note:
I think the following line must be removed
@facets_loop = sort {defined $a->{expand} && defined $b->{expand} && $a->{expand} cmp $b->{expand}} @facets_loop;
Comment 2 David Nind 2020-06-10 10:25:35 UTC
Created attachment 105681 [details] [review]
Bug 25701: (bug 14419 follow-up) Always display facet groups in the same order

It seems that this regression comes from bug 14419, but I have not found
a logic reason behind that.
This patch restores the behaviour we always had: facet groups must be
displayed in a given order: the Zebra index (au, ccode, holdingbranch,
etc.)

Test plan:
Apply this patch, restart all and confirm that the facets are not moving
up and down when you refresh your search result page.

QA note:
I think the following line must be removed
@facets_loop = sort {defined $a->{expand} && defined $b->{expand} && $a->{expand} cmp $b->{expand}} @facets_loop;

Signed-off-by: David Nind <david@davidnind.com>
Comment 3 Nick Clemens 2020-06-10 10:33:16 UTC
(In reply to Jonathan Druart from comment #1)
> Created attachment 105679 [details] [review] [review]
> Bug 25701: (bug 14419 follow-up) Always display facet groups in the same
> order
> 
> It seems that this regression comes from bug 14419, but I have not found
> a logic reason behind that.
> I think the following line must be removed
> @facets_loop = sort {defined $a->{expand} && defined $b->{expand} &&
> $a->{expand} cmp $b->{expand}} @facets_loop;

Afaict the line you change in the patch never worked, we always relied on the secondary sort line you mention above.

I removed the 'expand' field in my patches on 14419 set which broke the second (actual) sort

I agree we should remove this line and fix the first sort
Comment 4 Jonathan Druart 2020-06-10 10:50:18 UTC
Nick, did you understand why your patches break the sort?
Comment 5 Nick Clemens 2020-06-10 11:00:48 UTC
Created attachment 105682 [details] [review]
Bug 25701: (bug 14419 follow-up) Always display facet groups in the same order

It seems that this regression comes from bug 14419, but I have not found
a logic reason behind that.
This patch restores the behaviour we always had: facet groups must be
displayed in a given order: the Zebra index (au, ccode, holdingbranch,
etc.)

Test plan:
Apply this patch, restart all and confirm that the facets are not moving
up and down when you refresh your search result page.

QA note:
I think the following line must be removed
@facets_loop = sort {defined $a->{expand} && defined $b->{expand} && $a->{expand} cmp $b->{expand}} @facets_loop;

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 6 Nick Clemens 2020-06-10 11:00:51 UTC
Created attachment 105683 [details] [review]
Bug 25701: Remove sort on removed field

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 7 Nick Clemens 2020-06-10 11:01:50 UTC
(In reply to Jonathan Druart from comment #4)
> Nick, did you understand why your patches break the sort?

Because I removed the 'expand' field - that was the sort that actually sorted.

That initial sort did nothing. See bug 3580
Comment 8 Jonathan Druart 2020-06-15 10:01:10 UTC
Pushed to master for 20.11, thanks to everybody involved!
Comment 9 Lucas Gass 2020-06-17 21:46:28 UTC
backported to 20.05.x for 20.05.01
Comment 10 Aleisha Amohia 2020-06-18 05:53:19 UTC
backported to 19.11.x for 19.11.07
Comment 11 Victor Grousset/tuxayo 2020-06-19 03:57:06 UTC
Backported to 19.05.x branch for 19.05.12