https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271
--- Comment #195 from Tomás Cohen Arazi <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
