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.
Yes. I know that it doesn't hide the biblio when there is one item hidden and the other not. It's unrelated to 942$n, since this filtering happens after retrieval. It's a useful feature. It's just not super optimal in how it works.
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.
Fortunately, one of us who understands XSLT could built the feature to filter the XML (or others could take it as motivation to learn XSL :P). It's not so much ensuring that the record is always passed around internally as XML. It's more a matter of making sure that the initial retrieval is as XML and that it's filtered. After it's filtered, it can be passed around as XML, a MARC::Record object, even ISO Marc. It doesn't really matter. But yes, it would require effort (and probably a convention) to make sure that the MARCXML is always being retrieved via the filtering function rather than directly from the database through other functions. Overall, I'm not a huge fan of "good enough" :). I think Koha struggles a lot from technical debt which could be avoided. While I really want this functionality, I want it done as effectively, as efficiently, and as comprehensively as possible.
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.
There are currently inconsistencies in how records are retrieved, yes. That remains a problem with bug 11592 as well since it only applies to a few scripts. I'm saying that we consistently retrieve the record using a function, which filters the XML as needed, and then pass it on to whatever it needs to do. That's not really quick and dirty at all. In fact, it wouldn't overlap #2 either, since that would be a different filter to apply to a record. It would however negate bug 11592 as it would be a more comprehensive implementation of method #3. That being said, it would take more work, as it would need to be started from scratch.
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. :)
That's a rather particular scenario. Typically, if you're hiding fields in a framework, it's because you're hiding certain bibliographic data. You don't want to hide the whole record; you just want to hide certain data. If you wanted to hide the whole record, you'd just suppress it. You might just want to hide the note fields for all records from Framework N - not hide the records or the items. They're completely different requirements.
So unless you want to refactor the whole hiding, which I'm open to discussing, I just need a sign off for 11592. :)
I'm not talking about hiding bibliographic records. Nor am I talking about hiding item records. I'm talking about hiding fields/subfields in bibliographic records. Although perhaps that's what you mean there. Yep, I do suggest refactoring the whole thing. When Tomas suggested it to me the first time, it seemed mad, but the more I thought about it, the more I liked the idea. Of course, I don't have the time to do that at the moment, which puts a wrench in the works. But that doesn't mean I'm going to sign off on a patch that I intend to rip out down the road anyway. That said, if someone else wants to sign off on it, they're free to do so. I just don't think it's the best idea. It only affects a limited number of scripts in the OPAC. If we're going to ensure that the visibility options in the frameworks work, I'd like them to work clear across the board in the OPAC and the Intranet. Anyway, that's just my 2 cents.