[Bug 21264] New: Data inconsistencies - "Item type" and "item type for older issues" in subscriptions
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Bug ID: 21264 Summary: Data inconsistencies - "Item type" and "item type for older issues" in subscriptions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs@lists.koha-community.org Reporter: victor.grousset@biblibre.com QA Contact: testopia@bugs.koha-community.org CC: robin@catalyst.net.nz We should test for remains of bug 20461. Which will cause that more items (serial issues) will be created with an itype to NULL See the following for more details about the issue https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20461#c13 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Victor Grousset/tuxayo <victor.grousset@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |21010 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21010 [Bug 21010] Add a script to search for data inconsistencies -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Victor Grousset/tuxayo <victor.grousset@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |20461 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20461 [Bug 20461] New subscription form: "Item type" and "item type for older issues" fields are ignored -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Bug 21264 depends on bug 20461, which changed state. Bug 20461 Summary: New subscription form: "Item type" and "item type for older issues" fields are ignored https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20461 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Stable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Isn't this covered by bug 21591 / bug 21150 ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 --- Comment #2 from Victor Grousset/tuxayo <victor.grousset@biblibre.com> --- This issue is one of the causes of having invalid itype on items. So it would help having directly the root cause. We use a check for that: https://git.biblibre.com/biblibre/tools/src/commit/da516fdcd8a367047e1a5e5bd... The important par is this one: if [[ "$itype_on_item" ]] && # the syspref [[ "$makePreviousSerialAvailable" ]] && # another syspref [[ "$invalid_itemtypes_exists" || # subscription.itemtype "$invalid_previousitemtypes_exists" ]] # subscription.previousitemtype -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 --- Comment #3 from Victor Grousset/tuxayo <victor.grousset@biblibre.com> --- Maybe checking for subscription.itemtype isn't need. I haven't tested if the MARC frameworks usually doesn't let invalid values slip by. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 Emmi Takkinen <emmi.takkinen@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emmi.takkinen@koha-suomi.fi --- Comment #4 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- We are having problems with NULL values in subscription.previousitemtype column. When one receives multiple copies of a serial those NULL values attempt to create items with itype as NULL. Could we just make "item type for older issues" field mandatory? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Emmi Takkinen from comment #4)
We are having problems with NULL values in subscription.previousitemtype column. When one receives multiple copies of a serial those NULL values attempt to create items with itype as NULL.
Could we just make "item type for older issues" field mandatory?
I think our libraries would not all like that - why not correct the behavior and make the item type field mandatory on the item form? So if nothing is selected, the item can't be saved. That should already be the case but maybe it's not if the items can be created with null. I believe we have also seen that faulty behavior. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 --- Comment #6 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Katrin Fischer from comment #5)
(In reply to Emmi Takkinen from comment #4)
We are having problems with NULL values in subscription.previousitemtype column. When one receives multiple copies of a serial those NULL values attempt to create items with itype as NULL.
Could we just make "item type for older issues" field mandatory?
I think our libraries would not all like that - why not correct the behavior and make the item type field mandatory on the item form? So if nothing is selected, the item can't be saved. That should already be the case but maybe it's not if the items can be created with null. I believe we have also seen that faulty behavior.
All our item forms have mandatory itemtype field but this doesn't fix the problem completely. If syspref "makePreviousSerialAvailable" is enabled Koha tries to fill previous serials itype field with value from subscription.previousitemtype (code on serials-edit.pl lines 247-271) and if that value is NULL then we run into problems. Of course this wouldn't be an issue for us if we had same itemtype in both items.itype and biblioitems.itemtype columns and we could rely on Item->store to fill itype correctly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Emmi Takkinen from comment #6)
(In reply to Katrin Fischer from comment #5)
(In reply to Emmi Takkinen from comment #4)
We are having problems with NULL values in subscription.previousitemtype column. When one receives multiple copies of a serial those NULL values attempt to create items with itype as NULL.
Could we just make "item type for older issues" field mandatory?
I think our libraries would not all like that - why not correct the behavior and make the item type field mandatory on the item form? So if nothing is selected, the item can't be saved. That should already be the case but maybe it's not if the items can be created with null. I believe we have also seen that faulty behavior.
All our item forms have mandatory itemtype field but this doesn't fix the problem completely. If syspref "makePreviousSerialAvailable" is enabled Koha tries to fill previous serials itype field with value from subscription.previousitemtype (code on serials-edit.pl lines 247-271) and if that value is NULL then we run into problems.
Of course this wouldn't be an issue for us if we had same itemtype in both items.itype and biblioitems.itemtype columns and we could rely on Item->store to fill itype correctly.
I think the other solution would be to not activate the mechanism if the field is not set and keep the existing itemtype. That would only require a change to the logic and no data changes or similar. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 --- Comment #8 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Katrin Fischer from comment #7)
(In reply to Emmi Takkinen from comment #6)
(In reply to Katrin Fischer from comment #5)
(In reply to Emmi Takkinen from comment #4)
We are having problems with NULL values in subscription.previousitemtype column. When one receives multiple copies of a serial those NULL values attempt to create items with itype as NULL.
Could we just make "item type for older issues" field mandatory?
I think our libraries would not all like that - why not correct the behavior and make the item type field mandatory on the item form? So if nothing is selected, the item can't be saved. That should already be the case but maybe it's not if the items can be created with null. I believe we have also seen that faulty behavior.
All our item forms have mandatory itemtype field but this doesn't fix the problem completely. If syspref "makePreviousSerialAvailable" is enabled Koha tries to fill previous serials itype field with value from subscription.previousitemtype (code on serials-edit.pl lines 247-271) and if that value is NULL then we run into problems.
Of course this wouldn't be an issue for us if we had same itemtype in both items.itype and biblioitems.itemtype columns and we could rely on Item->store to fill itype correctly.
I think the other solution would be to not activate the mechanism if the field is not set and keep the existing itemtype. That would only require a change to the logic and no data changes or similar.
Hmm, that's probably the best solution and suitable for everyone. Maybe there could be a note next to "item type for older issues" field where we tell that if the field is not filled, existing itemtype is used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Emmi Takkinen from comment #8)
(In reply to Katrin Fischer from comment #7)
(In reply to Emmi Takkinen from comment #6)
(In reply to Katrin Fischer from comment #5)
(In reply to Emmi Takkinen from comment #4)
We are having problems with NULL values in subscription.previousitemtype column. When one receives multiple copies of a serial those NULL values attempt to create items with itype as NULL.
Could we just make "item type for older issues" field mandatory?
I think our libraries would not all like that - why not correct the behavior and make the item type field mandatory on the item form? So if nothing is selected, the item can't be saved. That should already be the case but maybe it's not if the items can be created with null. I believe we have also seen that faulty behavior.
All our item forms have mandatory itemtype field but this doesn't fix the problem completely. If syspref "makePreviousSerialAvailable" is enabled Koha tries to fill previous serials itype field with value from subscription.previousitemtype (code on serials-edit.pl lines 247-271) and if that value is NULL then we run into problems.
Of course this wouldn't be an issue for us if we had same itemtype in both items.itype and biblioitems.itemtype columns and we could rely on Item->store to fill itype correctly.
I think the other solution would be to not activate the mechanism if the field is not set and keep the existing itemtype. That would only require a change to the logic and no data changes or similar.
Hmm, that's probably the best solution and suitable for everyone. Maybe there could be a note next to "item type for older issues" field where we tell that if the field is not filled, existing itemtype is used.
Sounds good to me - could you file a separate bug? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21264 --- Comment #10 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Katrin Fischer from comment #9)
(In reply to Emmi Takkinen from comment #8)
(In reply to Katrin Fischer from comment #7)
(In reply to Emmi Takkinen from comment #6)
(In reply to Katrin Fischer from comment #5)
(In reply to Emmi Takkinen from comment #4)
We are having problems with NULL values in subscription.previousitemtype column. When one receives multiple copies of a serial those NULL values attempt to create items with itype as NULL.
Could we just make "item type for older issues" field mandatory?
I think our libraries would not all like that - why not correct the behavior and make the item type field mandatory on the item form? So if nothing is selected, the item can't be saved. That should already be the case but maybe it's not if the items can be created with null. I believe we have also seen that faulty behavior.
All our item forms have mandatory itemtype field but this doesn't fix the problem completely. If syspref "makePreviousSerialAvailable" is enabled Koha tries to fill previous serials itype field with value from subscription.previousitemtype (code on serials-edit.pl lines 247-271) and if that value is NULL then we run into problems.
Of course this wouldn't be an issue for us if we had same itemtype in both items.itype and biblioitems.itemtype columns and we could rely on Item->store to fill itype correctly.
I think the other solution would be to not activate the mechanism if the field is not set and keep the existing itemtype. That would only require a change to the logic and no data changes or similar.
Hmm, that's probably the best solution and suitable for everyone. Maybe there could be a note next to "item type for older issues" field where we tell that if the field is not filled, existing itemtype is used.
Sounds good to me - could you file a separate bug?
New bug 43239 created. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org