Bug 31755

Summary: Store biblio OPAC visibility in biblio table
Product: Koha Reporter: David Cook <dcook>
Component: OPACAssignee: Owen Leonard <oleonard>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low    
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description David Cook 2022-10-12 23:14:55 UTC
At the moment, you have to interrogate the MARCXML to determine if a record is suppressed using OpacSuppression, and you have to iterate through all of a bib's items to see if it's hidden/suppressed using OpacHiddenItems and OpacHiddenItemsHidesRecord.

As Tomas said at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31161#c21, it would make sense to have a "suppressed" field in the biblio table so that we can determine a biblio record's OPAC visibility using a simple SQL query.
Comment 1 David Cook 2022-10-12 23:19:58 UTC
In theory, every bib record change would trigger an evaluation of whether or not the bib is "suppressed", and every item change should trigger an evaluation of whether or not that item is "hidden". There would also need to be an evaluation of whether or not the bib is suppressed if all its items are hidden.
Comment 2 Katrin Fischer 2022-10-14 21:07:41 UTC
We'd also need a maintenance script then, because if items make a record hidden can be changed on the fly. It would make things a bit less flexible for libraries again... having to ask someone to run jobs server side if often not an easy thing for them.

Maybe this makes more sense for OpacSuppression only as a first step?
Comment 3 David Cook 2022-10-16 22:55:15 UTC
(In reply to Katrin Fischer from comment #2)
> We'd also need a maintenance script then, because if items make a record
> hidden can be changed on the fly. It would make things a bit less flexible
> for libraries again... having to ask someone to run jobs server side if
> often not an easy thing for them.

Flexibility is what got us into this mess in the first place...

> Maybe this makes more sense for OpacSuppression only as a first step?

Sure.