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
_______________________________________________
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/
