---- Reported by firstname.lastname@example.org 2010-01-26 17:11:12 ----
Pictures really say it here:
An item with dual statuses: http://screencast.com/t/YTk3ZGU2N2Qt
Another item with dual statuses: http://screencast.com/t/NDU3YjQ3M
Both of these items do have outstanding holds on them, that probably should have been triggered by going through the chute.
I will try to get more examples and more thorough documentation of what exactly is happening to these items.
We are using the NEKLS sponsored SIP2 code from LL with no further patches. This is not LEK. KF (irc) says she has also seen this issue, perhaps she can comment more.
---- Additional Comments From email@example.com 2010-01-26 18:31:57 ----
Ah, I should mention that this may be related to returns that don't get processed correctly/completely: the return code may not be completing before the SIP gets it's response.
Others have had issues with items checked in through the web interface presenting the "it's checked in" message when the item has not been actually returned. This seems to occur more frequently during busy times.
This is mostly speculation, though, so take that for what you will.
---- Additional Comments From firstname.lastname@example.org 2010-02-01 09:08:09 ----
Our library uses self check machines for issueing and returning items.
I have seen an item with status available and checked out once during testing.
I m not sure which version we were using and was not able to reproduce the behaviour - so I am not much help here.
Not sure how to check our database for such items either.
---- Additional Comments From email@example.com 2010-02-01 10:58:18 ----
If anyone encounters an example in the wild it would be interesting if they could check in which screens the duplicate status occurs. Some templates have about eighty+ lines to work out the status so it's not surprising if it is sometimes wrong.
---- Additional Comments From firstname.lastname@example.org 2010-02-04 19:45:03 ----
We see this in the intranet, on detail.pl and moredetail.pl, if that helps.
---- Additional Comments From email@example.com 2010-02-11 17:06:46 ----
OPAC statuses are correct in every case we've seen.
--- Bug imported by firstname.lastname@example.org 2010-05-21 01:22 UTC ---
This bug was previously known as _bug_ 4063 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4063
Actual time not defined. Setting to 0.0
CC member email@example.com does not have an account here
i have not been seeing this issue for a while - closing this ticket for now.