[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui changed: What|Removed |Added Attachment #19170|0 |1 is obsolete|| --- Comment #47 from Nuño López Ansótegui --- Created attachment 19176 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19176&action=edit Bug 9921 - Make it possible to force 001 = biblionumber 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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7736] Edifact QUOTE and ORDER functionality
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7736 Kyle M Hall changed: What|Removed |Added Status|Failed QA |Needs Signoff CC||k...@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10478] Do we need a sequential number generator?
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10478 --- Comment #2 from M. de Rooy --- (In reply to comment #1) > Created attachment 19175 [details] [review] > Bug 10478: Sequential number generator Just as an example of what I had in mind.. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10478] Do we need a sequential number generator?
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10478 --- Comment #1 from M. de Rooy --- Created attachment 19175 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19175&action=edit Bug 10478: Sequential number generator -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #46 from M. de Rooy --- (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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10500] Improve isbn matching when importing records
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10500 Kyle M Hall changed: What|Removed |Added Attachment #19172|0 |1 is obsolete|| --- Comment #2 from Kyle M Hall --- Created attachment 19174 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19174&action=edit Bug 10500 - Improve isbn matching when importing records Test Plan: 1) Catalog a record with the ISBN "0394502884 (Random House)" 2) Export the record, edit it so the ISBN is now "0394502884 (UnRandomHouse)" 3) Using the record import tool, import this record with matching on ISBN. 4) You should not find a match 5) Apply this patch 6) Run updatedatabase.pl 7) Enable the new system preference AggressiveMatchOnISBN 8) Repeat step 3 9) The tool should now find a match -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10500] Improve isbn matching when importing records
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10500 Kyle M Hall changed: What|Removed |Added Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10336] UT: HoldsQueue.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10336 --- Comment #11 from Galen Charlton --- Please see my comment in bug 10495. If you attach a non-WIP version of your patch, I'm ready to test it and sign off on it. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10336] UT: HoldsQueue.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10336 Galen Charlton changed: What|Removed |Added Blocks||10495 -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10495] t/db_dependent/HoldsQueue.t can fail unnecessarily
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10495 Galen Charlton changed: What|Removed |Added Depends on||10336 --- Comment #4 from Galen Charlton --- (In reply to comment #2) > Galen, > I got a bad news, with my DB tests, I have a bad news, with your patch I get: Yes, this relates to the comment I made in bug 10336 -- HoldsQueue.t currently assumes that there is at least one item out on loan; your patch removes that assumption. Consequently, to whoever QAs this: this patch should be tested in conjunction with the patch for 10336. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #45 from Galen Charlton --- (In reply to comment #43) > But note that last_insert_id may be more portable, it is considered less > reliable than e.g. using MySQL with mysql_insertid. > Since AddBiblio relies on it, I would have no objection to using one of the > two constructs. Actually, it looks like DBD::mysql bases its implementation of its last_insert_id() method on MySQL's mysql_insert_id function, so as far as DBI is concerned, I think $dbh->last_insert_id() does the Right Thing. 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. I'll poke at this. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7684] inventory : datatable fix actions etc.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7684 Sonia Lemaire changed: What|Removed |Added CC||sonia.lema...@biblibre.com --- Comment #51 from Sonia Lemaire --- I tested the patch using the two ways of making an inventory. The first way, by comparing a barcode file with a list of results : - I upload a barcode file - I select the library and the shelving location of the items I want to check - I choose the statuses of the items - I check the box “skip copies on loan” - I check the box “export to CSV file” - I check the box “compare barcodes list to results” Ok for items on loan : they have been checked in. Ok for misplaced items : marked as “should not have been scanned” on the screen and “wrong place” in the CSV file. Ok for wrong status : a notforloan item which should not be on the shelf is marked as “change item status” in both the online report and the CSV file. Ok for unknown barcode (scan error or item not found in koha) : marked as “barcode not found” ok for setting datelastseen to the inventory date Ok for CSV export Not ok : missing item : if a barcode has not been scanned when it should have been, it is ignored by the tool and no problem is reported. The second way, by creating a list of items to be checked “manually” - I select the library and the shelving location of the items I want to check - I choose the statuses of the items - I check the box “export to CSV file” As Mathieu Saby notes, it doesn't work. No list is created, neither on the online report, nor in the CSV file. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 8798] Add the use of DBIx::Class
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8798 --- Comment #66 from Paul Poulain --- (In reply to comment #60) > Chris and I discussed this bug today and he's agreed to update the patch > series for master; I intend to push DBIC support unless some showstopper > comes up during QA and testing. Jonathan & I had a short discussion about this patch & DBIC: we have the same question: what's the next step once this patch is pushed ? We need to have clear directions, in order to coordinate the effort & do as much progress as possible in DBIC. PS: from a QA point of view, am I right if I say that those patches need to be merged in one patch, otherwise they're quite hard to understand ? the schema is made, then updated. we put something in C4/Context.pm, then remove it to create Koha/Database.pm -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10010] Use jQueryUI Accordion to display constraints in MARC subfield editor
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10010 Galen Charlton changed: What|Removed |Added Status|Passed QA |Pushed to Master --- Comment #11 from Galen Charlton --- Pushed to master. Thanks, Owen! -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10495] t/db_dependent/HoldsQueue.t can fail unnecessarily
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10495 Jonathan Druart changed: What|Removed |Added Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10495] t/db_dependent/HoldsQueue.t can fail unnecessarily
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10495 Jonathan Druart changed: What|Removed |Added Attachment #19159|0 |1 is obsolete|| --- Comment #3 from Jonathan Druart --- Created attachment 19173 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19173&action=edit bug 10495: set precondition for HoldsQueue test t/db_dependent/HoldsQueue.t assumed, but did not check, that the AutomaticItemReturns system preference was off at the beginning of the test un. This patch makes sure that that assumption is met. To test: [1] Make sure that at least one item is on loan (this is another assumption that the test case makes, one that should be corrected with the work proposed for bug 10336. [2] Turn the AutomaticItemReturn system preference on. [3] Run the test: prove -v t/db_dependent/HoldsQueue.t [4] Tests 4 and 6 should fail. [5] Apply the patch. [6] Run the test case again; this time, all tests should pass. Signed-off-by: Galen Charlton -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #44 from M. de Rooy --- 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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10495] t/db_dependent/HoldsQueue.t can fail unnecessarily
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10495 Jonathan Druart changed: What|Removed |Added CC||jonathan.dru...@biblibre.co ||m --- Comment #2 from Jonathan Druart --- Galen, I got a bad news, with my DB tests, I have a bad news, with your patch I get: t/db_dependent/HoldsQueue.t .. 1/18 Use of uninitialized value $borrower_branchcode in string ne at t/db_dependent/HoldsQueue.t line 36. Use of uninitialized value $borrower_branchcode in string ne at t/db_dependent/HoldsQueue.t line 36. [...] Use of uninitialized value $borrower_branchcode in string ne at t/db_dependent/HoldsQueue.t line 36. Use of uninitialized value $borrower_branchcode in join or string at t/db_dependent/HoldsQueue.t line 48. DBD::mysql::st execute failed: Column 'frombranch' cannot be null at t/db_dependent/HoldsQueue.t line 55. DBD::mysql::st execute failed: Column 'frombranch' cannot be null at t/db_dependent/HoldsQueue.t line 55. # Looks like you planned 18 tests but ran 2. # Looks like your test exited with 255 just after 2. t/db_dependent/HoldsQueue.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 16/18 subtests Test Summary Report --- t/db_dependent/HoldsQueue.t (Wstat: 65280 Tests: 2 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 18 tests but ran 2. Files=1, Tests=2, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.43 cusr 0.02 csys = 0.47 CPU) Result: FAIL But I have a good one, if I apply 10336 before yours, I get: t/db_dependent/HoldsQueue.t .. ok All tests successful. Files=1, Tests=18, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.53 cusr 0.06 csys = 0.62 CPU) Result: PASS So I will sign off this one! Thanks! -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10500] Improve isbn matching when importing records
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10500 --- Comment #1 from Kyle M Hall --- Created attachment 19172 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19172&action=edit WIP - Improve ISBN Matching -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10500] New: Improve isbn matching when importing records
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10500 Bug ID: 10500 Summary: Improve isbn matching when importing records Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcha...@gmail.com Reporter: k...@bywatersolutions.com The MARC standards do not require that isbn fields contain only the isbn itself, and may contain other data, e.g. "0394502884 (Random House) :". Do to this, it's possible for two records to fail to match based on isbn because though each my have the same valid isbn, the other data in the field can cause them to not match. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10500] Improve isbn matching when importing records
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10500 Kyle M Hall changed: What|Removed |Added Assignee|gmcha...@gmail.com |k...@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921
--- Comment #43 from M. de Rooy ---
(In reply to comment #40)
> 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. :(
If we go through DBI, we have actually two choices: the more generic
last_insert_id and the mysql-bound mysql_insert_id.
If you do a grep on both, you will see that they are used a lot in Koha.
Actually, AddBiblio relies on:
my $biblionumber = $dbh->{'mysql_insertid'};
But note that last_insert_id may be more portable, it is considered less
reliable than e.g. using MySQL with mysql_insertid.
Since AddBiblio relies on it, I would have no objection to using one of the two
constructs.
One other point: I see confirmation that it is connection-safe, but I saw some
claims that it could not be thread-safe (threads using the same connection).
Of course, this also holds for current code.
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #42 from M. de Rooy --- (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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10336] UT: HoldsQueue.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10336 Galen Charlton changed: What|Removed |Added CC||gmcha...@gmail.com --- Comment #10 from Galen Charlton --- (In reply to comment #9) > Unfortunately, 2 tests still don't pass. Bug 10495 may be relevant. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10499] UT: VirtualShelves.t needs a database transaction
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10499 M. de Rooy changed: What|Removed |Added CC||m.de.r...@rijksmuseum.nl --- Comment #2 from M. de Rooy --- Could you have a look at bug 10386? It was already there.. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 6590] Removing hyphens from isbn and issn when cataloging a biblio
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6590 Kyle M Hall changed: What|Removed |Added CC||k...@bywatersolutions.com --- Comment #22 from Kyle M Hall --- > Or could we do some trickery before the indexing? Like add a Koha-specific, > hidden subfield to 020 where we store a normalized ISBN when a record is > saved/updated? Business::ISBN would be good for doing that, I think. This. Business::ISBN does an excellent job of normalizing ISBNs. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10290] UT: VirtualShelves.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10290 kenza changed: What|Removed |Added Blocks||10499 -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10499] UT: VirtualShelves.t needs a database transaction
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10499 kenza changed: What|Removed |Added Depends on||10290 -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10499] UT: VirtualShelves.t needs a database transaction
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10499 --- Comment #1 from kenza --- Created attachment 19171 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19171&action=edit Bug 10499: VirtualShelves.t - wrap tests in a database connection Before this patch, the queries in VirtualShelves.t were committed in the database and have to be removed at the end. This patch wraps tests in a database connection. Test plan: prove t/db_dependent/VirtualShelves.t VirtualShelves.t .. ok All tests successful. Files=1, Tests=72, 1 wallclock secs ( 0.06 usr 0.00 sys + 0.72 cusr 0.06 csys = 0.84 CPU) Result: PASS -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10499] UT: VirtualShelves.t needs a database transaction
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10499 kenza changed: What|Removed |Added Status|ASSIGNED|Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10499] New: UT: VirtualShelves.t needs a database transaction
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10499 Bug ID: 10499 Summary: UT: VirtualShelves.t needs a database transaction Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: gmcha...@gmail.com Reporter: kenza.z...@biblibre.com -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10499] UT: VirtualShelves.t needs a database transaction
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10499 kenza changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|gmcha...@gmail.com |kenza.z...@biblibre.com -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #41 from Nuño López Ansótegui --- (In reply to comment #39) > (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? 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? -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10497] star ratings not showing right in ccsr detail
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10497 Ed Veal changed: What|Removed |Added CC||ed.v...@bywatersolutions.co ||m --- Comment #2 from Ed Veal --- This is also an issue with the results page. I checked the code and the star on the results page is not showing because it is looking for "../../images/star-ratings-sprite.png" and the image is not present there. Regarding the details page and the start rating. It appears that there is no css for the ratings for the ccsr theme. Ed -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #40 from Katrin Fischer --- 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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 M. de Rooy changed: What|Removed |Added QA Contact||m.de.r...@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #39 from M. de Rooy --- (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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #38 from M. de Rooy --- Nuno, I came across this SQL construct. It makes the use of a exclusive row level lock not needed: UPDATE tablename SET counter = LAST_INSERT_ID( counter + 1) WHERE id=xxx SELECT LAST_INSERT_ID(); The second select does not need table access anymore. So you really make it one call. Concurrent use is covered nicely. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 --- Comment #37 from Nuño López Ansótegui --- 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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui changed: What|Removed |Added Status|Failed QA |Needs Signoff --- Comment #36 from Nuño López Ansótegui --- (In reply to comment #33) > Still some comments, but we are coming further :) Thanks for your patience.. > > 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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9921] Make it possible to force 001 = biblionumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9921 Nuño López Ansótegui changed: What|Removed |Added Attachment #19156|0 |1 is obsolete|| --- Comment #35 from Nuño López Ansótegui --- 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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 4456] Access to order by PO Number
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4456 Amit changed: What|Removed |Added CC||amitddng...@gmail.com, ||colin.campbell@ptfs-europe. ||com Assignee|colin.campbell@ptfs-europe. |amitddng...@gmail.com |com | -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10480] Cataloging plugins without redefining
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10480 M. de Rooy changed: What|Removed |Added Attachment #19168|0 |1 is obsolete|| --- Comment #10 from M. de Rooy --- Created attachment 19169 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19169&action=edit Bug 10480: Followup for additem.pl (no redefines for plugins) Adds the same functionality for additem as in addbiblio. Note that the new subroutine is slightly different from the addbiblio case. Test plan: Test your cataloging plugins on Add/edit items. If you have no one, temporarily connect new_example_plugin.pl; it will only put 12345 in your item field. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10480] Cataloging plugins without redefining
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10480 --- Comment #9 from M. de Rooy --- Created attachment 19168 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19168&action=edit Bug 10480: Followup for additem.pl (no redefines for plugins) Adds the same functionality for additem as in addbiblio. Note that the new subroutine is slightly different from the addbiblio case. Test plan: Test your cataloging plugins on Add/edit items. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10480] Cataloging plugins without redefining
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10480 --- Comment #8 from M. de Rooy --- I just realize that we do need to make a similar change in additem.pl (of course..) So indeed, it was not perfect yet. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10480] Cataloging plugins without redefining
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10480 M. de Rooy changed: What|Removed |Added Assignee|nu...@masmedios.com |m.de.r...@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10010] Use jQueryUI Accordion to display constraints in MARC subfield editor
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10010 Katrin Fischer changed: What|Removed |Added Status|Signed Off |Passed QA --- Comment #10 from Katrin Fischer --- You are right, thx Jonathan! It happens sometimes when using git bz that the status pulldown in bugzilla is still on the old status... then you add a comment and it's resetting. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10448] Changing framework when cataloguing clears all fields
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10448 Jonathan Druart changed: What|Removed |Added CC||jonathan.dru...@biblibre.co ||m --- Comment #5 from Jonathan Druart --- (In reply to comment #4) > Jonathan, since we have moved to GPL3+ can I update the license text when > QAing this? Yes, of course. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10010] Use jQueryUI Accordion to display constraints in MARC subfield editor
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10010 --- Comment #9 from Jonathan Druart --- Katrin, reading the history, it seems you did not mean to switch back to 'Signed Off'. Could you confirm this patch had passed QA? -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10336] UT: HoldsQueue.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10336 Jonathan Druart changed: What|Removed |Added Attachment #18388|0 |1 is obsolete|| --- Comment #8 from Jonathan Druart --- Created attachment 19167 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19167&action=edit WIP: HoldsQueue.t needs to create its own data -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10336] UT: HoldsQueue.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10336 --- Comment #9 from Jonathan Druart --- Thanks Galen! Unfortunately, 2 tests still don't pass. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9282] authorities auto-completion in mainmainentry
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9282
M. de Rooy changed:
What|Removed |Added
Status|Signed Off |Failed QA
--- Comment #10 from M. de Rooy ---
Looks quite good to me, but I am wondering about this now:
} elsif ($tag eq '180') {
$subfields_to_report = 'vxyz';
[etc. etc. etc.]
if ($subfields_to_report) {
push @authorized, {
heading => $field->as_string($subfields_to_report),
hemain => $field->subfield( substr($subfields_to_report,
0, 1) ),
If you use the first char here, you will take $v into hemain. But I think that
you should take $x for the 18X fields.
I would like to see a response from Jared here, as I assume that he was
responsible for quite some changes in this module. Could you please attract his
attention? Thanks.
Changing status to reflect need for clarification.
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9282] authorities auto-completion in mainmainentry
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9282 --- Comment #9 from M. de Rooy --- QA: Looking now.. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
