Created attachment 20398 [details] [review]
Bug 10078 - show location facet for all

Currently, the location facet only shows if you have singlebranch
mode enabled. In other words, you can either see the library branch
or the shelving location.

This patch simply changes the location facet so that it will always
show the shelving location (if one is available), regardless of the
singlebranch system preference.

Test Plan:

BEFORE APPLYING:

0) Disable singlebranch mode if it is on
1) Do an OPAC or Staff Client search for a record that has items with
shelving locations.
2) Note that you can see the library branch facet under Libraries
but no shelving locations.
3) Enable singlebranch mode
4) Repeat your search
5) Note that you can no longer see the library branch facet under
Libraries. However, you can see the shelving location under Location

N.B. If you don't have more than one branch or the search results
are all from one branch, you might not get a library branch facet.

If this is the case, create additional branches and/or change the
branch for items in your search results so that you have multiple
branches to prompt the appearance of a library branch facet.

AFTER APPLYING

1) Do an OPAC or Staff Client search for a record that has items with
shelving locations.
2) Note that you see a facet under Location on the left sidebar,
regardless of there being a singlebranch mode or the number of branches
there are being represented in the search results.

Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised.

I am not sure every library will be happy about this change. If I am not mistaken combining the branches and the location facet will give you 'wrong' results as always all items are taken into account for the search result. So if you your items look like this:

Item 1: Branch A, location C
Item 2: Branch B, location D

And you limit on Branch A and location D, the record will still be found. This will always happen when you combine item related facets.

Maybe we need a way to hide this facet for libraries who don't want to offer it. It could be as simple as having ids for CSS or a pref that lets you specify which facets you want to show. 

I think the search could probably be improved using DOM, but I am not sure this has been done yet and it would also still not work for libraries using GRS-1.

(In reply to Katrin Fischer from comment #4)
> I am not sure every library will be happy about this change. If I am not
> mistaken combining the branches and the location facet will give you 'wrong'
> results as always all items are taken into account for the search result. So
> if you your items look like this:
> 
> Item 1: Branch A, location C
> Item 2: Branch B, location D
> 
> And you limit on Branch A and location D, the record will still be found.
> This will always happen when you combine item related facets.
> 
> Maybe we need a way to hide this facet for libraries who don't want to offer
> it. It could be as simple as having ids for CSS or a pref that lets you
> specify which facets you want to show. 
> 
> I think the search could probably be improved using DOM, but I am not sure
> this has been done yet and it would also still not work for libraries using
> GRS-1.

I'm not sure that I understand your example, Katrin. 

1) If you limit on Branch A and location D, you should get no results in your scenario. 

2) In what scenario would you be able to use both those facets? (Using the Advanced Search, you could, but that's unrelated to the facets.) 

If you choose Branch A from the Libraries facet, you would only be presented with location C as a Locations facet. If you choose location D, you would only be presented with Branch B as a Libraries facet.

The only time where that would be different is if you had:

Item 1 (Bib #1): Branch A, location C
Item 2 (Bib #2): Branch B, location D
Item 3 (Bib #1): Branch A, location D

In that case, you could limit on Branch A and location D, and you would get a search result for Bib #1 showing item availability for Item 1 and Item 3. 

In that sense, I suppose that could be a type of wrong result, because you would only want to show availability for Item 3. 

I don't think it's an indexing issue though. From what I've seen so far, it seems to me that DOM and GRS-1 fill the same indexes, they just do it in different ways. 

In this case, I think the issue would be with how we're displaying items. If we want to limit what item availability shows up in the search results, we would need to start checking our limits when building item displays in the "searchResults" sub.

I don't think that's really a blocker for this bug though, as I mentioned, that same incorrect item availability would still occur by doing a Branch + Location query in the Advanced Search. I think that would be a separate issue.

That said, I'm certainly in favour of including facet IDs for CSS and/or using a system preference so that libraries can choose which facets to show.

Jared did an excellent job just now in IRC of clarifying your example, Katrin :). 

I think the best option will probably be to hide the Location facet in some way (probably CSS).

The problem I see with hiding Location based on singleBranch mode is that some libraries with a single physical branch might use several virtual branches, thus not wanting to use singleBranch mode, but still wanting to have the Location facet. 

I've actually just looked at the code, and all the facets already have IDs. Location's is "location_id".

Shall we set this back to Passed QA?

Perhaps it might be an idea to open another bug report to look at building facets better? 

Perhaps we could pass the @limits into the getRecords sub, or extract limits from the query within the sub...perhaps by testing against existing limits our search/facets would "narrow" rather than presenting all options (even ones that might not be make sense/that are incorrect).

Hi David,

I had checked for the ids, but somehow I still missed them - sorry!

I am setting it back to 'Passed QA', but still a bit worried that this might cause some unhappiness because the item based facets don't work as libraries expect. I recently had some trouble explaining that when it came to new books: When you are are a library with multiple branches a combined search for acquisition date and branch for example doesn't give you the results you'd expect. So in general a more precise way to search item data would be nice, but is out of the scope of this bug.

Hm maybe for others reading this we should clarify:

> 1) If you limit on Branch A and location D, you should get no results in
> your scenario. 

That would be how we want it, but it's not going to happen as for the facets always everything that appears in the record is taken into account. So all item information is mixed together - if you have a branch and a location appearing in your record, the facets will show up, even if the information belongs to different items.

> 2) In what scenario would you be able to use both those facets? (Using the
> Advanced Search, you could, but that's unrelated to the facets.) 

Yes, advanced search can give confusing results too - but I think it's a lot less obvious and users are not so likely to try.

> If you choose Branch A from the Libraries facet, you would only be presented
> with location C as a Locations facet. If you choose location D, you would
> only be presented with Branch B as a Libraries facet.

Unfortunately that's not the case - see explanation above.

> I don't think it's an indexing issue though. From what I've seen so far, it
> seems to me that DOM and GRS-1 fill the same indexes, they just do it in
> different ways. 

With DOM indexing, I think, the issue could be solved, but not with GRS - and it's currently not implemented.

Just trying to explain why I think this change is likely to cause some confusion.

(In reply to Katrin Fischer from comment #8)
> Hm maybe for others reading this we should clarify:
> 
> > 1) If you limit on Branch A and location D, you should get no results in
> > your scenario. 
> 
> That would be how we want it, but it's not going to happen as for the facets
> always everything that appears in the record is taken into account. So all
> item information is mixed together - if you have a branch and a location
> appearing in your record, the facets will show up, even if the information
> belongs to different items.
> 
> > 2) In what scenario would you be able to use both those facets? (Using the
> > Advanced Search, you could, but that's unrelated to the facets.) 
> 
> Yes, advanced search can give confusing results too - but I think it's a lot
> less obvious and users are not so likely to try.
> 
> > If you choose Branch A from the Libraries facet, you would only be presented
> > with location C as a Locations facet. If you choose location D, you would
> > only be presented with Branch B as a Libraries facet.
> 
> Unfortunately that's not the case - see explanation above.
> 
> > I don't think it's an indexing issue though. From what I've seen so far, it
> > seems to me that DOM and GRS-1 fill the same indexes, they just do it in
> > different ways. 
> 
> With DOM indexing, I think, the issue could be solved, but not with GRS -
> and it's currently not implemented.
> 
> Just trying to explain why I think this change is likely to cause some
> confusion.

Mmm, I think I understand what you're saying now.

Basically, 1 bibliographic record can contain multiple items from multiple different branches, multiple different locations, etc. 

As a result, the facets always include information from ALL the items attached to a bib record. 

So even if you "narrow" your search results using one facet, you'll still have facets and facet values showing up for other branches, locations, etc...if a bib record in the results ALSO contains items that have other branches, locations, etc. 

That certainly is a problem.

It seems to be a problem with every item-level facet though. Branches and itemtypes being perhaps the most obvious, although location would certainly fall into that as well. 

--

As for a solution...

I still don't think that DOM indexing would fix this. Admittedly, I am not very experienced with it, but from what I can tell, DOM indexing seems to use XPATH to select particular MARCXML nodes and then puts them into defined indexes (probably defined in bib1.att). The end result is the same as GRS-1, but I think it's much simpler and perhaps more robust than GRS-1. 

I think a solution would need to take into account item-level limits after the MARC search results are returned from Zebra. As far as I know, Zebra thinks only in terms of bibs and whether a bib is tied to a certain index. I imagine that we would have to do a certain amount of post-processing to weed out any inapplicable items...and then suppress that bib record, if there are no items that match our item-level limits.

I imagine that would get fairly messy though, and run into the same problems that we're already encountering with post-processed suppressed bib records :/ (such as the number of results not equalling the number at the top of the page and the number of records appearing per page being unequal).

I'm not sure that there's a way to query Zebra and check that all the 952s have a certain item-level limit. 

Again, I'm no indexing expert, but with indexing...I assume that each index is filled with words or phrases and each of these words or phrases is then linked to an entire record. 

I might be wrong (and am almost certainly missing some of the finer points and technical details), but that's how I understand the Zebra indexing to work whether DOM or GRS-1.

I am not totally sure here, so maybe someone can confirm, but from what I unnderstand you can build more flexible indexes over multiple subfields with DOM. So you could index various item subfields into one index and that could make the limiting more precise - actually looking for your search term in the same index. I think you could also index depending on indictors or checking for existence of other subfields first.

I have a plan to improve facets. Could you please take a look and comment the bug if you have any remarks?
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10891

M. Saby

Pushed to master, along with a follow-up that adds a regression test.

Thanks, David!