| Time |
Nick |
Message |
| 00:01 |
|
StomproJ joined #evergreen |
| 01:00 |
|
Mark__T joined #evergreen |
| 07:47 |
|
mrpeters joined #evergreen |
| 07:53 |
|
ericar joined #evergreen |
| 07:55 |
|
rjackson_isl joined #evergreen |
| 07:59 |
|
collum joined #evergreen |
| 07:59 |
|
rlefaive joined #evergreen |
| 08:16 |
|
Shae joined #evergreen |
| 08:20 |
|
Shae joined #evergreen |
| 08:29 |
|
Dyrcona joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:59 |
|
jwoodard joined #evergreen |
| 09:02 |
|
RoganH joined #evergreen |
| 09:24 |
|
yboston joined #evergreen |
| 09:28 |
|
maryj joined #evergreen |
| 09:32 |
kmlussier |
Oh, wow, I didn't even remember filing bug 1464767. I'm glad to see the bugs I submit to LP are consistent with the ones I submit to ESI. :) |
| 09:32 |
pinesol_green |
Launchpad bug 1464767 in Evergreen "OU selectors in web client do not provide scrollbars and are ordered incorrectly" [Medium,New] https://launchpad.net/bugs/1464767 |
| 09:34 |
gmcharlt |
kmlussier: https://youtu.be/pWS8Mg-JWSg?t=81 |
| 09:36 |
kmlussier |
Every morning should start off with a Monty Python clip. |
| 09:39 |
|
Callender joined #evergreen |
| 09:47 |
Dyrcona |
Heh. Sixteen lines of commit message for changing basically two words in the code. |
| 09:48 |
|
Callender_ joined #evergreen |
| 10:07 |
* jeff |
piles on bug 1503903 |
| 10:07 |
pinesol_green |
Launchpad bug 1503903 in Evergreen "Rollback on shelfcheck (3M, etc.) triggers holds?" [Undecided,New] https://launchpad.net/bugs/1503903 |
| 10:09 |
mmorgan |
*Sigh* Just discovered that barcodes 0, 3, 4, 6, and 8 are precataloged items in our system. Again. :-( |
| 10:11 |
tsbere |
mmorgan: We appear to have -, ., 2, 7, 8, 9, S, and u on the "single char barcodes" front right now. :( |
| 10:14 |
mmorgan |
We also have \ and a. |
| 10:17 |
mmorgan |
Both . and 0 have been precat items and have been deleted 8 times. They keep coming back :-( |
| 10:18 |
* mmorgan |
is afraid to look for more short barcodes. |
| 10:19 |
tsbere |
Most of our single-chars have only come up a couple of times, though 3 has apparently come up 8 times. >_> |
| 10:20 |
|
Sessions1024 joined #evergreen |
| 10:21 |
jeff |
Do you follow up with staff at the libraries in question the following day, so that they can be aware of the issue? |
| 10:21 |
jeff |
Do you all use precats normally, or would you disable their use completely if you could? |
| 10:23 |
mmorgan |
We don't check for these daily, perhaps we should. We do use precats when a patron presents an uncataloged item for checkout. |
| 10:24 |
jeff |
Is that normally because it's a new item, not fully processed -- or because it's an item that was lost in migration or something? |
| 10:25 |
jeff |
greetings, Sessions1024 |
| 10:26 |
* tsbere |
doesn't normally check for these either, and has no clue how many legitimate pre-cats get used, but knows that bib -1 is in the top 10 for circ counts |
| 10:27 |
mmorgan |
It can be a new item that didn't get processed correctly, more commonly, they're items that were either deleted because they were missing, or lost deleted items that found their way back to the shelves. |
| 10:28 |
mmorgan |
jeff: Do you have a process for following up with libraries on these daily? |
| 10:30 |
* mmorgan |
is experiencing deja-vu. http://irc.evergreen-ils.org/evergreen/2015-04-06#i_168240 |
| 10:33 |
|
Christineb joined #evergreen |
| 10:40 |
jeff |
mmorgan: not at present. it isn't a problem for us at this point. |
| 10:40 |
jeff |
mmorgan: if we needed, i'd probably use either a script or a jasper report that generated an email to appropriate folk who could then contact the library in question. |
| 10:41 |
jeff |
idea being to help resolve the underlying issue rather than whack-a-mole the precat copies. |
| 10:41 |
jeff |
adding minimum requirements or enforcing something like strict barcode would be another tool, but might not be worth the added effort. |
| 10:43 |
mmorgan |
+1 to resolving the underlying issue. |
| 10:46 |
mmorgan |
jeff: Is it not a problem for you because your staff users just don't click to accept the barcode? Or do you not have much in the way of misscans? |
| 10:46 |
jeff |
sorry, got a little preachy there. :-) |
| 10:47 |
mmorgan |
NP, didn't see it as preachy. |
| 10:50 |
jeff |
looks like we've had one mis-scan this month that resulted in a precat being created where it probably shouldn't have been a pre-cat. |
| 10:51 |
jeff |
last month, zero. in august, two. |
| 10:51 |
jeff |
(i hadn't looked recently, so i just looked) |
| 10:52 |
jeff |
it's on my list to have a frequent report of pre-cat items that haven't been turned into real items yet, but other things are currently higher on the list. |
| 10:52 |
jeff |
similar to "these are the recommended cron jobs", i'd be interested in "things you should probably report on and keep under control" |
| 10:53 |
mmorgan |
jeff: IIRC, you don't have much staff mediated checkout, is that right? Most is self check? |
| 10:53 |
jeff |
correct. |
| 10:54 |
mmorgan |
ok. |
| 10:55 |
mmorgan |
Most of our circ is done by staff, so there's more opportunity to accept a bad barcode. |
| 10:55 |
jeff |
though it's worth considering that we have selfcheck at only one branch. |
| 10:56 |
mmorgan |
Hmm. True. |
| 11:02 |
* mmorgan |
makes a note to look at the whole bad barcode/misscan/precat thing in the web client. |
| 11:04 |
|
vlewis joined #evergreen |
| 11:04 |
|
vlewis_ joined #evergreen |
| 11:25 |
rjackson_isl |
flying solo this week and have an easy question: Changed the email address on a branch and the Contact Information still lists the old email address. Do I need to run autogen to effect the change? |
| 11:28 |
rjackson_isl |
this is on 2.7.2 |
| 11:28 |
bshum |
rjackson_isl: When you say "Contact Information" is that for the catalog when you click on a given library? |
| 11:29 |
bshum |
I wouldn't have thought an autogen would be required to affect those sorts of changes (I think of autogen mainly when there's an actual new org unit or alteration to the structure of the org units) |
| 11:29 |
bshum |
But maybe it's being cached |
| 11:29 |
rjackson_isl |
bshum: if I query advanced by that site, select the item then select the link for the library the Contact Infomratrion is shown |
| 11:29 |
bshum |
And you need to do an apache reload or something. |
| 11:30 |
bshum |
rjackson_isl: Gotcha, we're thinking of the same place, cool. |
| 11:30 |
rjackson_isl |
yeah - Jason has a handy dandy restart all script but wasn't sure if I needed that on all 9 bricks or a autogen then that |
| 11:30 |
|
dMiller_ joined #evergreen |
| 11:30 |
rjackson_isl |
think I will try the restart - bshum++ |
| 11:53 |
|
bmills joined #evergreen |
| 11:59 |
jeff |
rjackson_isl: where did you adjust the email address? |
| 12:02 |
jeff |
in actor.org_unit, or... wait, I guess that's it for org emails, outside of A/T. |
| 12:05 |
dbs |
The library info pages make use of caching via memcached |
| 12:05 |
jeff |
TPAC_aou_address_cache_$lib_id as a key |
| 12:05 |
jeff |
you probably don't want to restart memcached, so consider either 1) waiting for the cache to time out, or 2) removing the key with memcrm |
| 12:06 |
jeff |
and 3) we should consider more cache invalidation when we know that we've likely changed something. |
| 12:07 |
jeff |
er, wrong key. |
| 12:11 |
jeff |
and... hrm. |
| 12:12 |
|
sandbergja joined #evergreen |
| 12:14 |
jeff |
i think only address and hours of operation are cached in memcached. the aou entry (including email) would be cached by nature of the autogenerated ctx.get_aou sub, which (i think) maintains an in-process cache, not within memcached. |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:27 |
rjackson_isl |
jeff++ the restart of services on the 9 bricks reloaded it for me. It is set up to do one at a time and doesn't cause any pain to the community in general |
| 12:52 |
|
dMiller_ joined #evergreen |
| 13:58 |
rjackson_isl |
Help (again today...) library accidentally did a CLAIMSNEVERCHECKEDOUT instead of a Renew for 21 items. Items are in the patrons hands. Can I update the action.circulation entries to repair these circs and allow for a renewal or will I be making a bigger mess doing so? |
| 14:01 |
jeff |
gut reaction is: if you have the barcodes i'd suggest staff at that library check them back out to the patron. |
| 14:02 |
jeff |
they'll possibly need to override the copies being in a bad status. |
| 14:02 |
jeff |
and "try not to do that again" ;-) |
| 14:02 |
rjackson_isl |
sounds good to me - was just getting ready to review the triggers on action.circulation and figured that was bad news :( |
| 14:03 |
Dyrcona |
you could probably fix it. It isn't as simple as just changin the stop_fines on the circulations, though. |
| 14:03 |
Dyrcona |
Probably better to just have them do what jeff suggests. |
| 14:03 |
jeff |
the number of columns needing updating in at least two tables is more than the half-dozen or so i just started thinking of. |
| 14:04 |
Dyrcona |
jeff: yes, not simple, like I said. |
| 14:04 |
rjackson_isl |
I think a little pain on the library might be in order here! ;) |
| 14:04 |
jeff |
Dyrcona: yup, i think we're in agreement there. :-) |
| 14:04 |
rjackson_isl |
thanks! |
| 14:04 |
Dyrcona |
Yes, pain and the avoidance thereof can be an effective learning tool. |
| 14:22 |
|
dMiller_ joined #evergreen |
| 14:29 |
kmlussier |
Is work being done on webby ATM? |
| 14:30 |
kmlussier |
The admin login stopped working for me, but other logins are working. |
| 14:30 |
kmlussier |
That's my sign that it's time for a break. |
| 14:32 |
Dyrcona |
Mine, too. :) |
| 15:37 |
gmcharlt |
kmlussier: Dyrcona: hmm, works for me |
| 15:46 |
|
Callender_ joined #evergreen |
| 15:47 |
Dyrcona |
I'm not trying webby, anyway. Just thought it was a good time for a break. :) |
| 15:47 |
* Dyrcona |
is trying to untangle some convoluted logic written over a year ago by himself. |
| 15:48 |
kmlussier |
NCIP? |
| 15:48 |
kmlussier |
The login worked for me as soon as I got back from my walk. |
| 15:49 |
Dyrcona |
See taking a walk solves most problems. |
| 15:49 |
Dyrcona |
Yes, it is NCIP. |
| 15:49 |
Dyrcona |
I think now that I was being too clever. |
| 15:50 |
kmlussier |
Unfortunately, taking the walk didn't solve the problem of the dog staring at me with sorrowful eyes while I try to work. |
| 15:53 |
|
jlitrell joined #evergreen |
| 16:04 |
|
dMiller_ joined #evergreen |
| 16:39 |
|
bmills joined #evergreen |
| 16:42 |
|
dMiller_ joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:35 |
|
rlefaive joined #evergreen |
| 17:46 |
Bmagic |
Something interesting: From the item status screen, if you "Request item" the result is a copy level hold without the phone number and email address pieces. When the hold is captured (via checkin) - the resulting hold slip does not include that info. Can anyone confirm that?> |
| 17:49 |
|
mrpeters joined #evergreen |
| 17:58 |
kmlussier |
Bmagic: What type of hold does that create? A force hold? |
| 17:59 |
Bmagic |
a plain copy level hold (as far as I know) |
| 18:02 |
Bmagic |
confirmed, copy level hold (on our test server) |
| 18:03 |
kmlussier |
I see. Yeah, I'm not sure. I don't think I've ever used that action before except to do force or recall holds. |
| 18:28 |
|
dMiller_ joined #evergreen |
| 19:08 |
|
rlefaive joined #evergreen |
| 20:45 |
|
rlefaive joined #evergreen |
