RFC on ISBN sanitisations, was: [Koha-patches] [PATCH] Bugfix ShelfBrowser using unsanitized ISBNs. Owen reported the
Joe Atzberger <joe.atzberger@liblime.com> wrote: [...]
+++ b/opac/opac-detail.pl [...] +sub isbn_cleanup ($) { + my $isbn=shift; + if ( + $isbn =~ /\b(\d{13})\b/ or + $isbn =~ /\b(\d{10})\b/ or + $isbn =~ /\b(\d{9}X)\b/i + ) { + return $1; + } + return undef; +} +
Should this be moved into C4 somewhere, expanded to strip non-[0-9X]s and convert UPC barcodes into ISBNs (for barcode wedge users during cataloguing) before checking, and used more widely? Looking for comments, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
Hi, On Wed, May 14, 2008 at 12:32 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Joe Atzberger <joe.atzberger@liblime.com> wrote: [...]
+++ b/opac/opac-detail.pl [...] +sub isbn_cleanup ($) { [snip] Should this be moved into C4 somewhere, expanded to strip non-[0-9X]s and convert UPC barcodes into ISBNs (for barcode wedge users during cataloguing) before checking, and used more widely?
Yes, I think this should be moved to C4. I've been noodling around with the notion of creating a C4::Normalize or the like to centralize these kinds of normalizations (as ISSNs, LC card numbers, OCLC numbers, etc. could benefit from this as well), but haven't done anything yet. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
MJ -- "Should this be moved into C4 somewhere?" My commit message for that piece concluded: Next we should move the sanitize function into C4 for widespread consumption and consistency. Short answer: yes! --Joe On Wed, May 14, 2008 at 2:01 PM, Galen Charlton <galen.charlton@liblime.com> wrote:
Hi,
On Wed, May 14, 2008 at 12:32 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Joe Atzberger <joe.atzberger@liblime.com> wrote: [...]
+++ b/opac/opac-detail.pl [...] +sub isbn_cleanup ($) { [snip] Should this be moved into C4 somewhere, expanded to strip non-[0-9X]s and convert UPC barcodes into ISBNs (for barcode wedge users during cataloguing) before checking, and used more widely?
Yes, I think this should be moved to C4. I've been noodling around with the notion of creating a C4::Normalize or the like to centralize these kinds of normalizations (as ISSNs, LC card numbers, OCLC numbers, etc. could benefit from this as well), but haven't done anything yet.
Regards,
Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
MJ --
"Should this be moved into C4 somewhere?"
My commit message for that piece concluded: Next we should move the sanitize function into C4 for widespread consumption and consistency.
Short answer: yes! I've pushed up Joe's patch to solve the immediate issue raised, but will be happy to see a patch for a C4::Normalize::* if someone has time for
On Thu, May 15, 2008 at 12:20:24PM -0400, Joe Atzberger wrote: that; otherwise, perhaps we can slate that for 3.2. Josh
--Joe
On Wed, May 14, 2008 at 2:01 PM, Galen Charlton <galen.charlton@liblime.com> wrote:
Hi,
On Wed, May 14, 2008 at 12:32 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Joe Atzberger <joe.atzberger@liblime.com> wrote: [...]
+++ b/opac/opac-detail.pl [...] +sub isbn_cleanup ($) { [snip] Should this be moved into C4 somewhere, expanded to strip non-[0-9X]s and convert UPC barcodes into ISBNs (for barcode wedge users during cataloguing) before checking, and used more widely?
Yes, I think this should be moved to C4. I've been noodling around with the notion of creating a C4::Normalize or the like to centralize these kinds of normalizations (as ISSNs, LC card numbers, OCLC numbers, etc. could benefit from this as well), but haven't done anything yet.
Regards,
Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi All, I'm working on a feature to add branch-specific restrictions the editing of Tools->Notices letters The restriction could be set using a syspref (the existing Independant-Branches syspref looks good) , or a user-level-permission (my personal choice 'edit_notices_branch_only' perhaps?) The only current issue is that the 'letter' table really needs a new 'branchcode' column for this to work simply I have an version of this feature working on my dev koha, but the 'branchcode' is currently being stored in the code field , and appended to the code value, separated by a ' : ' - eg:'ACCTDETAILS:MAIN' - which is a workaround for the missing branchcode field , but obviously isnt ideal... What are people's thoughts to added a 'branchcode' column 'letter' table? , I know we have a bit of a DB-structure freeze before the koha-beta3, but i thought i'd ask what everyone thought Is this a nice feature everyone? Paul and HDL what do you think of this, (as both of you did almost all of the existing 'Notices' work?) Any thoughts poeples? Thanks, Mason.
participants (5)
-
Galen Charlton -
jmf＠arwen.metavore.com -
Joe Atzberger -
Mason James -
MJ Ray