Bug 20206 - Inventory: barcodes without or with extra leading zeroes are reported not found
Summary: Inventory: barcodes without or with extra leading zeroes are reported not found
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Marcel de Rooy
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-15 12:06 UTC by Marcel de Rooy
Modified: 2021-09-27 14:12 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 20206: Add leading zeroes in GetItemnumberFromBarcode (2.76 KB, patch)
2018-02-15 12:11 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 20206: Find barcodes with more or less leading zeroes (2.67 KB, patch)
2020-08-27 14:42 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 20206: Find barcodes with more or less leading zeroes (3.04 KB, patch)
2020-08-31 13:36 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 20206: Find barcodes with more or less leading zeroes (3.08 KB, patch)
2021-06-23 20:21 UTC, Hakam Almotlak
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2018-02-15 12:06:10 UTC
GetItemnumberFromBarcode will not find 51320 if it should be 051320.
Could we need that?
I noticed that Excel stripped leading zeroes and we got missing messages in Inventory.
Anyone interested in a patch like the attached one?
Comment 1 Marcel de Rooy 2018-02-15 12:11:19 UTC
Created attachment 71650 [details] [review]
Bug 20206: Add leading zeroes in GetItemnumberFromBarcode
Comment 2 Marcel de Rooy 2018-02-15 12:12:06 UTC
Not for NSO yet, awaiting feedback
Comment 3 Katrin Fischer 2018-02-15 12:21:01 UTC
I think we should look for an exact match, otherwise you might end up changing the wrong items and that seems too dangerous. Maybe it could be optional.
Comment 4 Marcel de Rooy 2018-02-15 12:48:08 UTC
(In reply to Katrin Fischer from comment #3)
> I think we should look for an exact match, otherwise you might end up
> changing the wrong items and that seems too dangerous. Maybe it could be
> optional.

Thx. But having both 51320 and 051320 seems dangerous to me too. Not sure if Koha should support that everywhere in the codebase..
Comment 5 Katrin Fischer 2018-02-15 15:50:34 UTC
I don't think it should be a problem where SQL is concerned and I don't think I have ever seen an issue reported related to this. I feel we should not try and limit options where it's not strictly necessary as libraries might be working with a weird mix of barcodes from migrations and even more so in consortia.
Comment 6 paxed 2018-02-19 08:07:23 UTC
Agree with Katrin and Marcel, this sounds dangerous - matching like this should always be done exactly. Perhaps some places have barcodes that would then match multiples, because some are longer or shorter.
Comment 7 Marcel de Rooy 2018-02-19 12:11:28 UTC
It sounds better to solve this in inventory only. Will keep it at custom level for now..
Comment 8 Marcel de Rooy 2020-08-27 13:28:09 UTC
(In reply to Marcel de Rooy from comment #7)
> It sounds better to solve this in inventory only. Will keep it at custom
> level for now..

A second try?
Comment 9 Marcel de Rooy 2020-08-27 13:30:06 UTC
(In reply to paxed from comment #6)
> Agree with Katrin and Marcel, this sounds dangerous - matching like this
> should always be done exactly. Perhaps some places have barcodes that would
> then match multiples, because some are longer or shorter.

If a system would contain barcode 1 and barcode 01 and we would just allow that, it would be more dangerous imo.
Comment 10 Marcel de Rooy 2020-08-27 14:42:05 UTC
Created attachment 109236 [details] [review]
Bug 20206: Find barcodes with more or less leading zeroes
Comment 11 Marcel de Rooy 2020-08-27 14:42:54 UTC
Bit unpolished yet, but the idea is if you find multiple barcodes, report them on inventory
Comment 12 Marcel de Rooy 2020-08-31 13:36:18 UTC
Created attachment 109369 [details] [review]
Bug 20206: Find barcodes with more or less leading zeroes

Test plan:
Pick an item, change barcode to e.g. 0123456
Create a barcode file with 123456. Run inventory with it. Should be found and modified.
Change barcode file by modifying 123456 to 00123456. Same result.
Change barcode of another item to 000123456.
Run inventory again on same barcode file: 0 modified, warn on duplicates?

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 13 Marcel de Rooy 2020-08-31 14:16:08 UTC
Note that we have the following problem locally: we have 0123 on the barcode but the RFID says 123. We have 0123 in the database. So scanning the barcode is not a problem (check in/out), but the RFID scanner gives 123 to inventory and that is a problem.
Comment 14 Marcel de Rooy 2020-08-31 14:16:25 UTC
If you scan a barcode 0123, the inventory tool will find the item too if it has barcode 123 or even 00123 in the database. But if it finds multiple barcodes with this pattern, it will report a duplicates error.

Would this behavior be problematic for a library? I strongly think that if you have such data (both barcode 123 as well as 0123 in your table), you should be warned about it and correct it. Obviously we can add a pref here, but do we want a pref to tolerate bad data?
Comment 15 Hakam Almotlak 2021-06-22 16:04:50 UTC
Hey i applied the patch and created an item with 0123456 then another item with 00123456 and i tried to check in with the code 123456 and it says no item with this code.
i checked the database and the code 0123456 and 00123456 exist in the database, but i can`t find it when i check in it does not exclude the zeros at the begging of the code.
that is the database output:

MariaDB [koha_master_dev_inlibro]> select barcode from items;
+----------+
| barcode  |
+----------+
| NULL     |
| 00123456 |
| 0123456  |
| 111      |
| 77777    |
| 88888    |
| 99999    |
+----------+
7 rows in set (0.001 sec)
Comment 16 Marcel de Rooy 2021-06-23 13:34:02 UTC
(In reply to Hakam Almotlak from comment #15)
> Hey i applied the patch and created an item with 0123456 then another item
> with 00123456 and i tried to check in with the code 123456 and it says no
> item with this code.
> i checked the database and the code 0123456 and 00123456 exist in the
> database, but i can`t find it when i check in it does not exclude the zeros
> at the begging of the code.

Hi Hakam,
Thx for testing.
This patch only deals with the Tools/Inventory program. So it does not include the regular checkin.
Please try the barcodes you created in the test plan of this patch with the tools/inventory script.
Comment 17 Hakam Almotlak 2021-06-23 20:20:20 UTC
thanks for the explaining i tested it and it works perfectly.
Comment 18 Hakam Almotlak 2021-06-23 20:21:25 UTC
Created attachment 122351 [details] [review]
Bug 20206: Find barcodes with more or less leading zeroes

Test plan:
Pick an item, change barcode to e.g. 0123456
Create a barcode file with 123456. Run inventory with it. Should be found and modified.
Change barcode file by modifying 123456 to 00123456. Same result.
Change barcode of another item to 000123456.
Run inventory again on same barcode file: 0 modified, warn on duplicates?

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: hakam <hakam@inlibro.com>
Comment 19 Hakam Almotlak 2021-06-23 20:22:00 UTC
thanks for the explaining i tested it and it works perfectly.
Comment 20 Kyle M Hall 2021-09-10 15:17:44 UTC
I can't see any way we can get this in without at least a syspref or some other way to make this optional. I'm also a bit concerned about the regex performance, but the syspref should take care of that for anyone not using the feature.
Comment 21 Marcel de Rooy 2021-09-10 19:55:55 UTC
(In reply to Kyle M Hall from comment #20)
> I can't see any way we can get this in without at least a syspref or some
> other way to make this optional. I'm also a bit concerned about the regex
> performance, but the syspref should take care of that for anyone not using
> the feature.

My first impression would be to just leave it here. Perhaps a plugin. Not sure for now. I wont add a pref probably. If there was more interest, people had their chance since 2018..
Comment 22 Marcel de Rooy 2021-09-27 14:12:43 UTC
Bye bye