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?
Created attachment 71650 [details] [review] Bug 20206: Add leading zeroes in GetItemnumberFromBarcode
Not for NSO yet, awaiting feedback
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.
(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..
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.
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.
It sounds better to solve this in inventory only. Will keep it at custom level for now..
(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?
(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.
Created attachment 109236 [details] [review] Bug 20206: Find barcodes with more or less leading zeroes
Bit unpolished yet, but the idea is if you find multiple barcodes, report them on inventory
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>
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.
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?
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)
(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.
thanks for the explaining i tested it and it works perfectly.
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>
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.
(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..
Bye bye