https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20551
David Gustafsson <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #41 from David Gustafsson <[email protected]> --- (In reply to Katrin Fischer from comment #36) > > > > 5). There actually is a "deleteditems" table so I guess it would be possible > > to include these, even though it's hard to imagine why you would want to do > > this. Since the default is to include items perhaps it would be best to > > leave this as is and never include items for deleted biblios, or you will > > get more data than you probably want by default. It would also increase code > > complexity, probably with little benefit. If someone requests this it can be > > fixed later perhaps. Will point it out in the documentation that items are > > not included. > > I think introducing the export of deleted records and deleted items > separately would be a good idea. Let's start with this well defined feature > and think about the deleted items some more. > > While records have a flag to say "deleted", we don't have the same for > items. So we could start exporting deleted items that belonged to deleted > records, but what about other deleted items on existing records? How to > "mark" them as deleted? Now the tests are fixed. Regarding export of deleted items from a first glance I can see how you would expect this just as matter of symmetry with the regular export, but both conceptually and for lots of other reasons it makes no sense at all. 1. Exporting deleted records is probably never done to save the record information somewhere else, but to use data in records to match a record somewhere else to remove. I cannot imagine a case where this data would be found on an item-level. 2. It would require us to refactor C4::Biblio::EmbedItemsInMarcBiblio just for this specific case (which is an edge case that in practice will probably never be utilized), further increasing the burden of code maintenance and risk of introducing new bugs. If I'm incorrect and this feature is requested by many users it's always possible to implement later, but I would be very surprised if this turns out to be the case. -- 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/
