Create a new column in biblio table for opac visibiliy status
Hi I have a project about making more easy to hide/unhide records on the OPAC (without having to edit the record in cataloguing mode). http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9778 In the discussion with Fridolyn Somers, the idea of creating first a new column in biblio table for storing the "OPAC visibiliy" status appeared. It is not *stricty *needed but I imagine it could be used by other enhancements later. The issue is that there no field used universally in UNIMARC for storing the visibility information (for ex. in our library we have a non standard field for that, so our Zebra record.abs is specific for this point).:-( So to take advantage of this change, libraries (maybe only Unimarc libraries?) which will upgrade to 3.14 will need - to map their frameworks with the new field in sql database, so that Koha could know which MARC field is used to store the information. - then, to run a script - once for all - for updating this new field in sql database As it will imply manual operations after upgrade, I wanted to get the opinion of the RM fist. So, Galen, have you got some objections or comments? Mathieu Saby Rennes 2 university
Hi, On Fri, Sep 20, 2013 at 9:05 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr>wrote:
I have a project about making more easy to hide/unhide records on the OPAC (without having to edit the record in cataloguing mode). http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9778 In the discussion with Fridolyn Somers, the idea of creating first a new column in biblio table for storing the "OPAC visibiliy" status appeared. It is not *stricty *needed but I imagine it could be used by other enhancements later.
The issue is that there no field used universally in UNIMARC for storing the visibility information (for ex. in our library we have a non standard field for that, so our Zebra record.abs is specific for this point). :-( So to take advantage of this change, libraries (maybe only Unimarc libraries?) which will upgrade to 3.14 will need - to map their frameworks with the new field in sql database, so that Koha could know which MARC field is used to store the information. - then, to run a script - once for all - for updating this new field in sql database
As it will imply manual operations after upgrade, I wanted to get the opinion of the RM fist. So, Galen, have you got some objections or comments?
I think adding a column to the biblio table to express OPAC visibility is a good idea. To my knowledge, MARC21 and NORMARC libraries who use OPAC visibility all use the same subfield, 942$n, so updating the frameworks for those installations could be fully automated. It might be possible to do the same for UNIMARC installations; since an (unmodified) Koha system always uses the "Suppress" CCL keyword to exclude suppressed records, parsing the active Zebra configuration files would indicate which subfield was being used. Other tables could benefit from a visibility column as well -- namely branches and items -- but that of course could be added later Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Le 20/09/2013 18:15, Galen Charlton a écrit :
Hi,
On Fri, Sep 20, 2013 at 9:05 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr <mailto:mathieu.saby@univ-rennes2.fr>> wrote:
I have a project about making more easy to hide/unhide records on the OPAC (without having to edit the record in cataloguing mode). http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9778 In the discussion with Fridolyn Somers, the idea of creating first a new column in biblio table for storing the "OPAC visibiliy" status appeared. It is not *stricty *needed but I imagine it could be used by other enhancements later.
The issue is that there no field used universally in UNIMARC for storing the visibility information (for ex. in our library we have a non standard field for that, so our Zebra record.abs is specific for this point).:-( So to take advantage of this change, libraries (maybe only Unimarc libraries?) which will upgrade to 3.14 will need - to map their frameworks with the new field in sql database, so that Koha could know which MARC field is used to store the information. - then, to run a script - once for all - for updating this new field in sql database
As it will imply manual operations after upgrade, I wanted to get the opinion of the RM fist. So, Galen, have you got some objections or comments?
I think adding a column to the biblio table to express OPAC visibility is a good idea.
To my knowledge, MARC21 and NORMARC libraries who use OPAC visibility all use the same subfield, 942$n, so updating the frameworks for those installations could be fully automated. It might be possible to do the same for UNIMARC installations; since an (unmodified) Koha system always uses the "Suppress" CCL keyword to exclude suppressed records, parsing the active Zebra configuration files would indicate which subfield was being used.
I was wondering if a script launched by updatedatabase.pl will always have rights to access to directory where the /etc/zebra/... will be stored? Excuse me if it is a stupid question... Is it stored in the environment variable $KOHA_CONF_DIR ?
Other tables could benefit from a visibility column as well -- namely branches and items -- but that of course could be added later
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com <mailto:gmc@esilibrary.com> direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
Hi, On Fri, Sep 20, 2013 at 9:30 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr>wrote:
I was wondering if a script launched by updatedatabase.pl will always have rights to access to directory where the /etc/zebra/... will be stored? Excuse me if it is a stupid question... Is it stored in the environment variable $KOHA_CONF_DIR ?
Generally, the only stupid questions are the ones not asked. I think most of the time, updatedatabase.pl would be able to get at the appropriate Zebra configuration files, although I could envision split-server configurations where that might not be the case. On reflection, though, reliably parsing them to figure out the suppression subfield is not a non-trivial task, since in the general case you'd have to consider both GRS-1 and DOM. Consequently, it is probably best if the feature doesn't immediately /require/ that biblio.opacsuppressed (or whatever the column gets called) be populated right off the bat. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Le 20/09/2013 18:44, Galen Charlton a écrit :
Hi,
On Fri, Sep 20, 2013 at 9:30 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr <mailto:mathieu.saby@univ-rennes2.fr>> wrote:
I was wondering if a script launched by updatedatabase.pl <http://updatedatabase.pl> will always have rights to access to directory where the /etc/zebra/... will be stored? Excuse me if it is a stupid question... Is it stored in the environment variable $KOHA_CONF_DIR ?
Generally, the only stupid questions are the ones not asked.
I think most of the time, updatedatabase.pl <http://updatedatabase.pl> would be able to get at the appropriate Zebra configuration files, although I could envision split-server configurations where that might not be the case. On reflection, though, reliably parsing them to figure out the suppression subfield is not a non-trivial task, since in the general case you'd have to consider both GRS-1 and DOM. "Not trivial" was the phrase I was looking for ;-)
Consequently, it is probably best if the feature doesn't immediately /require/ that biblio.opacsuppressed (or whatever the column gets called) be populated right off the bat. Ok for that
Mathieu
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com <mailto:gmc@esilibrary.com> direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
participants (2)
-
Galen Charlton -
Mathieu Saby