[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 jonathan.dru...@biblibre.com 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 10336] UT: HoldsQueue.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10336 Jonathan Druart jonathan.dru...@biblibre.com changed: What|Removed |Added Attachment #19167|0 |1 is obsolete|| --- Comment #12 from Jonathan Druart jonathan.dru...@biblibre.com --- Created attachment 19177 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19177action=edit Bug 10336: HoldsQueue.t needs to create its own data After applying this patch and the patch submitted in bug 10495, you can run prove t/db_dependent/HoldsQueue.t and admire that all tests pass. This patch creates a borrower and uses Koha routines instead of directly request the database. -- 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 #3 from kenza kenza.z...@biblibre.com --- The patch 10386 doesn't add the rollback, so i think these two patches are complementary. -- 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 #67 from Kyle M Hall k...@bywatersolutions.com --- 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. This a good question! I've already submitted a patch that uses DBIC, Bug 10493. It's interesting because I started writing using the standard C4 and Koha modules, but I was extremely surprised to find how much easier and quicker the development went once I switched to DBIC! I think we need to push as much logic into the DBIC classes as we can ( only the logic which sensibly should be there or course ). For example, I'm sure Koha::Schema::Result::Borrower is ripe for additional logic. C4::Members::IsMemberBlocked() could easily be replaced with $borrower-IsBlocked(). 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 The only issue I see is we have 3 authors here. Elliot is no longer active in the community so I cannot speak for him, though I'm sure we can contact him about it. If a merge before push is necessary, I'd say he should retain the authorship line, considering this was originally his patch. On the other hand, a squashed patch could be uploaded for QA purposes, and the individual patches pushed afterward. I think that should provide the QA clarity while retaining individual patch authorship. -- 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 #68 from Paul Poulain paul.poul...@biblibre.com --- (In reply to comment #67) 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. This a good question! I've already submitted a patch that uses DBIC, Bug 10493. It's interesting because I started writing using the standard C4 and Koha modules, but I was extremely surprised to find how much easier and quicker the development went once I switched to DBIC! Have you seen my comment 57 and the other patch I made ? It also includes rewrite for some admin/ scripts. I agree that it's *much* easier ;-) (feel free to rebase, and I've no problem with loosing my authorship on those patches, if it can help things to go faster ;-) ) I think we need to push as much logic into the DBIC classes as we can ( only the logic which sensibly should be there or course ). For example, I'm sure Koha::Schema::Result::Borrower is ripe for additional logic. C4::Members::IsMemberBlocked() could easily be replaced with $borrower-IsBlocked(). Agreed. OTOH, we must be carefull with the methods we include : not too much, not too few. With the 3 level Business / DataObject / DB, I think things will be easy to manage : as many Business as we need, as small as possible, linked/linking to DO then DB. The only issue I see is we have 3 authors here. Elliot is no longer active in the community so I cannot speak for him, though I'm sure we can contact him about it. If a merge before push is necessary, I'd say he should retain the authorship line, considering this was originally his patch. On the other hand, a squashed patch could be uploaded for QA purposes, and the individual patches pushed afterward. I think that should provide the QA clarity while retaining individual patch authorship. I prefer the 2nd option for copyright purposes, but the 1st one for simplicity readability. -- 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 9788] Improvements for calling GetReservesFromItemnumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788
Kyle M Hall k...@bywatersolutions.com changed:
What|Removed |Added
CC||k...@bywatersolutions.com
--- Comment #6 from Kyle M Hall k...@bywatersolutions.com ---
I recieved this error when I tried to confirm the hold:
The 'days' parameter (undef) to DateTime::Duration::new was an 'undef', which
is not one of the allowed types: scalar
at /usr/lib/perl5/DateTime/Duration.pm line 31.
DateTime::Duration::new(undef, 'days', undef) called at
/usr/lib/perl5/DateTime.pm line 1629
DateTime::add('DateTime=HASH(0x42cf260)', 'days', undef) called at
/home/koha/kohaclone/C4/Letters.pm line 614
C4::Letters::_parseletter('HASH(0x42ced20)', 'reserves', 'HASH(0x42d43b0)')
called at /home/koha/kohaclone/C4/Letters.pm line 555
C4::Letters::_substitute_tables('HASH(0x42ced20)', 'HASH(0x42d0ca0)')
called at /home/koha/kohaclone/C4/Letters.pm line 503
C4::Letters::GetPreparedLetter('letter_code', 'HOLD_PRINT', 'tables',
'HASH(0x42d0ca0)', 'substitute', 'HASH(0x42d0130)', 'branchcode', 'CPL',
'module', ...) called at /home/koha/kohaclone/C4/Reserves.pm line 1907
C4::Reserves::_koha_notify_reserve(3, 19, 1) called at
/home/koha/kohaclone/C4/Reserves.pm line 1294
C4::Reserves::ModReserveAffect(3, 19, undef) called at
/home/koha/kohaclone/circ/returns.pl line 145
--
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 9788] Improvements for calling GetReservesFromItemnumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Needs Signoff |Failed 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 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Needs Signoff |Failed QA --- Comment #13 from Kyle M Hall k...@bywatersolutions.com --- (In reply to comment #12) Created attachment 19177 [details] [review] Bug 10336: HoldsQueue.t needs to create its own data After applying this patch and the patch submitted in bug 10495, you can run prove t/db_dependent/HoldsQueue.t and admire that all tests pass. This patch creates a borrower and uses Koha routines instead of directly request the database. Then I apply both patches and run HoldsQueue.t, I get the following error: perl t/db_dependent/HoldsQueue.t 1..18 ok 1 - use C4::Reserves; ok 2 - use C4::HoldsQueue; Type of arg 1 to keys must be hash (not subroutine entry) at t/db_dependent/HoldsQueue.t line 47, near GetBranches; Execution of t/db_dependent/HoldsQueue.t aborted due to compilation errors. # Looks like you planned 18 tests but ran 2. # Looks like your test exited with 255 just after 2. And this: prove t/db_dependent/HoldsQueue.t t/db_dependent/HoldsQueue.t .. 1/18 Type of arg 1 to keys must be hash (not subroutine entry) at t/db_dependent/HoldsQueue.t line 47, near GetBranches; Execution of t/db_dependent/HoldsQueue.t aborted due to compilation errors. # 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, 1 wallclock secs ( 0.02 usr 0.01 sys + 0.60 cusr 0.05 csys = 0.68 CPU) Result: FAIL -- 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 10386] UT: VirtualShelves.t needs some more adjustments
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10386 Kyle M Hall k...@bywatersolutions.com 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 10386] UT: VirtualShelves.t needs some more adjustments
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10386 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #18821|0 |1 is obsolete|| --- Comment #4 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19178 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19178action=edit Bug 10386: VirtualShelves.t needs some more adjustments Most important: Does no longer delete all shelves! Checks if there are ten borrowers for testing. But even works without them :) When creating or modifying lists, takes name clashes into consideration. Small change to _CheckShelfName in VirtualShelves module. Making it possible to check a name for a list whose owner has been set to NULL. Note that a test like field=? with undef for placeholder will not work in MySql. Test plan: How do you test a test? Well, you could run it on various databases.. But for real hacking, you could also add some debug lines. I tested this by forcing 10 undefs in @borrowernumbers. And by overwriting the return value of randomname with an existing name. Signed-off-by: Kyle M Hall 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 10499] UT: VirtualShelves.t needs a database transaction
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10499 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Needs Signoff |Patch doesn't apply 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 10336] UT: HoldsQueue.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10336 Jonathan Druart jonathan.dru...@biblibre.com changed: What|Removed |Added Status|Failed QA |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 Jonathan Druart jonathan.dru...@biblibre.com changed: What|Removed |Added Attachment #19177|0 |1 is obsolete|| --- Comment #14 from Jonathan Druart jonathan.dru...@biblibre.com --- Created attachment 19179 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19179action=edit Bug 10336: HoldsQueue.t needs to create its own data After applying this patch and the patch submitted in bug 10495, you can run prove t/db_dependent/HoldsQueue.t and admire that all tests pass. This patch creates a borrower and uses Koha routines instead of directly request the database. -- 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 #15 from Jonathan Druart jonathan.dru...@biblibre.com --- (In reply to comment #13) Type of arg 1 to keys must be hash (not subroutine entry) at t/db_dependent/HoldsQueue.t line 47, near GetBranches; It's certainly caused by the perl version (I am using v.5.14). Could you try again with the last patch please? -- 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 8367] How long is a hold waiting for pickup at a more granular level
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Kyle M Hall k...@bywatersolutions.com 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 8367] How long is a hold waiting for pickup at a more granular level
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Signed Off |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 8367] How long is a hold waiting for pickup at a more granular level
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #19116|0 |1 is obsolete|| --- Comment #57 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19182 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19182action=edit [SIGNED-OFF] Bug 8367: Followup FIX a sql statement (bad conflict merge) Signed-off-by: Kyle M Hall 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 8367] How long is a hold waiting for pickup at a more granular level
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #19107|0 |1 is obsolete|| --- Comment #55 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19180 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19180action=edit [SIGNED-OFF] Bug 8367: Add more granular level for ReservesMaxPickUpDelay This patch adds: - a new column in the issuing rules - a new column reserves.maxpickupdate (+old_reserves) It contains the waitingdate + the corresponding max pickup delay. Each time the waitingdate is modified, this value will be modified too. - a new field issuingrules.holdspickupdelay This patch removes the ReservesMaxPickUpDelay syspref. The update database script will update the issuingrules table with the correct value before removing it. You can now specify a pickup delay for an hold function of a patron category and/or a item type and/or a library. To test: Check there is no regression with a normal reserve workflow. Add one or more issuingrules. Update the new column 'Holds pickup delay' in your issuing rules. In 4 templates, you can see the max pickup delay for an hold (circ/circulation.tt, circ/waitingreserves.tt, members/moremember.tt, opac-user.tt). According to a library and an item type, the maxpickupdate value will be equal to the waiting date + the pickup delay defined. Signed-off-by: Kyle M Hall 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 8367] How long is a hold waiting for pickup at a more granular level
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #19108|0 |1 is obsolete|| --- Comment #56 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19181 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19181action=edit Bug 8367: Skip to next open day if max pickup date is a holiday Test plan: 1) Note your ReservesMaxPickUpDelay setting. 2) Create and trap a hold 3) View waitingreserves.pl, note the last pickup date, and the pickup location 4) Edit the calendar for the given location, and make the pickup date a holiday 4) View waitingreserves.pl, the last pickup date should now be the increased by one day -- 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 7228] can't order more than 1 when importing all from staged file
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7228 --- Comment #23 from Nicole C. Engard neng...@gmail.com --- The problem I reported was the one thing that this patch doesn't fix: - syspref AcqCreateItem : create items on ORDERING - in a basket, create an order (click on add to add an item = quantity = 1) - save the order - reopen the order - try to change the quantity (2 instead of 1), without clicking on add to create a new item = you cannot (alert message) = the behavior is the same as before the patch If I want to order from a staged file I should be able to add multiple copies even if I'm doing the item at the time of ordering. Otherwise what's the benefit? Nicole -- 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 10487] UT: GetMaxPickupDate needs unit tests.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10487 Kyle M Hall k...@bywatersolutions.com 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 10487] UT: GetMaxPickupDate needs unit tests.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10487 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #19110|0 |1 is obsolete|| --- Comment #2 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19183 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19183action=edit Bug 10487: UT: GetMaxPickupDate needs unit tests GetMaxPickupDate is introduced by bug 8367. It needs unit tests. $ prove t/db_dependent/Reserves.t should produce: t/db_dependent/Reserves.t .. 1/14 # # Creating biblio instance for testing. # Creating item instance for testing. ERROR: GetMaxPickupDate is called without reserve and without itemnumber ERROR: GetMaxPickupDate is called without reserve and without itemnumber t/db_dependent/Reserves.t .. 11/14 # Deleting item testing instance. # Deleting biblio testing instance. # Deleting borrower. t/db_dependent/Reserves.t .. ok All tests successful. Files=1, Tests=14, 1 wallclock secs ( 0.03 usr 0.00 sys + 0.42 cusr 0.06 csys = 0.51 CPU) Result: PASS Signed-off-by: Kyle M Hall 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 9351] item type not recorded correctly in statistics for returns and some local use
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9351 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Needs Signoff |Failed QA CC||k...@bywatersolutions.com --- Comment #13 from Kyle M Hall k...@bywatersolutions.com --- At step one, when I was able to check out a Not For Loan item to a patron. I switched back to master and tried again, and my checkout was blocked correctly. -- 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 10483] check_uniqueness.pl does not work
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10483 Kyle M Hall k...@bywatersolutions.com 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 10483] check_uniqueness.pl does not work
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10483
Kyle M Hall k...@bywatersolutions.com changed:
What|Removed |Added
Attachment #19075|0 |1
is obsolete||
--- Comment #3 from Kyle M Hall k...@bywatersolutions.com ---
Created attachment 19184
--
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19184action=edit
Bug 10483 - check_uniqueness.pl does not work
When syspref UniqueItemFields is defined, the item uniqueness is tested in
acquisition by an Ajax call to check_uniqueness.pl.
I noticed that it does not work, item is always created without alert even on
existing barcode.
I have looked in perl debug mode and found that in check_uniqueness.pl :
my $input = new CGI;
my @field = $input-param('field');
my @value = $input-param('value');
@field and @value are always empty.
It is because in CGI the params are named field[] and value[].
It seems to be because of the ajax serialization of a Javascript Array.
This patch corrects this bug.
Test plan :
- Select an existing item with barcode
- Add barcode to UniqueItemFields syspref (use space as separator for
multiple values)
- Set AcqCreateItem syspref to Create an item when placing an order
- Go to an acquisition basket
- Create a new order from empty
- Enter existing barcode in item form and save
= You get an alert that barcode already exists and order is not saved
- Enter a non-existing barcode in item form and save
= Order and item are created
Signed-off-by: Kyle M Hall 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 10289] UT: Reserves.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10289 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #18660|0 |1 is obsolete|| --- Comment #11 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19185 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19185action=edit Bug 10289: UT: Reserves.t needs to create its own data Try before the patch: prove t/db_dependent/Reserves.t And after, it should produce: t/db_dependent/Reserves.t .. 1/4 # # Creating biblio instance for testing. # Creating item instance for testing. # Deleting item testing instance. # Deleting biblio testing instance. # Deleting borrower. t/db_dependent/Reserves.t .. ok All tests successful. Files=1, Tests=4, 1 wallclock secs ( 0.02 usr 0.01 sys + 0.39 cusr 0.02 csys = 0.44 CPU) Result: PASS Signed-off-by: Kyle M Hall 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 10289] UT: Reserves.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10289 Kyle M Hall k...@bywatersolutions.com 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 10334] UT: t/db_dependent/needs_user_input/* are unusable
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10334 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Signed Off |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 10334] UT: t/db_dependent/needs_user_input/* are unusable
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10334 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #18397|0 |1 is obsolete|| --- Comment #4 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19186 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19186action=edit Bug 10334 - UT: t/db_dependent/needs_user_input/* are unusable t/db_dependent/needs_user_input/Auth.t and t/db_dependent/needs_user_input/Auth_with_ldap.t seem not really useful. If I refer to the git history, it seems that they are antiquated tests. The first one is not compilable: perl -wc t/db_dependent/needs_user_input/Auth.t Can't locate override_context_prefs.pm Signed-off-by: Chris Cormack ch...@bigballofwax.co.nz Signed-off-by: Kyle M Hall 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 6553] Parentheses in corporate author break tracings
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6553 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added QA Contact|koha-b...@lists.koha-commun |k...@bywatersolutions.com |ity.org | -- 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 10333] UT: Labels/t_Batch.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10333 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Signed Off |Failed QA CC||k...@bywatersolutions.com --- Comment #3 from Kyle M Hall k...@bywatersolutions.com --- With this patch, the tests now assume that the home and holding branch are in 952 a and b. While this is the Koha default, it's not necessarily true. I think it would be better to get the values for these fields using GetMarcFromKohaField(). -- 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 10362] on return with reserve or transfer the alerts are not shown
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10362 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Signed Off |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 10362] on return with reserve or transfer the alerts are not shown
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10362 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #18536|0 |1 is obsolete|| --- Comment #3 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19187 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19187action=edit Bug 10362 - on return with reserve or transfer the alerts are not shown When a return is performed on an item with a reserve or a transfer, the possible alert messages are not shown. These alerts are cases from errmsgloop like NotIssued, debarred ... This patch changes the template to show both messages and alerts. Test plan : - Perform an checkout that will a checkin : * need a transfert (return in a different branch) * set user debarred (depends on issuing rules) - Perform check-in = You get tranfert message and debarment alert Signed-off-by: Srdjan srd...@catalyst.net.nz Signed-off-by: Kyle M Hall 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 10380] output_pref should use a hashref for parameters
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10380 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Signed Off |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 10380] output_pref should use a hashref for parameters
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10380
Kyle M Hall k...@bywatersolutions.com changed:
What|Removed |Added
Attachment #18597|0 |1
is obsolete||
--- Comment #3 from Kyle M Hall k...@bywatersolutions.com ---
Created attachment 19188
--
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19188action=edit
Bug 10380: Change prototype for output_pref routine
Koha::DateUtils::output_pref takes 4 parameters and the last one is a
boolean, so some calls are:
output_pref($dt, undef, undef, 1)
This patch changes it prototype to
output_pref({
dt = $dt,
dateformat = $dateformat,
timeformat = $timeformat,
dateonly = $boolean
});
an alternative is to call the output_pref routine with a datetime
object, without using an hashref:
output_pref($dt);
Signed-off-by: Srdjan srd...@catalyst.net.nz
Signed-off-by: Kyle M Hall 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 9854] Add 'ttf-dejavu*' packages to debian/control file, for label printing (bug 8375)
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9854 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Signed Off |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 9854] Add 'ttf-dejavu*' packages to debian/control file, for label printing (bug 8375)
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9854 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #18566|0 |1 is obsolete|| --- Comment #2 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19189 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19189action=edit bug 9854: add ttf-dejavu as dependency for Debian packages ttf-dejavu (i.e., the core and extra DejaVu TrueType) fonts are used by the proposed fix for bug 8375. To test, build and install the Koha packages for Debian and verify that the ttf-dejavu package is installed. Signed-off-by: Galen Charlton g...@esilibrary.com Signed-off-by: Kyle M Hall 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 10247] Too many reserves due to syspref does not show warning
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10247 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #18827|0 |1 is obsolete|| --- Comment #8 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19190 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19190action=edit Bug 10247 - Too many reserves due to syspref does not show warning On intranet, when placing a reserve : If borrower as reached the reserves quota, a warning should appear : Cannot place hold * Too Many Holds: TEST has too many holds. This works when quota defined in circulation rules is reached but not when quota specified in syspref maxreserves is reached, in case this quota is lower than the one defined is circulation rules. This is because template param maxreserves is set twice, this patch corrects this bug. Also moves warnings and messages conditionnal variable from perl to template because it cause the same bug as for maxreserves. Signed-off-by: Srdjan srd...@catalyst.net.nz Signed-off-by: Kyle M Hall 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 10247] Too many reserves due to syspref does not show warning
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10247 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Status|Signed Off |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 Kyle M Hall k...@bywatersolutions.com 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 10336] UT: HoldsQueue.t needs to create its own data
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10336 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #19179|0 |1 is obsolete|| --- Comment #16 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19191 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19191action=edit Bug 10336: HoldsQueue.t needs to create its own data After applying this patch and the patch submitted in bug 10495, you can run prove t/db_dependent/HoldsQueue.t and admire that all tests pass. This patch creates a borrower and uses Koha routines instead of directly request the database. Signed-off-by: Kyle M Hall 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 10380] output_pref should use a hashref for parameters
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10380
--- Comment #4 from Galen Charlton gmcha...@gmail.com ---
(In reply to comment #1)
This patch changes it prototype to
output_pref({
dt = $dt,
If we switch to named parameters, we may as well avoid over-abbreviating.
Would there be any objection to a followup that renames 'dt' to 'date'?
--
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 10334] UT: t/db_dependent/needs_user_input/* are unusable
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10334 Galen Charlton gmcha...@gmail.com changed: What|Removed |Added Status|Passed QA |Pushed to Master CC||gmcha...@gmail.com --- Comment #5 from Galen Charlton gmcha...@gmail.com --- Pushed to master. Thanks, Jonathan! -- 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 #69 from Galen Charlton gmcha...@gmail.com --- (In reply to comment #68) On the other hand, a squashed patch could be uploaded for QA purposes, and the individual patches pushed afterward. I think that should provide the QA clarity while retaining individual patch authorship. I prefer the 2nd option for copyright purposes, but the 1st one for simplicity readability. I think the attribution issue can be addressed when squashing by adding Author: tags to the commit message that list contributor's whose attribute would otherwise be taken away by the squash. -- 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 10430] status filter not working in serial claims when translated
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10430 Fridolyn SOMERS fridolyn.som...@biblibre.com changed: What|Removed |Added Severity|minor |major --- Comment #4 from Fridolyn SOMERS fridolyn.som...@biblibre.com --- I update to major importance because many libraries have reported this bug. -- 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 #70 from Galen Charlton gmcha...@gmail.com --- (In reply to comment #66) (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. What I propose is a multi-part process: [1] Once DBIC support is pushed, along with at least one other patch that uses it, we promote the existence of it vigorous, with the aim of encouraging folks to use it for new functionality even *before* KohaCon. I agree that seminars there would be a good idea, too. I think it would be a reasonable goal to get to the point where, once the cycle for 3.16 starts, DBIC is required for any new code that interacts with the database. That can't be a requirement for 3.14, of course, but we can certainly encourage it. [2] I agree that we should make a concerted effort to switch existing code over to DBIC, but with a *very* strong caveat: I am disinclined to push patches that refactor code to use DBIC that are not backed up by unit tests first. There will be some trickiness in writing such tests, of course, since switching functionality to DBIC also means restructuring the API, but I have very little tolerance for user-visible regressions in the name of architectural improvements, no matter how important. However, one question that has to be answered first: who has time to commit to systematically refactoring existing code? An answer to that would inform future planning. -- 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 9854] Add 'ttf-dejavu*' packages to debian/control file, for label printing (bug 8375)
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9854 Galen Charlton gmcha...@gmail.com changed: What|Removed |Added CC||gmcha...@gmail.com --- Comment #3 from Galen Charlton gmcha...@gmail.com --- Note that I'm going to sit on this until a patch for 8375 is approved (the bug dependencies on this are a little weird). -- 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 #71 from Paul Poulain paul.poul...@biblibre.com --- (In reply to comment #70) What I propose is a multi-part process: [1] Once DBIC support is pushed, along with at least one other patch that uses it, we promote the existence of it vigorous, with the aim of encouraging folks to use it for new functionality even *before* KohaCon. I agree that seminars there would be a good idea, too. +1 I think it would be a reasonable goal to get to the point where, once the cycle for 3.16 starts, DBIC is required for any new code that interacts with the database. That can't be a requirement for 3.14, of course, but we can certainly encourage it. +1, even if the big deal here will be to mix DBIC C4/ code: I want to add a feature that could use C4/Acquisition.pm::whatever. Should I write a Koha/BusinessLogic::whatever_for_DBIC anyway ? I don't see an clear answer to this question. If I answer yes, then it mean there are 2 whatever functions, that will be a pain to maintain. [2] I agree that we should make a concerted effort to switch existing code over to DBIC, but with a *very* strong caveat: I am disinclined to push patches that refactor code to use DBIC that are not backed up by unit tests first. There will be some trickiness in writing such tests, of course, since switching functionality to DBIC also means restructuring the API, but I have very little tolerance for user-visible regressions in the name of architectural improvements, no matter how important. in my tests on bug 8309, I started with some basic admin/ scripts. I think it's a good way to start, because there is only a few dependencies, and a lot of things that are not in any C4/ file already. However, one question that has to be answered first: who has time to commit to systematically refactoring existing code? An answer to that would inform future planning. +1 Next week, there's the yearly french kohacon, I plan to speak openly of this problem: we need time, and, as everyone knows, time is money (I need to pay BibLibre staff you know... what a pity :D ). I think we should also speak of this during KohaCon13 -- 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 #72 from Kyle M Hall k...@bywatersolutions.com --- [1] Once DBIC support is pushed, along with at least one other patch that uses it, we promote the existence of it vigorous, with the aim of encouraging folks to use it for new functionality even *before* KohaCon. I agree that seminars there would be a good idea, too. That sounds great to me! I think it would be a reasonable goal to get to the point where, once the cycle for 3.16 starts, DBIC is required for any new code that interacts with the database. That can't be a requirement for 3.14, of course, but we can certainly encourage it. I for one, will be writing all future patches the involve new scripts and subs with DBIC from this point on. [2] I agree that we should make a concerted effort to switch existing code over to DBIC, but with a *very* strong caveat: I am disinclined to push patches that refactor code to use DBIC that are not backed up by unit tests first. There will be some trickiness in writing such tests, of course, since switching functionality to DBIC also means restructuring the API, but I have very little tolerance for user-visible regressions in the name of architectural improvements, no matter how important. I agree with unit testable-ness for functions, but what about scripts? One of the great reasons to have DBIC is we can just use find() or single() to grab a borrower in the script, rather than calling C4::Members::GetMember. Script mods should of course have a full and thorough test plan, but I can't imagine them being unit testable, right? However, one question that has to be answered first: who has time to commit to systematically refactoring existing code? An answer to that would inform future planning. I for one will absolutely commit to refactoring existing code! For smaller modules I could probably submit one a week or more ( considering smaller modules have fewer subs and often fewer callers ). Larger modules with subs called often will probably need to be refactored on a sub by sub basis. -- 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 #73 from Galen Charlton gmcha...@gmail.com ---
Paste of an IRC conversation with the maintainer of DBIX::Class today:
riba I wanted to comment on
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8798 but didn't find a
way without creating yet another account
huginn Bug 8798: enhancement, P3, ---, elliott, Signed Off , Add the use of
DBIx::Class
- riba is now known as Guest688
- Guest688 is now known as ribasushi
ribasushi wtf..
ribasushi anyway - is any of the bug participants around?
jcamins ribasushi: I think gmcharlt, khall, and paul_p have been discussing
that recently.
paul_p ribasushi yes, I'm here
ribasushi hi
-- lds (~thunde...@giono.biblibre.com) has quit (Quit: lds)
paul_p hi ribasushi
gmcharlt hi ribasushi
ribasushi paul_p: I am the current-long-standing DBIC maint
ribasushi I am excited you guys are migrating DBIC wholesale - I need more
such success stories to brag about ;D
ribasushi I looked over some of the diffs and there's one thing that jumped
at me as very wrong
-- lds (~thunde...@giono.biblibre.com) has joined #koha
paul_p ribasushi well, we've got the decision, some nice hackers, what we
lack is time (or money, but that's almost the same thing : I could dedicate 2
FTE to this task if I had enough money...)
paul_p ribasushi which mistake ?
ribasushi you have set (in many places) ...
ribasushi I am looking for it, lost the diff...
-- chris_n (~Chris@184.7.21.42) has quit (Quit: Coyote finally caught me)
ribasushi $ENV{'DBIC_DONT_VALIDATE_RELS'} - you set this all over the place
ribasushi it was introduced as a backcompat measure for folks with broken
preexisting schema definitions
ribasushi in *new code* this is a sign of a latent data eater
-- Callender (~quas...@50-79-238-214-static.hfc.comcastbusiness.net) has
joined #koha
ribasushi you need to resolve the cause of this (whatever it may actually be)
before going public with a call for conversions
-- chris_n (~Chris@184.7.21.42) has joined #koha
*** Mode #koha +o chris_n by ChanServ
gmcharlt ribasushi: we were figuring that corrections to the schema were
needed anyway
gmcharlt but could you expand on what you mean by latent data eater?
ribasushi the presence of this warning implies an incorrectly set metadata on
the source in question
ribasushi most likely the direction of the relationship is reversed
- Jesse_phone is now known as JesseM
ribasushi the higher the DBIC version - the more I rely on the correctness of
such metadata to make informed decisions on the SQL I generate
ribasushi for instance an incorrect relationship direction may end up in a
cascaded delete going in a way that you never anticipated
ribasushi or an entire JOIN being dropped away because DBIC can prove
(based on the erroneous metadata) that it does not need it
gmcharlt gah
gmcharlt thanks for the warning
ribasushi because this stuff happens deep in the guts the consequences may
compound to something I can't currently think of
paul_p ribasushi = am I right if I say adding this will hide any error in
your schema, and that's a bad idea, better fixing the schema ?
ribasushi on the other hand - I *never* rely on metadata blindly, unless I
can provide a reasonable (and timely) warning way in advance hey your schema
metadata makes no sense!
ribasushi gmcharlt: so I am not taking the risk lightly, but there is only so
much I can do ;)
ribasushi paul_p: any error is a tad strong, a number of errors would be
more correct
ribasushi paul_p: also s/better fixing/we have to fix/
gmcharlt ribasushi: well, we'll take that out of the patch and exercise it
more
ribasushi I am sadly not much around IRC lately (life happens etc)
ribasushi but I am always available with a reasonable turnaround at
ribasu...@cpan.org
-- pianohacker (~fe...@vps.lanfort.org) has joined #koha
ribasushi so feel free to contact me if more issues arise
ribasushi gmcharlt: ^^
ribasushi paul_p: ^^
gmcharlt great -- and thanks for taking the time to look it over
paul_p ribasushi we'll probably ask for some hints later ;-)
gmcharlt ribasushi: do you have any objections to my pasting this
conversation into the bug report? (the channel is logged anyway, to be clear)
ribasushi gmcharlt: not at all
-- lds (~thunde...@giono.biblibre.com) has quit (Quit: lds)
gmcharlt thanks
ribasushi gmcharlt: I'd also grp for other ENV overrides
ribasushi in case I missed something (it's a lot of code ;)
ribasushi *grep
--
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 #74 from Galen Charlton gmcha...@gmail.com --- (In reply to comment #71) (In reply to comment #70) I think it would be a reasonable goal to get to the point where, once the cycle for 3.16 starts, DBIC is required for any new code that interacts with the database. That can't be a requirement for 3.14, of course, but we can certainly encourage it. +1, even if the big deal here will be to mix DBIC C4/ code: I want to add a feature that could use C4/Acquisition.pm::whatever. Should I write a Koha/BusinessLogic::whatever_for_DBIC anyway ? I don't see an clear answer to this question. If I answer yes, then it mean there are 2 whatever functions, that will be a pain to maintain. My preference is that that every effort should be made when introducing a DBIC-based method to remove the C4 function(s) that it supersedes; having both a Koha::* method and a C4::* method for the same thing only invites trouble in the form of divergent business logic. Developing new features incrementally can help with that. Of course, I can imagine circumstances where following the recommendation above would require refactoring an unwieldy amount of code. In cases like that, I will *consider* patches that result in Koha/C4 duplication provided that the C4 function is clearly marked as deprecated. If such a patch gets pushed, I'd say that no new code that uses the C4 function would subsequently be allowed. Since all of this refactoring we're facing means that we're essentially building a whole new API, I *strongly* encourage folks to discuss their proposals for refactoring particular methods on koha-devel first. -- 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 #75 from Jared Camins-Esakov jcam...@cpbibliography.com --- (In reply to comment #74) My preference is that that every effort should be made when introducing a DBIC-based method to remove the C4 function(s) that it supersedes; having both a Koha::* method and a C4::* method for the same thing only invites trouble in the form of divergent business logic. Developing new features incrementally can help with that. I have no irons in this fire, but if the C4 functions can be retained as transitional shims rather than simply deleting them, that might reduce the amount of code that required refactoring, and maintain the usefulness of existing unit tests. -- 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 #76 from Galen Charlton gmcha...@gmail.com --- (In reply to comment #72) I agree with unit testable-ness for functions, but what about scripts? One of the great reasons to have DBIC is we can just use find() or single() to grab a borrower in the script, rather than calling C4::Members::GetMember. Script mods should of course have a full and thorough test plan, but I can't imagine them being unit testable, right? That depends on how one writes them. If we think of a script as most of the time being a wrapper that gathers command-line parameters, then calls one or more functions or methods that exist in the Koha namespace, those functions can readily be included in the Test::More-based tests. In other words, we should encourage writing scripts in such a way that unit tests of their core functionality can be easily written. -- 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 #77 from Galen Charlton gmcha...@gmail.com --- (In reply to comment #75) (In reply to comment #74) My preference is that that every effort should be made when introducing a DBIC-based method to remove the C4 function(s) that it supersedes; having both a Koha::* method and a C4::* method for the same thing only invites trouble in the form of divergent business logic. Developing new features incrementally can help with that. I have no irons in this fire, but if the C4 functions can be retained as transitional shims rather than simply deleting them, that might reduce the amount of code that required refactoring, and maintain the usefulness of existing unit tests. That's a good point. Certainly one could envision a C4 method being rewritten to invoke a bunch of DBIC-based code, without the unit test changing at all. But the emphasis would be on such things being *transitional*. -- 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 9788] Improvements for calling GetReservesFromItemnumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788
M. de Rooy m.de.r...@rijksmuseum.nl changed:
What|Removed |Added
Status|Failed QA |Needs Signoff
--- Comment #7 from M. de Rooy m.de.r...@rijksmuseum.nl ---
Thanks for testing Kyle! I would really like to see this patch joining patch
9761.
Since I do not have this error, I checked where you crashed in C4/Letters:
613my $dt = dt_from_string();
614$dt-add( days = C4::Context-preference('ReservesMaxPickUpDelay')
);
L613 gets back the date of today. L614 adds a few days.
Since the crash is on L614, it seems that your pref ReservesMaxPickupDelay is
undefined (perhaps deleted in some other course of development..) ?
Could you check that please?
We can add a test with || 0 or something, but it should normally not be needed.
Hope that fixes 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 8798] Add the use of DBIx::Class
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8798 --- Comment #78 from Kyle M Hall k...@bywatersolutions.com --- I cannot agree more with this assertion. Koha scripts have often been too 'smart' for their own good ; ) Over time this has definitely improved with more and more logic getting pushed into the Modules. I'd say this is where most bugs come from. The bug in the generation of fines in fines.pl vs returns.pl comes to mind. I think a long term goal is to have each system preference checked only once in the code base for any given behavior. That way these types of bugs won't occur. But now I'm getting all pie-in-the-sky and going off topic at the same time! To summarize, in our ideal Koha, scripts just get a bunch of stuff and pass it to the template, without doing much else. That depends on how one writes them. If we think of a script as most of the time being a wrapper that gathers command-line parameters, then calls one or more functions or methods that exist in the Koha namespace, those functions can readily be included in the Test::More-based tests. In other words, we should encourage writing scripts in such a way that unit tests of their core functionality can be easily written. -- 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 #79 from Paul Poulain paul.poul...@biblibre.com --- (In reply to comment #78) I cannot agree more with this assertion. Koha scripts have often been too 'smart' for their own good ; ) Over time this has definitely improved with more and more logic getting pushed into the Modules. I'd say this is where most bugs come from. The bug in the generation of fines in fines.pl vs returns.pl comes to mind. I think a long term goal is to have each system preference checked only once in the code base for any given behavior. That way these types of bugs won't occur. But now I'm getting all pie-in-the-sky and going off topic at the same time! I concur ! And I would add that the 2 level only logic we had (.pl / C4/.pm) was another source of bugs : any logic must sometimes/often be checked in different context, and it's sometimes checked differently. To summarize, in our ideal Koha, scripts just get a bunch of stuff and pass it to the template, without doing much else. agreed ! In other words, we should encourage writing scripts in such a way that unit tests of their core functionality can be easily written. Test::www::Mechanize can also help us testing scripts in web-environment as well. It's sometimes tricky to be sure of the results, but, at least, we can be sure it returns a 200 ;-) -- 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 #80 from Galen Charlton gmcha...@gmail.com --- (In reply to comment #79) tests of their core functionality can be easily written. Test::www::Mechanize can also help us testing scripts in web-environment as well. It's sometimes tricky to be sure of the results, but, at least, we can be sure it returns a 200 ;-) Better than returning 418! [1] ;) [1] http://tools.ietf.org/html/rfc2324 -- 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 9788] Improvements for calling GetReservesFromItemnumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788 --- Comment #9 from M. de Rooy m.de.r...@rijksmuseum.nl --- Created attachment 19192 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19192action=edit Bug 9788: Followup for expirationdate in Letter.pm Pasting comment from the Bugzilla report: Looking bit longer at this code, it is kind of strange to find it there in the first place. Adding maxpickupdelay in Letters.pm should not be there, but it is.. Also this date is not used normally in the default HOLD Available for Pickup notice (that we are generating in this case). And if it would be undef, the expiration date should imo be empty instead of today+0. (before adding maxreservespickupdelay, you should test the allowexpire pref first) So it is an (invisible) bug on its own. Test plan: See former patch. Kyle just discovered this bug, apparently by deleting the maxpickupdelay pref.. -- 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 9788] Improvements for calling GetReservesFromItemnumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788 --- Comment #10 from M. de Rooy m.de.r...@rijksmuseum.nl --- OK. I tested the following now: With patch 1 only (and deleted maxpickupdelay): Crash just like Kyle mentioned. With patch 2 applied too (still undef maxpickupdelay): No crash! So my assumption seems to be correct about the deleted pref :) Don't forget to restore the maxpickupdelay value if you should want to test this too.. -- 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 9788] Improvements for calling GetReservesFromItemnumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #16092|0 |1 is obsolete|| --- Comment #11 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19193 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19193action=edit Bug 9788: Improvements when calling GetReservesFromItemnumber Description: GetReservesFromItemnumber also returns waiting date. Simplifies some code. Improves item status display on catalogue detail, when placing a hold at opac-reserve and in staff, and on transfers to receive form. This patch builds on work from reports 9367 and 9761. Test plan: Place a future next-av. hold (enable future holds prefs), say 2 days ahead. Check item status on catalogue detail. Nothing to see. Enable ConfirmFutureHolds by inserting a number of days, say 2. Confirm earlier hold by checking it in. Look at item status again on detail. Switch to other opac user. Try to place a hold again. Check item status with item level hold info. Try to place hold in staff, check item level status. Make a transfer for that item. Switch branch. Look at transfers to receive. Signed-off-by: Kyle M Hall 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 9788] Improvements for calling GetReservesFromItemnumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788 Kyle M Hall k...@bywatersolutions.com 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 9788] Improvements for calling GetReservesFromItemnumber
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9788 Kyle M Hall k...@bywatersolutions.com changed: What|Removed |Added Attachment #19192|0 |1 is obsolete|| --- Comment #12 from Kyle M Hall k...@bywatersolutions.com --- Created attachment 19194 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19194action=edit Bug 9788: Followup for expirationdate in Letter.pm Pasting comment from the Bugzilla report: Looking bit longer at this code, it is kind of strange to find it there in the first place. Adding maxpickupdelay in Letters.pm should not be there, but it is.. Also this date is not used normally in the default HOLD Available for Pickup notice (that we are generating in this case). And if it would be undef, the expiration date should imo be empty instead of today+0. (before adding maxreservespickupdelay, you should test the allowexpire pref first) So it is an (invisible) bug on its own. Test plan: See former patch. Kyle just discovered this bug, apparently by deleting the maxpickupdelay pref.. Signed-off-by: Kyle M Hall 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 9770] C4::ClassSortRoutine::Dewey can pad the wrong part of a call number internally
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9770 --- Comment #3 from Jason Etheridge ja...@esilibrary.com --- Created attachment 19195 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19195action=edit patch for ClassSortRoutine_Dewey.t Here's the test to go with the first patch -- 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 M. de Rooy m.de.r...@rijksmuseum.nl changed: What|Removed |Added CC||mtomp...@hotmail.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 10454] Duplicate card numbers may be generated
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10454 M. Tompsett mtomp...@hotmail.com changed: What|Removed |Added Status|NEW |In Discussion --- Comment #4 from M. Tompsett mtomp...@hotmail.com --- Others have suggested last_insert_id. Is last_insert_id a good option? The DBI page has scary things like: Given all the caveats above, it's clear that this method must be used with care. And some of those are ugly caveats. I was thinking of generating an ID made of 4 parts which should be unique enough: 1) 16 character random string (A-Za-z0-9 character options). 2) process id padded to 6 digits 3) microsecond time padded to 20 digits 4) CGISESSID (or a 32 character random string if undefined). This, however, during testing created an every changing cardnumber when I just felt bored and clicked refresh on memberentry.pl So, I added a check for just the session id part to see if it is in borrowers. If not, then it would reuse it. Duplication should only happen on multi-tab stupidity, as far as I can tell. This got me thinking, do I need anything other that CGISESSID? Feedback appreciated. -- 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 #3 from M. Tompsett mtomp...@hotmail.com --- M. de Rooy, you use MySQL's LAST_INSERT_ID, which is not forward compatible with people who may be attempting to use a different back end, or working towards that. The next problem is code that calls something to get the next number without actually having put it into a table anywhere and then calling it again when someone refreshed. Do we really want such gaping holes in the sequences we store? Is the session id number, as stored in the CGISESSID cookie, unique enough, such that one could look for the session id to grab the sequence value to see if it is in the destination table, and if it is generate a new sequence number, otherwise reuse the one that is already pre-calculated? This is the situation I am pondering on the card number specific bug 10454. -- 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/
