serials: improvements when deleting an item

I am able to replicate this issue on our Evergreen 2.8 testing server.

In Serials control view --> delete a received copy -> Go back to OPAC view, the basic summary is not updated. When I expand the summary the deleted item is not listed

Summary shows as 2015: MAR - 2015:JUL
Expanded view shows 2015: MAR / 2015:APR / 2015:JUN / 2015:JUL
2015:MAY issue was deleted

Tested on web client 3.0.4.

An observation from testing serials in the web client:

When a serial item is deleted, the summary statement is not updated. However, if after deleting the item, another item attached to the subscription is received or reset, the summary method is updated to reflect all the changes. The same thing happens to any attached copy records; deleting the item does not delete the copy record, but the next time an item is received or reset, the copy record is deleted.

I also noticed that if an item is reset before deleting, the summary statement and copy records are updated correctly.

MassLNC is working with Catalyte to fix this bug along with another improvement - the deletion of linked entries in the asset.copy table at the same time the serial item is deleted. The full requirements for this project are available at http://masslnc.org/node/3383.

Since the proposed changes will be available in one branch, I'm going to update the title/description to cover the full feature.

I apologize for the bad timing, but we have a locally developed fix for the issues mentioned here. Given the pieces in place, the implementation is quite simple. I will make sure it is clean from any other local customizations and post a branch today.

(Our library has been without a full-time serials person for around 18 months, but a new person will finally start in two weeks, so we are investing time in serials again.)

Branch available here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1414197_serial_item_delete_improvements

working/user/dbwells/lp1414197_serial_item_delete_improvements

Please see the commit message for more information, but in brief, since "reset" already had the necessary brains to do everything needed, the delete code will now reset any received item before deleting it. This handles unit updates, unit/copy deletes, and summary changes.

Thanks Dan! My initial testing looks good, but I've asked some serials people to look at it more closely. If their testing comes back favorably, I'll sign off and merge the branch.

We found one issue with this branch. The problem occurs when there are two or more attached to one issuance.

If I delete the item belonging to the first stream added to this distribution, the issuance information will be removed from the summary statement even though there is still an undeleted item for that issuance. If I instead deleted an item from a later stream, the summary statement would continue to correctly show the issuance information. The problem only occurs if the item is deleted from that initial stream.

Everything else looks great!

Kathy, thanks for looking at this so quickly!

The behavior you are seeing reaches way back to the dawn of Evergreen serials. When I wrote some of original receiving code 8 (?!) (or so) years ago, I wrote into it the concept of a "primary" stream per distribution, and that holdings would reflect that stream only as "truth". There are even comments about adding a flag to sstream to allow designating a stream as primary, but that we would use the lowest stream ID "for now".

Trouble is, looking at the code today (and a few other times over the last year or two), I have no idea what exactly I was trying to accomplish. Best guess: there is no good reason to do this, and it was a moment of serials-related lunacy (common in those days).

I am happy to start pulling those weeds with the hope that I don't find anything attached to the other end. The question I'd ask now is whether we should push that onto this bug or let it be it's own follow-up bug. I'd prefer it be a follow-up based on the following:
1) This behavior actually has the potential to show up in many other situations (i.e. receiving a higher-id stream item will also not update the holdings in current Evergreen)
2) My suspicion is that it is somewhat rare for items to exist in different states within the same distribution (while being more common across distributions, which would not be affected by this, since streams are a per-distribution thing)

On the other hand, if we know of existing workflows where we expect to commonly delete only *some* items from a single distribution, we could certainly consider fixing this deeper problem as part of this bug after all. What do you think?

I agree with pushing what we have now and addressing the other issue in a follow-up bug.

In answer to #2, to be honest, I don't think we have many cases where libraries have two streams for a distribution. However, when they do, I'm guessing it's likely that they will be in different states if one copy goes missing or is lost by a patron. I can't say how frequently it would happen, but I'm guessing it happens fairly frequently with high-demand titles like Consumer Reports.

Adding my signoffs now.

Pushed to master, release 3.1 and release 3.0.

Thanks Dan!