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:[email protected]] > Sent: Friday, 21 November 2014 4:09 PM > To: David Cook > Cc: [email protected] > 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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
