This needs a follow up patch to set the values in the syspref.sql file (and other language ones)
Created attachment 3491 [details] [review] Proposed Patch
Created attachment 3492 [details] [review] Followup patch
Created attachment 3493 [details] [review] Another follow up
I'm not seeing the *.pref file edited in any of these patches which means no one can set the preference.
What is the purpose of this feature? Is it to hide all items except those belonging to the patron's branch? I've tried reading the patch files but I'm not clear on it.
The purpose of this feature is to give the ability to define custom rules to hide items. The rules are based on the items table fields. The user can define values that makes the item hidden. If at least one of the defined rules match, the item is hidden. Some examples can ben found here : docs/opac/OpacHiddenItems.txt
I just updated my current head server, but I do not see a docs/opac/OpacHiddenItems.txt file. The only thing under docs is history.txt. Can you attach this file to the bugzilla entry?
Two problems, already mentioned: 1. OpacHiddenItems is not added to any .pref file 2. OpacHiddenItems.txt is not in any of the patches (but there is a file here: http://git.biblibre.com/?p=koha;a=blob;f=docs/opac/OpacHiddenItems.txt) Marking as "Failed QA".
The OpacHiddenItems.txt is in the "Proposed patch" attachment. The .pref file is still required though.
Created attachment 3644 [details] [review] Adds the syspref in opac.pref
Created attachment 3691 [details] [review] Proposed Patch
Created attachment 3692 [details] [review] Followup patch
Created attachment 3693 [details] [review] Another follow up
Created attachment 3694 [details] [review] Adds the syspref in opac.pref
The attached patches did not apply. I fixed them so they apply and updated the attachments.
Created attachment 3700 [details] [review] Proposed Patch Previous version contained merge leftovers
Created attachment 3701 [details] [review] Followup patch Previous version contained merge leftovers
Created attachment 3702 [details] [review] Another follow up Previous version contained merge leftovers
Created attachment 3703 [details] [review] 1st patch signed off
Created attachment 3704 [details] [review] 2nd patch signed off
Created attachment 3705 [details] [review] 3rd patch signed off
Created attachment 3706 [details] [review] 4th patch signed off
Tests done: - Display items of a biblio - filter items with OpacHiddenItems = itemcallnumber: [123] - Item with callnumber 123 disappear
Pushed, please test
We have found that while OpacHiddenItems seems to works in the opac-detail.pl in 3.4.1, the "hidden items" do appear once "specific copy" is selected on opac-reserve.pl
Thanks for testing Linda, I suggest we leave this bug open until someone has a chance to do a follow up for the reserve page.
I'm not sure I agree with the approach this feature takes; specifying a large and complex set of criteria for bulk hiding of items makes for a very difficult feature to debug (as we've seen lately with this feature being broken). Wouldn't it make more sense to just add a "hidden" or "visibility" field to the items table? Then any item could be masked in the OPAC (or staff client). If we took in more than just 0 or 1, then we could have levels of invisibility (this would be good for biblio-level suppression, as well). For example, anonymous views can see hidden = 0, logged in users gain hidden = 1, staff can see hidden = 2, etc. We've got a bulk item editor, so making these changes in bulk would be pretty simple; we'd just need to identify the criteria. A small ergonomic change to the Reports interface to allow the direct pushing of a report to the bulk editor would make these convenient and seamless.
Ian, seems this patch has been pushed. Are you proposing to revert it ?
This feature has been working for us all along, and we'd hate to lose it. I have no idea why it works for us and no one else but it does, and it's still working in our test 3.6. Ours is like this: itype: [07, 10] location: [STAFF, ISO]
There have been no further reports of problems so I am marking this bug resolved.