status_changed_time can go back in time

The attached patch should prevent updates from applying an older status_changed_time than the existing value.

Missed colon in the assignment in the previous patch!

Thinko in previous patch. We only want to keep the old time if we're not resetting it to now().

Have you looked at this?

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=4b94821578792b6494278672f6d8d3a4f9c0b4cc

Which is part of another bug:

https://bugs.launchpad.net/evergreen/+bug/1220389

I don't want to see either of us wasting effort.

I should add that the point of the branch and bug that I added above are so that the status_changed time can go back in time.

I will see if I can reproduce the behavior reported by Bill in current master when I get a chance, which may mean never.

Further investigation leads me to believe that the better fix is to alter the code where the stale copy object is used so that it's status_changed_time is updated before the database representation is updated.

I hadn't caught your change for bug 1220389. However, that wouldn't apply in this case, as the status is not changing. The copy floats after the check-in, so the NEW and OLD are both effectively 7, bailing immediately from the IF.

Refreshing the object prior to updating would be an option, although it requires another call to pull the data, and it leaves me with the question, is this the only place this phenomenon can occur?

Because this case is unique, in that it occurs when statuses are not really changing, it could coexist with your proposed change to the function.

Hello, I just ran into this issue with EG 2.10.6.

I can replicate it by doing a checkout without checkin. Checking out an item that is currently checked out, to someone else without checking it in first.

I noticed this because we were looking for issues with the reshelving complete script, where items go from checked out -> reshelving -> checked out -> available. In a few cases (3) when the reshelving complete script was run at the same time as the no-op checkin, the reshelving complete script grabbed the item because of the status_change_time being set back to the last checkout date.

So I can get it to trigger in two cases. Floating to a different branch, or doing a no-op checkin at the same branch.

Josh

Looking at this I agree with Jason that looking at the stale copy object is probably the better approach here. I'm assigning this to myself for now. I'm not sure I'll have time this week to look at it more but it doesn't appear to be a major point given the lack of activity on it.