http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #2 from Paul A <paul.a@aandc.org> --- Created attachment 16896 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=16896&action=edit .tar for serialized 001 field See bug 9921 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui <nunyo@masmedios.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #18700|0 |1 is obsolete| | --- Comment #4 from Nuño López Ansótegui <nunyo@masmedios.com> --- Created attachment 18701 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18701&action=edit Bug 9921 - Make it possible to force 001 = biblionumber Update Copyright -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui <nunyo@masmedios.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #18701|0 |1 is obsolete| | --- Comment #6 from Nuño López Ansótegui <nunyo@masmedios.com> --- Created attachment 18707 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18707&action=edit Bug 9921 - Make it possible to force 001 = biblionumber Update marc_subfield_structure for add marc21_field_001.pl -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #8 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- You attached the wrong patch perhaps?? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #10 from Nuño López Ansótegui <nunyo@masmedios.com> --- (In reply to comment #9)

(In reply to comment #8)

...

You attached the wrong patch perhaps??

No wait..

Does it apply? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui <nunyo@masmedios.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #18707|0 |1 is obsolete| | --- Comment #12 from Nuño López Ansótegui <nunyo@masmedios.com> --- Created attachment 18862 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18862&action=edit Bug 9921 - Make it possible to force 001 = biblionumber The previous patch no longer applies. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #14 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Nuño: Thanks for your patch adjustments and the effort to synchronize all language files in this regard. But I still have some thoughts about this: 1) I think we cannot force the plugin at upgrade time (in the updatedatabase change). If someone already has another plugin there, you cannot overwrite that. I would consider this a blocker for this patch. You could consider the update if there is no plugin attached. You could print a upgrade warning statement if there is another plugin. 2) My personal opinion is that we should stop making changes in all the language folders. Let an active language maintainer do that. This is currently not the policy however; note that I sent a message to the dev list just now about this topic. More ideally, you would insert the plugin only in the general (English) file and just update the translations in the language (the plugin filename does not need translation at all). What we should do in the meantime, is however a little bit gray area now. So, this does not block your patch. 3) I feel that incrementalControlNumber is not (really) a pref. I can imagine more cases where we might need a sequential number. Would it be interesting to move it perhaps to Tools in a more general context such as a sequence number engine with its own table (id, keyname, seqnumber, date)? There are more fields like callnumber (with plugins) that could use such an approach.. This does again not block your patch, but we could trigger the discussion on a more general solution. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gmcharlt@gmail.com --- Comment #15 from Galen Charlton <gmcharlt@gmail.com> --- (In reply to comment #14)

3) I feel that incrementalControlNumber is not (really) a pref. I can imagine more cases where we might need a sequential number. Would it be interesting to move it perhaps to Tools in a more general context such as a sequence number engine with its own table (id, keyname, seqnumber, date)? There are more fields like callnumber (with plugins) that could use such an approach.. This does again not block your patch, but we could trigger the discussion on a more general solution.

This idea (creating a sequence engine) is worth elevating to a new enhancement bug. There's been some chatter on #koha the past few days about this in the context of improving how sequential patron cardnumbers are assigned. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #17 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #16)

New code *must* enable the warnings pragma; please use Modern::Perl.

This could still be a problem with the way the plugins work in the marc editor. The routine is redefined iirc.. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui <nunyo@masmedios.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #18862|0 |1 is obsolete| | --- Comment #19 from Nuño López Ansótegui <nunyo@masmedios.com> --- Created attachment 19062 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19062&action=edit Bug 9921 - Make it possible to force 001 = biblionumber Added 'use Modern::Perl;' in cataloguing/value_builder/marc21_field_001.pl Update if there is no plugin attached. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #20 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #15)

This idea (creating a sequence engine) is worth elevating to a new enhancement bug. There's been some chatter on #koha the past few days about this in the context of improving how sequential patron cardnumbers are assigned.

See bug 10478 please. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #22 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #18)

(In reply to comment #17)

...

(In reply to comment #16)

...

New code *must* enable the warnings pragma; please use Modern::Perl.

This could still be a problem with the way the plugins work in the marc editor. The routine is redefined iirc..

All the more reason to stick to our coding guidelines, if the additional warning messages in the log annoys somebody enough to inspire them to fix that issue with the cataloging plugins, then. :)

I actually disagree here. We cannot block development, because we already have a bad construct in Koha and a new developer should solve that first. We need to be somewhat pragmatic. As long as the construct is in, we are more or less obliged to support it. We would not encourage people to submit patches, if they should start solving our old problems. But I looked a little bit, sufficiently annoyed :) and submitted a proposal for this under bug 10480. Have a look! BTW It will not be possible to phase out all old plugins directly, because we have to keep in mind that people may have also written custom plugins this way. Bug 10480 supports both ways therefore. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #24 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #23)

Ok, I wait, thanks.

You do no longer need to wait. Click bug 10480 :) -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui <nunyo@masmedios.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #19062|0 |1 is obsolete| | --- Comment #26 from Nuño López Ansótegui <nunyo@masmedios.com> --- Created attachment 19099 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19099&action=edit Bug 9921 - Make it possible to force 001 = biblionumber 'cataloguing/value_builder/marc21_field_001.pl' has been moved to the new style using $building_plugins -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #28 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #26)

Created attachment 19099 [details] [review] Bug 9921 - Make it possible to force 001 = biblionumber

'cataloguing/value_builder/marc21_field_001.pl' has been moved to the new style using $building_plugins

Cool. Nuno, would you object if I convert your patch in two patches? I would like to see the essential stuff in one patch, and all changes to language folders to a followup. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #30 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #29)

(In reply to comment #28)

...

(In reply to comment #26)

...

Created attachment 19099 [details] [review] [review] [review] Bug 9921 - Make it possible to force 001 = biblionumber

'cataloguing/value_builder/marc21_field_001.pl' has been moved to the new style using $building_plugins

Cool. Nuno, would you object if I convert your patch in two patches? I would like to see the essential stuff in one patch, and all changes to language folders to a followup.

Ok, I agree with that. In this way, functionality is independent of adaptation into other languages.

Thanks. I will be testing now and making little change. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #31 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 19153 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19153&action=edit Bug 9921: Followup for installer languages -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #33 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Still some comments, but we are coming further :) Thanks for your patience.. When editing an existing record, I would prefer not to change the biblionumber in the 001 by a string again when receiving focus. Currently, you overwrite and save the string in the record. Since you only changed AddBiblio and not ModBiblio, this is permanent. Same for incremental. Please combine your code for AddBiblio and ModBiblio. Also when I would incidentally change biblionumber by deleting a char or so, I would loose my biblionumber or incremental. Consider adding the focus action to Blur? Consider blocking edit in this input field via your javascript? I am not yet fully sure if your incremental update will hold under concurrent use. If between your fetch with preference and the next execute, someone else does an earlier execute, you could have double numbers? Need some way of locking or transaction? Updatedatabase Need a print statement if someone already has a plugin for 001? Maybe they can consider your new plugin? I am wondering if it is dangerous to set the plugin for one framework and not for another (could be the case)? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui <nunyo@masmedios.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #19156|0 |1 is obsolete| | --- Comment #35 from Nuño López Ansótegui <nunyo@masmedios.com> --- Created attachment 19170 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19170&action=edit Bug 9921 - Make it possible to force 001 = biblionumber Code is add in ModBiblio. Adding the focus action to Blur and Clic. Update incremental number and then read. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #37 from Nuño López Ansótegui <nunyo@masmedios.com> --- It's no problem to use other plugin or not using of this plugin, the field is not autofilled or will be filled with a number . If the field 001 is blank will be updated with incremental biblionumber or number. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #39 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #36)

...

I am wondering if it is dangerous to set the plugin for one framework and not for another (could be the case)?

Since your pref is OFF by default, this is initially harmless. Suppose however that people have some frameworks, and some frameworks have a 001 plugin and other frameworks have not. (Not recommended of course..) They upgrade and now some frameworks have your plugin and others have the old (custom) one. They are perhaps not aware of this incosistency. At some time they activate your pref and they see your plugin in some framework, making the wrong conclusion that all frameworks already have it. From that time on, we do have a problem. Now is the question: Should we actually update a Koha db that has this inconsistency with potential for future problems, or should we only update if all frameworks do NOT have a 001 plugin? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #40 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think we should only update the database when there are no existing plugins for any of the 001. But when we do update, it should loop over all frameworks to ensure it's a consistent change. Marcel - not sure, but is the LAST_INSERT_ID a MySQLism? I seem to remember a discussion in IRC about it, but of course... I can't remember enough to explain why I have it memorized as not a good idea. :( -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #42 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #41)

If they have their own 001 plugin, i think that they should be able to control their frameworks and differ if they have the default plugin 001 in Koha or not.

What do you think?

My point only applies to several frameworks with inconsistent use of 001 plugin. Just to be safe, we could restrict ourselves to updating only when all 001 plugins are empty and print a upgrade warning otherwise. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #44 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Found this quote somewhere in context of using mod_perl: As long as you get it from the same $sth, it's going to be thread safe (i.e. doesn't matter if another process inserts before you call insert_id, you still get the one you inserted). -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #46 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to comment #45)

In the original context though, this bug plus recent discussion on #koha about table-locking issues with fixup_cardnumber is making me think that what we *really* need is a small module for simulating true sequences so that one can simply do something like

my $num = Koha::Database::Sequence->get_next_val($sequence_name);

The idea is that the module and the code backing it would provide the ability to create a sequence with a specified name, then fetch values from it that are guaranteed to be unique.

See bug 10478. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtompset@hotmail.com --- Comment #48 from M. Tompsett <mtompset@hotmail.com> --- Koha::Sequence will be added as part of bug 10454. This may be useful in this context for incrementing something automatically. Here's a preliminary sample test suite for it, and the output. --- BEGIN --- #!/usr/bin/perl use strict; use warnings; use Test::More tests => 15; BEGIN { use_ok('Koha::Sequence' , 'check to use Koha::Sequence'); } my $seq = Koha::Sequence->new('blah'); ok ( defined($seq) , 'created sequence called blah'); my $rv = $seq->reset_everything; ok ( $rv , 'triggered reset of everything' ); $seq = Koha::Sequence->new('id1'); ok ( defined($seq) , 'created sequence called id1'); $rv = $seq->del_sequence; ok ( $rv , 'deleted sequence called id1'); my $seq1 = Koha::Sequence->new('cardnumber_katipo'); my $seq2 = Koha::Sequence->new('cardnumber_none'); ok ( $seq1->is_sequence, 'Confirmed cardnumber_katipo sequence' ); ok ( $seq2->is_sequence, 'Confirmed cardnumber_none sequence' ); my $value; ok ( $value = $seq1->get_next_value, "Value $value" ); ok ( $value = $seq1->get_next_value, "Value $value" ); ok ( $value = $seq2->get_next_value, "Value $value" ); ok ( $value = $seq2->get_next_value, "Value $value" ); $seq = Koha::Sequence->new('blah'); ok ( defined($seq) , 'created sequence called blah'); $rv = $seq->reset_everything; ok ( $rv , 'triggered reset of everything' ); ok ( $value = $seq1->get_next_value, "Value $value" ); ok ( $value = $seq2->get_next_value, "Value $value" ); --- END --- t$ prove -v Sequence.t Sequence.t .. 1..15 ok 1 - use Koha::Sequence; ok 2 - created sequence called blah ok 3 - triggered reset of everything ok 4 - created sequence called id1 ok 5 - deleted sequence called id1 ok 6 - Confirmed cardnumber_katipo sequence ok 7 - Confirmed cardnumber_none sequence ok 8 - Value 1000000 ok 9 - Value 1000001 ok 10 - Value 162 ok 11 - Value 163 ok 12 - created sequence called blah ok 13 - triggered reset of everything ok 14 - Value 1000000 ok 15 - Value 162 ok All tests successful. Files=1, Tests=15, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.10 cusr 0.00 csys = 0.12 CPU) Result: PASS the reset_everything rebuilds the cardnumber_katipo and cardnumber_none sequences. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 I'm just a bot <gitbot@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gitbot@bugs.koha-community. | |org When did the bot| |2013-09-29 last check this| | --- Comment #49 from I'm just a bot <gitbot@bugs.koha-community.org> --- Patch applied cleanly, go forth and signoff -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Bug 9921 depends on bug 10480, which changed state. Bug 10480 Summary: Cataloging plugins without redefining http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10480 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #52 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Zeno Tajoli from comment #51)

In fact the patch is blocked by discussion on Koha::Sequence (bug 10454). Is it Ok if i rewrite the patch without the incremental option ? I will insert two options.

I would favor a solution using the sequence number engine. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 marjorie barry-vila <marjorie.barry-vila@ccsr.qc.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila@ccsr.qc | |.ca -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Bug 9921 depends on bug 10480, which changed state. Bug 10480 Summary: Cataloging plugins without redefining http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10480 What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- -- You are receiving this mail because: You are watching all bug changes.