Bug 37569 - Serials without history cannot be edited
Summary: Serials without history cannot be edited
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Serials (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-05 13:17 UTC by Baptiste Wojtkowski (bwoj)
Modified: 2024-08-05 13:32 UTC (History)
0 users

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


Attachments
BZ37569: Fix the way serials are returned (1.63 KB, patch)
2024-08-05 13:29 UTC, Baptiste Wojtkowski (bwoj)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Baptiste Wojtkowski (bwoj) 2024-08-05 13:17:46 UTC
Serials cannot be edited if there is no history associated to the serial. Fetching a subscription matching a given serialnumber results in an hashref containing two fields named serial number. One of them is undef and is used by the form and is therefore not submitted at the end.

This is not supposed to happen since creating an exemplary automatically creates a new exemplary, but if serials are created through DB, they are not editable.
Comment 1 Katrin Fischer 2024-08-05 13:19:21 UTC
Hi Baptiste, if you create a subscription in Koha it always gets an entry in the history table. I'd say this is a data/migration issue?
It might be nice to make it more flexible, but then we'd need to make sure that the entry is generated as soon as it's needed.
Comment 2 Baptiste Wojtkowski (bwoj) 2024-08-05 13:29:01 UTC
Created attachment 170062 [details] [review]
BZ37569: Fix the way serials are returned

Serials cannot be edited if there is no history associated to the serial. Fetching a subscription matching a given serialnumber results in an hashref containing two fields named serial number. One of them is undef and is used by the form and is therefore not submitted at the end.

This is not supposed to happen since creating an exemplary automatically creates a new exemplary, but if serials are created through DB, they are not editable.

Test plan:
1 - Create a serial
2 - In the database remove there history associated with the serial
3 - Try and edit serial, at the end of the form, it will result in
  "serial not found"
4 - Apply patch
5 - Redo 3 and notice it now works
Comment 3 Baptiste Wojtkowski (bwoj) 2024-08-05 13:32:07 UTC
(In reply to Katrin Fischer from comment #1)
> Hi Baptiste, if you create a subscription in Koha it always gets an entry in
> the history table. I'd say this is a data/migration issue?
> It might be nice to make it more flexible, but then we'd need to make sure
> that the entry is generated as soon as it's needed.

Hi thanks for you answer ! You're right, the case is not supposed to happen, and when we meet it, it a migration issue, but koha's behaviour is quite weird in such a case, since everything seems to happen well until you try and save the duplicated serial.