Bug 13603 - autoBarcode setting hbyymmincr not taking month into account when looking up next increment
Summary: autoBarcode setting hbyymmincr not taking month into account when looking up ...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal (vote)
Assignee: Kyle M Hall
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-20 14:50 UTC by Kyle M Hall
Modified: 2015-12-03 22:03 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 13603 - autoBarcode setting hbyymmincr not taking month into account when looking up next increment (2.56 KB, patch)
2015-01-20 15:18 UTC, Kyle M Hall
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 13603 - autoBarcode setting hbyymmincr not taking month into account when looking up next increment (2.67 KB, patch)
2015-01-21 18:22 UTC, Kyle M Hall
Details | Diff | Splinter Review
[PASSED QA] Bug 13603 - autoBarcode setting hbyymmincr not taking month into account when looking up next increment (2.84 KB, patch)
2015-02-08 20:09 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2015-01-20 14:50:55 UTC
The hbyymmincr autoBarcode builder looks up all barcodes that begin with any number of letters ( the branchcode ) and a two-digit year directly afterward ( e.g. MPL15 ), then grabs the last four digits as the increment counter. The problem is, this does not take months into account, so unlike the description that says the system is limited to 10,000 items a month, it is limited to 10,000 items per *year*.

This situation can easily be corrected my adding the month into the lookup ( e.g. MPL1501 ).
Comment 1 Kyle M Hall 2015-01-20 15:18:11 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall 2015-01-21 18:22:26 UTC Comment hidden (obsolete)
Comment 3 Katrin Fischer 2015-01-28 10:09:02 UTC
I am not sure I understand this correctly, so feel free to correct:

I am concerned of changing the scheme and changing the total length while this might be in use as it is in libraries currently. As some libraries purchase preprinted barcode sheets, this could be really annoying.

Could we fix this differently?

Maybe we could fix the description and add a scheme with the month as a new option?
Comment 4 Katrin Fischer 2015-02-08 20:09:09 UTC
Created attachment 35734 [details] [review]
[PASSED QA] Bug 13603 - autoBarcode setting hbyymmincr not taking month into account when looking up next increment

The hbyymmincr autoBarcode builder looks up all barcodes that begin with
any number of letters ( the branchcode ) and a two-digit year directly
afterward ( e.g. MPL15 ), then grabs the last four digits as the
increment counter. The problem is, this does not take months into
account, so unlike the description that says the system is limited to
10,000 items a month, it is limited to 10,000 items per *year*.

This situation can easily be corrected my adding the month into the
lookup ( e.g. MPL1501 ).

Test Plan:
1) Enable autoBarcode, set to hbyymmincr
2) Catalog an item, let the barcode.pl plugin generate
   the next barcode.
3) Catalog an item with the barcode MPL15009999
4) Catalog another item, use the barcode.pl plugin to
   generate the next barcode.
5) Note the barcode is generated ends with '0001' instead of the
   correct increment
6) Apply this patch
7) Repeat step 4
8) Note the barcode now ends with the correct increment

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Jeanne Heicher <nppublib@pa.net>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Problem confirmed - the continuing number bit was not reset
to start counting from 1 again on the beginning of a new month.
Comment 5 Katrin Fischer 2015-02-08 20:10:47 UTC
After testing this I understand better - the problem is that the last bit of the number is not reset each month but keeps counting.

I feel ok about changing it now.
Comment 6 Tomás Cohen Arazi 2015-02-13 17:14:45 UTC
Patch pushed to master.

Thanks Kyle!
Comment 7 Chris Cormack 2015-02-14 08:28:34 UTC
Pushed to 3.18.x will be in 3.18.4
Comment 8 Mason James 2015-02-26 05:06:58 UTC
Pushed to 3.16.x, will be in 3.16.8