Bug 20283 - Editing a course item for an inactive course affects the item fields directly
Summary: Editing a course item for an inactive course affects the item fields directly
Status: RESOLVED DUPLICATE of bug 23727
Alias: None
Product: Koha
Classification: Unclassified
Component: Course reserves (show other bugs)
Version: master
Hardware: All All
: P5 - low normal with 20 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-23 11:12 UTC by Nick Clemens
Modified: 2020-08-06 23:46 UTC (History)
7 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2018-02-23 11:12:29 UTC
When adding an item to course reserves the values in the items and course_items tables are swapped e.g. items.holdingbranch becomes course_items.holdingbranch and vice versa.

When a course is marked inactive, the values are swapped back.

When editing an inactive course we modify item values directly. This seems to be because we don't check if the course is active or not. When a course is active ti is correct to modify the items, but if inactive we should only modify course_items

To recreate:
1 - Find/create  an item with existing values for:
    item type
    collection code
    shelving location
    holding library
    staff/public note
2 - Add this item to an active course in course reserves, change all the values
3 - Make the course inactive
4 - Edit the course item, changing all the values
5 - Save and note the changes did not populate to the course reserve
6 - View the item, note the item was changed
7 - Edit the course again, note the dropdowns show the course item values, not the new item values

I think we have two options:
1 - Check if a course it active when modifiying a course reserve and adjust the correct table
2 - Don't allow editing of items for inactive courses
Comment 1 nchan 2018-07-06 22:44:40 UTC
I'm having the same issue.

Additionally, when deleting an inactive course that contains reserve items, the values that are normally changed when the course is marked "active" are changed permanently in the item record.

Course reserve class is inactive.
Item in the course reserve list has correct location, item type, and shelving location.
Course reserve class is deleted (due to inactivity).
Item that was listed in the course reserve list now has a location status of "reserves," item type of "reserve," and location is changed based on branch where the course reserves were held.

Switching the course to "active" before deleting the course also causes the same result.

This is pretty frustrating to go back and fix manually due to the number of items that may be in a course (and once the course is deleted, it may be hard to track down the original list).
Comment 2 Myka Kennedy Stephens 2018-10-08 08:20:31 UTC
Yes, this bug creates huge problems if one does not know it exists.

The only way I have figured out to avoid items being permanently changed to their course reserve status when a course is deleted or when an item is deleted from a course is to do the following:
1. Make sure the course being deleted is enabled
2. Edit the item being deleted from the course to leave everything unchanged
3. Delete the item from the course

This workaround probably requires the same amount of effort as manually changing each item back to its original status after deleting a course from course reserves. The better way to go is probably to note all the barcodes before deleting the course and then use the batch item modification tool after the fact.

Please find a fix for this bug! Thank you in advance.
Comment 3 Jonathan Druart 2018-10-09 19:20:17 UTC
I have tried to write a fix but I did not manage to write the tests. There is a lack of tests which makes new tests hard to write.
Comment 4 Myka Kennedy Stephens 2020-08-06 23:46:20 UTC
I'm not having trouble with this anymore and think it was resolved by bug 24772 and bug 23727. I cannot recreate the original issue.

Marking as resolved for now. Please feel free to reopen if I'm wrong and it's still a bug.

*** This bug has been marked as a duplicate of bug 23727 ***