| Time |
Nick |
Message |
| 07:03 |
|
mrpeters joined #evergreen |
| 07:25 |
|
rjackson_isl joined #evergreen |
| 07:28 |
|
agoben joined #evergreen |
| 07:40 |
|
JBoyer joined #evergreen |
| 07:54 |
|
ericar joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:47 |
|
maryj joined #evergreen |
| 08:52 |
|
mrpeters joined #evergreen |
| 08:55 |
|
Dyrcona joined #evergreen |
| 09:01 |
|
bos20k joined #evergreen |
| 09:14 |
|
bos20k joined #evergreen |
| 09:16 |
|
collum joined #evergreen |
| 09:23 |
|
kmlussier joined #evergreen |
| 09:27 |
Bmagic |
@coffee yo |
| 09:27 |
* pinesol_green |
brews and pours a cup of Colombia Granja La Esperanza Geisha, and sends it sliding down the bar to yo |
| 09:33 |
Dyrcona |
Bmagic: We beat Hanabi last week, though you might say we cheated since we played until the players had no cards left to play. |
| 09:34 |
Dyrcona |
We also had two other games with 21 and 22 points. |
| 09:37 |
|
maryj_ joined #evergreen |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:17 |
Bmagic |
Dyrcona++ |
| 10:17 |
Bmagic |
That is a feat that I have yet to claim |
| 10:28 |
csharp |
we just bought hanabi for our beach trip last week (though I don't think anyone got around to playing it yet) :-) |
| 10:32 |
Bmagic |
csharp++ # The infection spreads |
| 11:01 |
|
mmorgan joined #evergreen |
| 11:26 |
|
mrpeters joined #evergreen |
| 11:35 |
|
Christineb joined #evergreen |
| 11:53 |
|
maryj joined #evergreen |
| 12:12 |
|
brahmina joined #evergreen |
| 12:13 |
|
jihpringle joined #evergreen |
| 12:40 |
|
mrpeters joined #evergreen |
| 12:46 |
Bmagic |
Anyone out there heard any stories like this one: sending an item in transit, then arriving but the copy is deleted in the database? |
| 12:47 |
Dyrcona |
Not that I recall, but it doesn't surprise me. |
| 12:48 |
Dyrcona |
You should probably toggle the flag on the In Transit copy status to prevent copy deletion and make sure that staff do not have the override for that. |
| 12:48 |
|
tater-laptop joined #evergreen |
| 12:48 |
csharp |
it happens when staff delete a batch of items from a bucket or something (iirc) |
| 12:48 |
Bmagic |
Another clue is that the copy had a status of Lost when it was put into transit |
| 12:49 |
csharp |
you can check auditor.asset_copy_history to verify |
| 12:49 |
Dyrcona |
So, a lost item that wasn't really lost, probably because it wasn't checked in properly. |
| 12:49 |
Bmagic |
csharp: yeah, I am looking at that table |
| 12:49 |
|
tater-laptop left #evergreen |
| 12:49 |
Dyrcona |
I'd also check asset.copy for duplicate barcodes. |
| 12:50 |
Bmagic |
Dyrcona: I checked that |
| 12:50 |
Bmagic |
Just one copy with that barcode |
| 12:50 |
Dyrcona |
Bmagic++ |
| 12:50 |
Bmagic |
Could the system delete the copy under this condition? |
| 12:50 |
csharp |
I think it can from a bucket deletion |
| 12:50 |
Dyrcona |
Yes, most definitely depending on circumstances. |
| 12:50 |
Bmagic |
Checking in a lost copy, triggered a transit and somehow the logic deleted the copy |
| 12:50 |
csharp |
that is to say, I have seen the issue you're seeing and that was the cause in the past |
| 12:51 |
Dyrcona |
Bmagic: Nope, as csharp says someone deleted the copy, either in a bucket or by itself. |
| 12:51 |
Dyrcona |
Nothing in Evergreen just deletes copies. |
| 12:51 |
Bmagic |
I am fishing for a system delete, not a human one |
| 12:51 |
Bmagic |
ok, just making sure! |
| 12:52 |
Bmagic |
I wouldn't think that Evergreen would delete copies out of the blue, but I could see, maybe, somehow it could if the conditions were just perfect |
| 12:52 |
csharp |
Bmagic: you might do a query for asset.copy where deleted and edit_date = <the timestamp from the copy in question> |
| 12:52 |
csharp |
it would show a batch if there was one |
| 12:53 |
* Dyrcona |
was thinking of suggesting that. csharp++ |
| 12:53 |
Bmagic |
reading auditor.asset_copy_history is confusing sometimes. The row there is the state of the row BEFORE the update. So, when I see deleted=true, I need to look at the timestamp on the row before that? |
| 12:53 |
Dyrcona |
Bmagic: Pretty much. The last line where deleted=false is the one that deleted it. |
| 12:54 |
Bmagic |
that was way back in 2015! |
| 12:54 |
Bmagic |
how in the world would the system allow it to be checked in and go into transit if it was deleted? |
| 12:54 |
Dyrcona |
It doesn't have to be checked in to go into transit. |
| 12:54 |
Bmagic |
perhaps there is a bug allowing deleted copies to be put in transit? |
| 12:54 |
Bmagic |
there is a transit slip |
| 12:54 |
Dyrcona |
Could have been a transit hanging around pre-deletion? |
| 12:55 |
Bmagic |
printed from the system |
| 12:55 |
csharp |
Bmagic: audit_time should be the same as the time of deletion/update |
| 12:55 |
Dyrcona |
Yes, there might be such a bug, but I haven't looked lately. |
| 12:55 |
Bmagic |
the transit clearly says 7-18-2016 |
| 12:55 |
Bmagic |
and the copy was recorded deleted "2015-04-10 10:30:01.518181-05" |
| 12:55 |
Dyrcona |
It would be easier to delete it after it went into transit than for it to go into transit after being deleted. |
| 12:56 |
Dyrcona |
Well, that sounds like a bug. |
| 12:56 |
csharp |
Bmagic: I can verify that transit slip printing is squirrely around those situations too |
| 12:56 |
Bmagic |
hmmm |
| 12:56 |
Dyrcona |
Is the transit still there? What are its dates? |
| 12:56 |
Bmagic |
perhaps the combination of it being status lost, and deleted, and wanting to go to a different branch |
| 12:56 |
Bmagic |
yes, the transit row is there in the db |
| 12:57 |
Bmagic |
with a source send time and no receive time |
| 12:57 |
Dyrcona |
Sounds right, it couldn't be checked in to receive the transit because it is deleted. |
| 12:57 |
Bmagic |
yep, it won't allow checkin at the destination |
| 12:57 |
Bmagic |
so, bug then? |
| 12:58 |
Dyrcona |
Well, the bug would be that a deleted copy was able to go into transit, I guess. |
| 12:58 |
Bmagic |
yeah, that is what I am thinking |
| 12:58 |
csharp |
is the source_send_time earlier than the deletion? |
| 12:59 |
Bmagic |
csharp: no, it was deleted april of 2015, and put in transit last week |
| 12:59 |
csharp |
weird |
| 12:59 |
Bmagic |
very |
| 12:59 |
Bmagic |
Confusing for the libraries for sure |
| 13:00 |
mmorgan |
Bmagic: Maybe the item was checked in from the patron record? |
| 13:00 |
Bmagic |
and me! |
| 13:00 |
Dyrcona |
mmorgan++ |
| 13:00 |
Bmagic |
mmorgan: different logic there? |
| 13:00 |
Dyrcona |
That's probably it. The only way to checkin a deleted copy that I know. |
| 13:00 |
Bmagic |
you can't just scan the barcode into the checkin box? |
| 13:00 |
mmorgan |
Item was lost in 2015. Patron showed up with item. Staff looked up patron. Selected item on patron record and chose Check in/ |
| 13:00 |
csharp |
another rule of thumb I've learned from this sort of situation - it was almost certainly created by staff actions |
| 13:01 |
Dyrcona |
Bmagic: Not different logic as far as transits go. |
| 13:01 |
bshum |
Or they were just clearing the item off the record cause the patron claimed they returned it. |
| 13:01 |
mmorgan |
Bmagic: A deleted item won't be found when scanned in the checkin box. |
| 13:01 |
Bmagic |
but somehow the fact that it's deleted is overlooked when using the patron javascript? |
| 13:01 |
Dyrcona |
Bmagic: Not exactly. |
| 13:02 |
Bmagic |
It still sounds like a bug to me |
| 13:02 |
Dyrcona |
Deleted items show up in items out. If you right click to checkin from the menu, no checks are done on the barcode, etc. |
| 13:03 |
Dyrcona |
When you enter a barcode into the normal checkin box, the copy is looked up by barcode. That lookup will fail on deleted copies. |
| 13:03 |
Dyrcona |
The real bug is letting staff delete copies that are charged to a patron account. |
| 13:04 |
* mmorgan |
would like to see a way to look up a deleted item in the staff client by barcode. |
| 13:04 |
Dyrcona |
Scroll back up to my second comment on this discussion. :) |
| 13:04 |
Dyrcona |
mmorgan: The only problem with that is you will get more than one copy in some cases, and some interfaces can't handle that. |
| 13:05 |
Dyrcona |
Barcodes on deleted items are excluded from the uniqueness checks. |
| 13:06 |
mmorgan |
Okay, but maybe if there were a way to look up a deleted item, we wouldn't end up with more than one copy with the same barcode. |
| 13:07 |
* Dyrcona |
doubts given past experience. ;) |
| 13:07 |
Dyrcona |
Missing "it" in there. |
| 13:07 |
bshum |
mmorgan: Except there are cases where libraries reuse barcodes for temporary items or ILLs |
| 13:08 |
bshum |
So there might be dozens or hundreds of dupe barcode entries, being deleted and reused over and over |
| 13:08 |
bshum |
So I also doubt "it" |
| 13:09 |
mmorgan |
Yes, good point. There are certainly legitimate cases for reusing a barcode. Not suggesting that deleted items should *always* be retrieved. |
| 13:09 |
Dyrcona |
Actually, IIRC, checkin from items out uses the copy id and not the barcode, which is why no checks are done for deletion, etc. |
| 13:09 |
bshum |
We could add some sort of warning maybe to that check if used from the patron out |
| 13:09 |
Dyrcona |
Maybe a check box or option on item status to include deleted items. |
| 13:10 |
bshum |
And have it say something like, "this item is deleted", but checking it in will still do weird stuff if the item was in an incomplete status |
| 13:10 |
mmorgan |
It would be useful for staff to have A way to link a deleted item to a patron. Right now they have none if the item is returned anonymously. |
| 13:10 |
bshum |
So no matter what, you'll end up with a problem. Especially too if the barcode was re-used, so you can't just undelete the item too |
| 13:11 |
Dyrcona |
Deleted items show up in items out, but right, they'd have to know the patron in advance. |
| 13:12 |
mmorgan |
Dyrcona: An option on item status would be good. That way, they'd be able to find the patron. |
| 13:15 |
mmorgan |
bshum: In many cases you wouldn't be able to undelete the item, but giving staff a way to see if a barcode they have in hand was deleted can avoid a lot of confusion. |
| 13:15 |
* Dyrcona |
agrees with the latter half of that statement. |
| 13:16 |
* mmorgan |
has had many a conversation with confused staff members, trying to check in a barcode and it won't come off the patron's record. |
| 13:16 |
Dyrcona |
I did come up with a utility that catalogers at MVLC could use to undelete copies by barcode, but it is rather crude and won't undelete certain things, such as precats. |
| 13:16 |
mmorgan |
I'm sure others have had those conversations, too. |
| 13:16 |
Dyrcona |
Oh, yes, definitely. |
| 13:17 |
jeff |
we treat "deleted item with open circulation" as an anomaly that is reported on and dealt with. |
| 13:17 |
jeff |
similar to "item with open circ but Available status" |
| 13:17 |
Dyrcona |
And having that same conversation multiple times with the same staff caused the implementation of the flag on copy status to be developed. :) |
| 13:18 |
Dyrcona |
jeff: Those are good ideas. |
| 13:19 |
jeff |
the latter report today has three items on it: two with stop_fines of CLAIMSRETURNED, one NCIP-related. |
| 13:20 |
Dyrcona |
That sounds like "fun." |
| 13:21 |
mmorgan |
Another thing that adds to the confusion here. From Items out, choosing Item details retrieves based on barcode. |
| 13:22 |
mmorgan |
So when the barcode has been reused, you get details on the current copy, not the deleted one. |
| 13:25 |
mmorgan |
jeff++ |
| 13:25 |
mmorgan |
good ideas for regular reports. |
| 13:33 |
jeff |
we're also moving away from freeform entries for some stat cats, but haven't changed the setting yet. in the meantime, we do report when we have a non-standard entry there as well. |
| 13:34 |
jeff |
trying to think if we have other examples. i could check the scheduled reports to see what runs that i've forgotten about because there haven't been any results in a while. |
| 13:46 |
|
gsams_ joined #evergreen |
| 14:14 |
|
ericar joined #evergreen |
| 16:10 |
JBoyer |
Dyrcona, you still around? |
| 16:11 |
Dyrcona |
Yes. |
| 16:14 |
* Dyrcona |
worries that JBoyer has a very long question.... |
| 16:14 |
JBoyer |
Not long, but not good. |
| 16:15 |
JBoyer |
NCIPServer doesn't appear to care about password validity, is that known or am I screwing something up? |
| 16:15 |
Dyrcona |
That's known. |
| 16:15 |
JBoyer |
Ok. |
| 16:15 |
Dyrcona |
You could always add that as a feature. :) |
| 16:17 |
JBoyer |
I'm planning to, but the next issue is that if you put a "proper" password (including symbols, say). into SHAREit, it drops everything including and after any character it doesn't like and then just reloads the login window because REASONS. |
| 16:17 |
JBoyer |
I know that's on AG, I just wanted to vent. |
| 16:18 |
Dyrcona |
Right. There are other reasons that NCIPServer doesn't check passwords. |
| 16:18 |
JBoyer |
If I put my actual password in, I can't login; if I enter something like 12345 or "hootenanny" I'm in not problem. |
| 16:18 |
Dyrcona |
Sounds about right. |
| 16:19 |
Dyrcona |
I think, but I'm not sure, that you can ask them (AG) to not ask for passwords. |
| 16:19 |
JBoyer |
I'll see if I can get them to do anything about it because holy crap, but I just wanted to make sure I wasn't missing anything important. I guess if I can get this added I'll have to make it a setting in case others have a similar choice to make. :-/ |
| 16:19 |
Dyrcona |
I thought it was a configuration option that they can do per NCIP remote or whatever. |
| 16:20 |
JBoyer |
Thanks for the time, I'll start yelling their way. (and I probably will see about turning passwords off, given their abysmal alternative...) |
| 16:20 |
Dyrcona |
Yeah...I'd put in the <patrons> section. |
| 16:21 |
Dyrcona |
I could see it being a big problem if they don't properly encode & or some other characters. |
| 16:23 |
JBoyer |
That sounds like the most likely problem to pop up first, yeah. |
| 16:24 |
JBoyer |
If they would just send the MD5 that would be ideal. Even if it didn't work for any other system it's not like it would be worse than it is now. |
| 16:24 |
Dyrcona |
Well, that's all changed recently on the Evergreen side. Not so sure that you want them sending MD5s, anyway. |
| 16:25 |
Dyrcona |
And, nobody uses client authentication with NCIP2, because certificates. |
| 16:33 |
JBoyer |
I figured as far as Evergreen goes you could still use the MD5 as a starting point since that's what the passwords in-db are before the security upgrade. Not sure yet. I know I'd rather they try to send MD5 than properly XML encode anything. |
| 16:34 |
JBoyer |
re: certificates, do you mean in the https sense, or the sort-of-ssh-esque sense? |
| 16:34 |
JBoyer |
ssh-key kind of thing, that is. |
| 16:35 |
Dyrcona |
Like the ones used for https, you insert the certificate data into the authentication block. |
| 16:35 |
Dyrcona |
I forget the tag names, but could look it up. |
| 16:39 |
jeff |
that sounds depressing. |
| 16:39 |
jeff |
do you control the AG system, or does another organization? |
| 16:40 |
JBoyer |
jeff, it's entirely hosted. We have control as in say-so, but not how it works internally. |
| 16:42 |
JBoyer |
Dyrcona, that sounds like the worst thing to set up for the general public. (Handy for machine to machine work, though.) |
| 16:42 |
Dyrcona |
It is meant for machine to machine. |
| 16:44 |
Dyrcona |
In this case "client" is the NCIP client. |
| 16:44 |
JBoyer |
Oh, I follow now. |
| 16:47 |
Dyrcona |
! JBoyer: Yep, I knew that, too. :) |
| 16:48 |
JBoyer |
Dyrcona, in your case I thought it wouldn't work and you told them to go http only, I specified https and never heard anything about it (until I noticed that my testing server LE cert expired 3 months ago...) |
| 16:48 |
Dyrcona |
I guess you don't have to use certificates, but I swear I saw them mentioned in the standard somewhere. |
| 16:48 |
JBoyer |
I suppose you could do almost anything that both ends agree on, maybe it was in a draft or mailing list? |
| 16:48 |
Dyrcona |
Hmm..... |
| 16:49 |
Dyrcona |
Y'know. I think they got SSL working... I don't recall if we had it configured for both SSL and non-SSL at MVLC. |
| 16:50 |
Dyrcona |
I know it failed the first time that they tried it with our wildcard cert. |
| 16:51 |
Dyrcona |
So, ! doesn't work. |
| 16:51 |
Dyrcona |
:) |
| 16:52 |
Dyrcona |
They may not properly check certificates. |
| 16:54 |
Dyrcona |
Anyway, the fields are SystemAuthentication and AgencyAuthentication. |
| 16:56 |
Dyrcona |
Well, FromSystemAuthentication and FromAgencyAuthentication to be absolutely correct. :) |
| 17:01 |
Dyrcona |
So long everybody! I'll be back tomorrow. |
| 17:04 |
jeff |
well, that got MORE depressing pretty quickly. |
| 17:06 |
|
mmorgan left #evergreen |
| 17:18 |
berick |
@weather 27712 |
| 17:18 |
pinesol_green |
berick: Durham, NC :: Mostly Cloudy :: 82F/28C | Heat Index: 87F/31C | Monday: Partly cloudy. Lows overnight in the mid 70s. Monday Night: Some clouds. Low 76F. Winds SSW at 5 to 10 mph. | Updated: 15m ago |
| 17:19 |
berick |
huh, google thinks it's 11 degrees hotter right now. |
| 17:19 |
gsams_ |
@weather 76262 |
| 17:19 |
pinesol_green |
gsams_: Roanoke, TX :: Mostly Cloudy :: 97F/36C | Heat Index: 105F/40C | Monday: Partly cloudy. Lows overnight in the upper 70s. Monday Night: A stray shower or thunderstorm is possible early. A few clouds. Low 77F. Winds ESE at 10 to 15 mph. | Updated: 19m ago |
| 17:20 |
gsams_ |
huh, could of sworn it was just a few degree shy of standing on the sun a minute ago... |
| 17:22 |
gsams_ |
I'm actually even more surprised we've only had 3 100+ degree days this month |
| 17:39 |
jeff |
@weather ktvc |
| 17:39 |
pinesol_green |
jeff: Cherry Capital, MI :: Scattered Clouds :: 83F/28C | Heat Index: 83F/28C | Monday: Mainly clear. Lows overnight in the low 60s. Monday Night: A clear sky. Low 62F. Winds NW at 10 to 15 mph, becoming SW and decreasing to less than 5 mph. | Updated: 46m ago |
| 18:54 |
|
gsams joined #evergreen |
| 20:22 |
|
dcook joined #evergreen |
