Greetings,
1) 942$n Since this is determined by the search query, it's irrelevant when it comes to filtering fields and subfields.
True, but I figured I'd mention it to be complete. :)
2) OpacHiddenItems This is a tough one, since we hide the entire biblio if all the items within it are hidden. Would have to think more about this one... I both like and dislike this system preference.
-- Imagine a Biblio with two items, one which is completely hidden, and the other not. It's ugly, but this gives 942$n a little more granularity.
3) MARC Bibliographic Frameworks ... that's why I brought up Tomas's idea of using XSLTs for filtering instead. There would be a XSLT for each framework which could be changed dynamically each time the framework is changed, which should not be very often anyway. When retrieving records from the database or Zebra, the record would be filtered through the XSLT.
But sometimes the record is a MARC::Record, and sometimes it is XML. I don't know how to filter XML using XSLT, but I do know how to filter a MARC::Record. :) So, unless we are going to ensure the record is always passed around internally as XML, Bug 11592 in its current state seems good enough to me.
Conceptually, the visibility in the bibliographic frameworks should always apply to records whether they're retrieved from Zebra or MySQL.
Yes, I agree. However, the internal storage structure (sometimes MARC::Record, sometimes XML) and the way things are retrieved (Zebra/MySQL) makes filtering consistently difficult. This is just an overlap of method 2 and 3 as a quick and dirty solution, since #2 was already in Koha and bug 11592 is a clean up of #3.
For instance, say field X is hidden in the framework. With your scripts, it would be hidden in the detail views, but it wouldn't be hidden in the search results. Doesn't that completely defeat the point of hiding it on the detail page if they can see it in the search results, which is likely their first point of contact with the record anyway?
Yes, unless OpacHiddenItems ends up filtering out the things to show in search details. You can use both #2 and #3 to accomplish a clean hide. Yes, it's ugly, but it is functional. :) So unless you want to refactor the whole hiding, which I'm open to discussing, I just need a sign off for 11592. :) As for refactoring, if I recall 'papa' was suggesting something similar to the circulation rules screen for hiding. ;) GPML, Mark Tompsett