Bug 14007 - Item Types for items hidden by OpacHiddenItems turn up in facet results
Summary: Item Types for items hidden by OpacHiddenItems turn up in facet results
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low normal with 1 vote (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 24403
  Show dependency treegraph
 
Reported: 2015-04-17 02:54 UTC by Liz Rea
Modified: 2021-01-27 14:23 UTC (History)
11 users (show)

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


Attachments
Wrong count for facets (189.94 KB, image/png)
2018-09-21 14:09 UTC, Séverine Queune
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Liz Rea 2015-04-17 02:54:12 UTC
An example of this bug:

Library has hidden item type "password" from the OPAC.

Library does a search for a publication for which they have a password. On the OPAC - the record is hidden, but the item type facet contains the item type of "Password" even though the item itself is hidden. Clicking the facet brings back no results. 

We've already hidden them on the Advanced search in bug 12330, it would be good to tidy this up as well.
Comment 1 Chris Slone 2017-08-21 13:51:16 UTC
I know this bug is a little old now, but it is still pertinent. If you have an item type that cannot be viewed on the OPAC it still shows up in the facets. For example, we have an Interlibrary Loan item type that is not visible on the OPAC, but it appears in the facets when it meets the criteria of the search. Clicking on this item type will bring you to an error message. It's confusing to the patron and/or gives the impression that there are problems with the OPAC.
Comment 2 Séverine Queune 2018-09-21 14:09:55 UTC
Created attachment 79233 [details]
Wrong count for facets

Facet should only take in count items that are not hidden.
Comment 3 Séverine Queune 2018-09-21 14:10:18 UTC
Still valid !
Comment 4 David Cook 2018-11-28 04:59:34 UTC
Because the "OpacHiddenItems" is handled after results are returned from the search engine, it's really hard to do handle the logic well.
Comment 5 Marjorie Barry-Vila 2019-12-02 18:44:45 UTC
+1
Comment 6 Tomás Cohen Arazi 2020-12-15 12:43:07 UTC
We should have separate indexes for OPAC and staff interface.
Probably public_* for the OPAC. We could need some trick for when OpacHiddenItemsExceptions is matched (i.e. it should display the full thing).
Comment 7 Katrin Fischer 2020-12-15 18:55:24 UTC
Would this be just like 2 different itemtype indexes? or "full" index?
I think the first might be a good solution, but the opachiddenitems is currently a dymanic setting that works 'on the fly'. I think making new indexes will always require a full reindex so will limit the usefulness of the functionality a bit.

Is there an alternative solution where we could filter those from search dynamically?
Comment 8 Tomás Cohen Arazi 2020-12-15 18:57:19 UTC
(In reply to Katrin Fischer from comment #7)
> Would this be just like 2 different itemtype indexes? or "full" index?
> I think the first might be a good solution, but the opachiddenitems is
> currently a dymanic setting that works 'on the fly'. I think making new
> indexes will always require a full reindex so will limit the usefulness of
> the functionality a bit.
> 
> Is there an alternative solution where we could filter those from search
> dynamically?

I guess we could build smarter searches based on the context information (OpacHiddenItems, patron category, etc). It would be a not-so-simple development, but of course doable.
Comment 9 Katrin Fischer 2020-12-15 18:58:39 UTC
I wonder if the options of "exceptions" are not already a "killer" for the index idea - making things more complicated :(
Comment 10 Tomás Cohen Arazi 2020-12-15 19:00:16 UTC
(In reply to Katrin Fischer from comment #9)
> I wonder if the options of "exceptions" are not already a "killer" for the
> index idea - making things more complicated :(

Nah, you would use one query/index or the other depending on that context, which is a mix of settings and the logged-in user category and interface.