https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271 --- Comment #195 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #193)
Note for myself:
* comment 182
* comment 183
* comment 184
* deal with reports
This should be done using DB views. What is the 'deleted' column name we picked?
* my $item_object = Koha::Items->find({barcode => $barcode }); => We need to remove the barcode unique index
We need to rely on the DB to handle barcode uniqueness... we should move the barcode to another column, say... deleted_barcode.
* Prevent regression and deal with Koha::Items->find Koha::Items->search Ideas: - ->find returns only non-deleted items when ->find_deleted returns only deleted items - same for ->search, ->search_deleted
Or keep Koha::Old::Items that could inherit from Koha::Items
Or update all the occurrences (how many?)
On the API I would expect the endpoint to return non-deleted ones as default, and I would prefer to handle it explicitly: manually adding deleted => 0 to the query. And have ?include_deleted=true and/or ?deleted=true be mandatory to get the deleted ones. Maybe we could encapsulate this pattern in Koha::Objects::Deleted, which extended Koha::Objects with new generic methods: ->search_without_deleted I haven't made up my mind yet, but I feel it smells to have ->search have a weird behaviour other than the expected. I'm also worried how we would handle: my $items = $biblio->items; so it doesn't return deleted ones. -- You are receiving this mail because: You are watching all bug changes.