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: 2023-09-15 14:55 UTC (History)
15 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
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.
Comment 11 Noémie Labine 2022-01-10 16:22:41 UTC
Still valid !
Comment 12 Fridolin Somers 2022-01-18 06:50:33 UTC
Using OpacSuppression is the only way to hide records without those searchengine side-effects.
Comment 13 David Cook 2022-01-19 01:09:57 UTC
(In reply to Tomás Cohen Arazi from comment #6)
> 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).

This is something I've been thinking about when exporting data from Koha into other systems. OpacSuppression, OpacHiddenItems, OpacHiddenItemsExceptions... these all change behaviour without changing the actual data. 

With OpacSuppression it doesn't matter too much because it's just on/off, but the other 2 require potentially heavy calculations for updating an index...
Comment 14 Joseph Alway 2023-09-15 14:52:53 UTC
Our workaround was to add CSS to remove the facet label (Where CustomType is the Item Type we're hiding.):
/*Hide the CustomType facet in search results*/
.facet-label a[title="CustomType"] {display: none !important; }
Comment 15 Joseph Alway 2023-09-15 14:55:40 UTC
(In reply to Joseph Alway from comment #14)
> Our workaround was to add CSS to remove the facet label (Where CustomType is
> the Item Type we're hiding.):
> /*Hide the CustomType facet in search results*/
> .facet-label a[title="CustomType"] {display: none !important; }

To clarify this was added to the OPACUserCSS system preference.