It would be helpful to indicate in the staff client that a record you are viewing is using the OpacHiddenItems system preference for the OPAC. It could display 'Hidden in OPAC' similar to the way is displays 'Suppressed in OPAC' for suppressed bibs.
+1 -- we indicate that a bib is suppressed. Why not also a note on hidden items? I'm asked fairly frequently why something or other hidden by OPACHidden isn't visible.
+1
*** Bug 28827 has been marked as a duplicate of this bug. ***
A new column in items table ?
(In reply to Fridolin Somers from comment #7) > A new column in items table ? I think that points back to a conversation we've had elsewhere about how challenging OpacHiddenItems is, since it's based off a multi-factor calculation and not just a database flag. If you changed OpacHiddenItems, you'd have to iterate through every item row in the database to check if the column in the items table is hidden. And even then there's other system preferences to check to see whether or not the actual bib record is hidden. -- I think this would be a useful feature, but it would be very difficult to do without overhauling OpacHiddenItems, which is going to be a high effort activity I think.
(In reply to David Cook from comment #8) > I think this would be a useful feature, but it would be very difficult to do > without overhauling OpacHiddenItems, which is going to be a high effort > activity I think. I mean if we did it in terms of a database field. I think for now we could just perform the calculation on the load of the detail page. That should be all right. (Although it would be slow for a bib record with a high number of items, so it would probably be best to do asynchronously...)
(In reply to Fridolin Somers from comment #7) > A new column in items table ? I meant a column in the HTML table of items, in details page.
(In reply to Fridolin Somers from comment #10) > (In reply to Fridolin Somers from comment #7) > > A new column in items table ? > > I meant a column in the HTML table of items, in details page. I like the idea. Do we expect a performance hit by it? Or could it be an indicator somehow, maybe in one of the existing columns, like a small icon with a tool tip?
(In reply to Katrin Fischer from comment #11) > (In reply to Fridolin Somers from comment #10) > > (In reply to Fridolin Somers from comment #7) > > > A new column in items table ? > > > > I meant a column in the HTML table of items, in details page. > > I like the idea. Do we expect a performance hit by it? > Or could it be an indicator somehow, maybe in one of the existing columns, > like a small icon with a tool tip? Sorry, Frido. Now I feel embarrassed [U+1F605]. I think that we could expect a performance hit, but the work should be CPU bound rather than I/O bound, so hopefully it won't be too much. The more rules and the more holdings you have, the worse it will be. If we want to show if the bib is hidden by OpacHiddenItems, then I think it gets more complicated, because Koha::Biblio->hidden_in_opac performs the calculation once, and then when building the item array for display, we'd need to perform the calculation again. This would be suboptimal. Perhaps Koha::Biblio->hidden_in_opac should take an optional argument of "items", and Koha::Item->hidden_in_opac should store its calculation in itself. Alternatively, Koha::Biblio->hidden_in_opac could return a hashref of itemnumbers denoting hidden status, and then on detail.pl when processing items this hashref could be checked to determine hidden status. Or we could just worry about optimizing this later if it's an issue. For a small number of holdings and a small number of rules, it probably wouldn't be noticeable. It would probably just have an impact on a higher number of holdings. But then that's where bug 33568 saves the day...