1) 942$n While this is marked at the biblio level, this is actually a "Zebra level" type of hiding. When you choose to use OpacSuppression, you're basically saying "Zebra, don't return anything that has a value in this index." Since this is determined by the search query, it's irrelevant when it comes to filtering fields and subfields. 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. 3) MARC Bibliographic Frameworks Yes, I know that bug 11592 refers to method 3. In fact, 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. After re-reading the title of your bug, I can see how you can say that it doesn't relate to search results. However, conceptually, it does relate to search results. Conceptually, the visibility in the bibliographic frameworks should always apply to records whether they're retrieved from Zebra or MySQL. 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? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

-----Original Message----- From: Mark Tompsett [mailto:mtompset@hotmail.com] Sent: Friday, 21 November 2014 4:09 PM To: David Cook Cc: koha-devel@lists.koha-community.org Subject: Re: Hiding...

Greetings,

There are different “hiding” actions. Let’s see if I remember them all. 1) 942$n This is at the biblio-level. 2) System preference: OpacHiddenItems This can be used to hide on any field at an item-level. 3) Home › Administration › MARC frameworks › {name} framework structure › Tag {tag number} subfield structure › Edit subfields constraints This is used to affect visibility: OPAC, Intranet, Editor, Collapsed, Flagged?

Bug 11592 refers to method 3.

David Cook wrote:

...

I’m really interested in this one, but Tomas raised a good point the other day suggesting that we should filter the MARC as it comes out of the source (i.e. Zebra or MySQL) using XSLT (dynamically generated based on framework hidden values).

I’m not sure this is applicable in this hiding case. It would likely be valid in case (1) and perhaps case (2).

David Cook asked:

...

Does your patch filter search results for the OPAC? I don’t see a mod there which would do that…

This is not related to search results. It is about opac details in normal, marc, and isbd views.

Hopefully this clarifies. And if I’m wrong, someone can explain why (e.g. XSLT does apply, because ...).

GPML, Mark Tompsett

...

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.