| Time |
Nick |
Message |
| 07:08 |
|
rfrasur joined #evergreen |
| 07:45 |
|
rjackson_isl joined #evergreen |
| 08:13 |
|
Dyrcona joined #evergreen |
| 08:22 |
|
bos20k joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:56 |
|
bos20k_ joined #evergreen |
| 09:01 |
|
bos20k joined #evergreen |
| 09:17 |
|
jvwoolf joined #evergreen |
| 09:26 |
Bmagic |
gmcharlt++ dbwells++ Dyrcona++ jeffdavis++ sandbergja++ #releases |
| 09:29 |
|
aabbee joined #evergreen |
| 09:50 |
|
jvwoolf1 joined #evergreen |
| 10:03 |
berick |
GOTO: Bmagic |
| 10:03 |
berick |
or in other words |
| 10:03 |
berick |
gmcharlt++ dbwells++ Dyrcona++ jeffdavis++ sandbergja++ #releases |
| 10:03 |
Bmagic |
:) |
| 10:04 |
Bmagic |
GOTO: # brings back qbasic memories, https://en.wikipedia.org/wiki/QBasic |
| 10:05 |
Bmagic |
ha! qbasic had an Easter egg! |
| 10:06 |
Bmagic |
I wrote a game called "Land of the golden cow" in qbasic. In 7th grade. I copied the program onto floppy disks and distributed them at school. I had to explain to folks that if your computer was upgraded to Windows 95 from 3.1, then you had DOS and therefore could run qbasic |
| 10:06 |
|
yboston joined #evergreen |
| 10:06 |
Bmagic |
but if your computer came with Windows 95, you could not run my game because you didn't have qbasic |
| 10:07 |
* csharp |
wrote an adventure game in basic in the 80s |
| 10:07 |
csharp |
wasn't a very interesting game though :-) |
| 10:07 |
Bmagic |
I wish I still had that code.... and maybe I do but I don't have a floppy drive |
| 10:08 |
Bmagic |
Pretty sure it was loaded with a ton of GOTO: calls |
| 10:09 |
Bmagic |
I think I showed it to someone and they told me that GOTO was not good and I should re-write it |
| 10:09 |
csharp |
this was kind of like my adventure game writing experience: https://www.youtube.com/watch?v=2jqKiVHS6x4&app=desktop |
| 10:09 |
csharp |
I would get something I was super proud of, then let someone else see it and it was very unimpressive |
| 10:09 |
Bmagic |
yep! |
| 10:11 |
|
nfBurton93 joined #evergreen |
| 10:13 |
gmcharlt |
berick: about that OpenSRF/RealBASIC binding you've been promising any day now... |
| 10:15 |
berick |
finally a market emerges! |
| 10:16 |
Bmagic |
But only for those who UPGRADED to Windows 95. Not those with it installed from the factory |
| 10:16 |
Bmagic |
A niche market |
| 10:16 |
|
chris__ left #evergreen |
| 10:17 |
|
nfBurton15 joined #evergreen |
| 10:18 |
|
nfBurton joined #evergreen |
| 10:20 |
mmorgan |
This question comes up every so often and I haven't found a good way to handle it. A library is closed for a period of time, and there doesn't seem to be a good way to stop hold captures for that library when items are checked in at other libraries. |
| 10:20 |
Dyrcona |
Old BASIC programmers never die. They GOSUB without RETURN. |
| 10:20 |
mmorgan |
Anyone have a creative solution? |
| 10:21 |
nfBurton |
Make each Shelving Location not holdable? |
| 10:21 |
Dyrcona |
We usually set the hold targeter skip me for the library and suspend all holds until they're open again. |
| 10:21 |
Dyrcona |
nfBurton: Only works for that library's items, not other libraries'. |
| 10:22 |
nfBurton |
Ah yes |
| 10:22 |
Dyrcona |
There's a new emergency closing handler. |
| 10:22 |
mmorgan |
Dyrcona: Yes, I've looked at that, but it doesn't do anything about hold capture as far as I can tell. |
| 10:22 |
mmorgan |
It |
| 10:23 |
mmorgan |
's good for moving due dates and shelf expire dates, though |
| 10:23 |
Dyrcona |
I've always written something to suspend the holds until the library will be open again. |
| 10:23 |
Dyrcona |
This has sometime included an email to the affected patrons. |
| 10:24 |
* mmorgan |
will look at that. |
| 10:25 |
Bmagic |
Dyrcona++ # GOSUB |
| 10:26 |
* mmorgan |
can't remember if the patron would have the option to change the pickup location if they chose |
| 10:28 |
Dyrcona |
mmorgan: I've done that, too, changed the pickup locations to a neighboring town. I believe the patron can change the pickup location, but it has been a while since I've looked at the edit hold interface in the OPAC. |
| 10:28 |
mmorgan |
Dyrcona: How would you handle activating the holds again after the closure? |
| 10:28 |
Dyrcona |
If the new open date is known, set a thaw_date. |
| 10:29 |
Dyrcona |
Or, set a thaw_date based on the best guess. |
| 10:29 |
mmorgan |
Ok, set a thaw date when you suspend, then you don't have to worry about holds that already were suspended. |
| 10:30 |
Dyrcona |
Yes, pretty much. I'll see if I can find any code to share. |
| 10:31 |
nfBurton |
Is there a trick to getting Grunt working? I'm following the new install instructions but grunt just isn't |
| 10:31 |
mmorgan |
Yup, patrons can change the pickup library in the opac. |
| 10:32 |
Dyrcona |
nfBurton: Grunt was removed. What version are you installing? |
| 10:33 |
nfBurton |
Ah I had an old installation doc. |
| 10:33 |
nfBurton |
I'm using the GIT repo |
| 10:33 |
nfBurton |
I thought it was something new lol |
| 10:33 |
|
Christineb joined #evergreen |
| 10:33 |
Dyrcona |
You're installing master, or a different branch? |
| 10:34 |
Dyrcona |
Grunt is gone as of 3.1, IIRC. |
| 10:34 |
nfBurton |
master |
| 10:34 |
Dyrcona |
Use the README in the repo for the instructions. |
| 10:34 |
nfBurton |
Ah, that's why. 3.1 was my first upgrade/installation so I've never seen it |
| 10:35 |
Dyrcona |
The 3.4-beta2 instructions should also work, but anything older, no guarantees. :) |
| 10:36 |
nfBurton |
While I'm here. To make a GIT change, because I'm close to a push, I push to the working repo signed off and then I just wait for it to be signed off and merged? |
| 10:38 |
Dyrcona |
nfBurton: Pretty much, but that assumes you've got a Lp bug that gets updated appropriately as well. |
| 10:39 |
nfBurton |
How do I get that updated as well? |
| 10:41 |
Dyrcona |
You edit it on Launchpad. |
| 10:43 |
nfBurton |
Oh okay. Thought perms were needed for that. I see how that works then. And then core committers listen to Launchpad to see when they need to look at a change? |
| 10:44 |
mmorgan |
nfBurton: Just a Launchpad login is needed to comment and add tags to a bug |
| 10:44 |
nfBurton |
I know I had to talk to someone about targeting for a release. I thought it all worked like that XD |
| 10:45 |
nfBurton |
Guess not |
| 10:45 |
nfBurton |
Makes sense |
| 10:46 |
nfBurton |
Still wrapping my head around this. I think I''ve got it though |
| 10:46 |
mmorgan |
Post a link to your branch on the bug and add a pullrequest tag so others will know to test it |
| 10:49 |
nfBurton |
Dyrcona++ mmorgan++ |
| 10:49 |
nfBurton |
Thanks! |
| 10:50 |
Dyrcona |
I'm planning to spend some time on bugs today, probably this afternoon. I noticed a few things while doing the bugmaster stuff last night that I want to look at. |
| 10:51 |
jeff |
mmorgan: we recently did this here (had a library closure for a rebuild/move, suspended holds and prevented targeting). It was messy, but worked lots better than nothing. |
| 10:51 |
Dyrcona |
Also, don't worry about setting targets. If you don't have permission, someone else will usually do it. And, I'll be looking at some targeted bugs that either slipped through the cracks or need targets dropped today. |
| 10:51 |
jeff |
mmorgan: we suspended all holds for pickup at that library and set a very specific activation date, so that we could unsuspend them in bulk later. |
| 10:53 |
jeff |
mmorgan: we also ran a script to delete rows from action.hold_copy_map for: 1) other library's holds for pickup at that library (started this a week or two before the closure, while holds were still active) and 2) that library's items for other libs (and eventually that library's items altogether) |
| 10:53 |
Dyrcona |
mmorgan: All I've come across so far is a simple update statement to set holds to frozen with a specific thaw date for pickup at a given library where the hold isn't fulfilled, captured, canceld, or already frozen. |
| 10:53 |
Dyrcona |
I know I did more complicated stuff while at MVLC. |
| 10:54 |
jeff |
mmorgan: we ran that script every minute (because it was fast, so why not) |
| 10:54 |
jeff |
mmorgan: and we also suspended any newly-placed holds for pickup at that library, with the same specific activation date. |
| 10:55 |
jeff |
mmorgan: one thing we missed: when a new hold was placed, if there was an available copy on a shelf somewhere, that copy would be set as current_copy, and we were not clearing current_copy when suspending. Those items were then captured and sent in transit and sat in limbo for a while (maybe a dozen items max). |
| 10:56 |
jeff |
mmorgan: patrons could change their pickup lib and unsuspend the hold, and we kept an eye out for still-suspended holds with a changed pickup lib with the special activation date. we didn't find many, I don't remember if we took any manual action like contacting the patron to double check. |
| 10:57 |
jeff |
we then activated and cleared the activation date on the holds that still had the specific activation timestamp. |
| 10:58 |
jeff |
another thing to remember is that the normal process of updating a hold can move the activation timestamp back in time if it was more precise than one second. |
| 10:58 |
jeff |
(caught me on a few) |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:13 |
|
jvwoolf joined #evergreen |
| 11:21 |
|
sandbergja joined #evergreen |
| 11:25 |
|
jvwoolf joined #evergreen |
| 11:31 |
|
sandbergja joined #evergreen |
| 11:44 |
|
sandbergja joined #evergreen |
| 11:44 |
* mmorgan |
returns and reads up |
| 11:45 |
mmorgan |
Dyrcona++ |
| 11:45 |
mmorgan |
jeff++ |
| 11:45 |
mmorgan |
Turns out we won't need to suspend holds. The closure is not long enough to warrant that. |
| 11:47 |
mmorgan |
We're going to make use of the capture local holds as transits checkin modifier so items won't become ready for pickup until they can actually be picked up. |
| 11:47 |
Dyrcona |
That's one use for that feature. |
| 11:48 |
mmorgan |
That's really the only use we've ever come up with :) |
| 11:50 |
Dyrcona |
It was intended for AMH with automated checkin. |
| 11:52 |
mmorgan |
How does an AMH know to use that modifier? |
| 11:52 |
Dyrcona |
You set an option in the SIP configuration, IIRC. |
| 11:54 |
mmorgan |
Oh, ok, so then those items would go to a separate bin and get a manual checkin later? |
| 11:55 |
Dyrcona |
Yeah. |
| 11:55 |
Dyrcona |
I remember tsbere implemented that feature and set this up for the Haverhill library. They has some intricate thing for determining which bin items went in. |
| 11:56 |
mmorgan |
We have one library with an AMH, but don't make use of that modifier. We have a 30 minute delay before hold notifications go out. |
| 11:57 |
|
bos20k_ joined #evergreen |
| 11:57 |
Dyrcona |
That's the default delay, I think. This AMH was 24/7. They modified the building to make the AMH accessible. |
| 11:58 |
jeff |
Yes, highly recommend capture local holds as transits. We use it for our AMH/bookdrops and for closures and for capture at locations away from the circ desk or without sticky receipt printer. |
| 12:00 |
mmorgan |
Any advice for avoiding the local holds as transit getting put in a delivery bin by mistake? |
| 12:00 |
Dyrcona |
jeff: I thought of filing a CVE that 3M SIP should be done away with. :) |
| 12:00 |
mmorgan |
When manually checking in, I mean. |
| 12:01 |
jeff |
mmorgan: put them on the hold shelf? |
| 12:01 |
Dyrcona |
Not much you can do about human error, I'm afraid. |
| 12:01 |
jeff |
Dyrcona: and replaced with what, SIP 3.0? :P |
| 12:01 |
Dyrcona |
jeff: No. |
| 12:02 |
jeff |
mmorgan: in a "library's closed" scenario we usually put them on the shelf or set them aside somewhere, since the plan is to re-scan them all and have a hold slip printed once the library's ready for patrons. |
| 12:02 |
Dyrcona |
It came from some thinking about a couple of XUl client bugs and TLS parameters, and I naturally moved to SIP isn't encrypted without some effort.... |
| 12:02 |
* jeff |
nods |
| 12:02 |
mmorgan |
jeff: I mean differentiating at checkin, seems like you'd need to scrutinize the transit destination to sort out which ones go on the holds shelf. |
| 12:03 |
mmorgan |
Because normally, everything that goes in transit would go into a bin for delivery. |
| 12:03 |
Dyrcona |
mmorgan: No more than usual, I would think. The slip is supposed to say route to hold shelf or something like that. |
| 12:04 |
Dyrcona |
Presumably staff know that the option is on and know to pay attention. |
| 12:04 |
jeff |
mmorgan: yeah, no general advice there other than to turn off auto-print and look at the destination on each and only print slips for those that are going elsewhere, and place the others on a special cart/bin, etc. |
| 12:07 |
|
sandbergja joined #evergreen |
| 12:13 |
|
sandbergja joined #evergreen |
| 12:14 |
|
bos20k joined #evergreen |
| 12:15 |
|
yboston joined #evergreen |
| 12:15 |
|
khuckins joined #evergreen |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:28 |
|
JBoyer joined #evergreen |
| 12:35 |
|
jvwoolf joined #evergreen |
| 12:36 |
|
bos20k joined #evergreen |
| 12:42 |
|
sandbergja joined #evergreen |
| 12:56 |
|
sandbergja joined #evergreen |
| 13:17 |
|
JBoyer joined #evergreen |
| 13:27 |
|
sandbergja joined #evergreen |
| 13:34 |
|
yboston joined #evergreen |
| 13:50 |
rjackson_isl |
Question about tracking circulations at a self check: With current web based Evergreen can the ws= parameter be used at login and providing it syncs up with a valid registered workstation name then the circulations on that self check will show the corresponding key entry in the workstation field for action.circulation? |
| 13:51 |
rjackson_isl |
or, do you have to have the individual sip entries in oil_sip.xml use a location_code with a matching workstation name to accomodate circulations tracking |
| 13:52 |
jeff |
rjackson_isl: it's unclear if you're asking about Evergreen's web based self checkout interface or SIP based self checkout. Can you clarify? |
| 13:53 |
rjackson_isl |
and that is part of the issue - I am not 100% clear - but I think sip based so that means the location_code is the answer? |
| 13:54 |
rjackson_isl |
see how much I miss JBoyer :( !!! |
| 13:55 |
rjackson_isl |
jeff - it all started with a simple report request to add workstation name to total circs per day of week |
| 13:55 |
jihpringle |
rjackson_isl: we track circ stats for self check based on the user group |
| 13:55 |
rjackson_isl |
turns out most of the library's circs are self check |
| 13:56 |
jihpringle |
all our sip accounts use a particular profile |
| 13:57 |
csharp |
rjackson_isl: we don't use location code for SIP and create reports based on the SIP user account home library |
| 13:57 |
csharp |
(as in the SIP device's login, not each patron) |
| 13:57 |
rjackson_isl |
jihpringle++ - just need to have a two report solution perhaps if I can't get them to agree to label the self checks |
| 14:01 |
csharp |
I just looked and we also have set up similar reports (billing in this particular case) based on the user group |
| 14:04 |
rjackson_isl |
csharp not connecting the dots still sorry! I have an example circ up with no workstation entry and the usr entry is the patron's |
| 14:04 |
|
jvwoolf1 joined #evergreen |
| 14:04 |
rjackson_isl |
what am I looking for to link to the fact it was a self check (sip) related circ |
| 14:05 |
csharp |
rjackson_isl: what about the staff member who checked out the circ? (should be the SIP account) |
| 14:05 |
rjackson_isl |
yes - thanks bulb dimly lit now |
| 14:05 |
csharp |
:-) |
| 14:07 |
csharp |
so you could do Circulation -> Circulating Staff -> Main (Profile) Permission Group -> Group ID (In list) and Circulation -> Circulating Staff -> Home Library -> Organizational Unit ID (In list) as filters (along with circ date range) |
| 14:07 |
|
yboston joined #evergreen |
| 14:08 |
rjackson_isl |
csharp++ |
| 14:10 |
csharp |
this is also where per-device SIP accounts come in handy instead of a single shared one per library/system/etc. |
| 14:11 |
rjackson_isl |
right - based on the initial request (circs per workstation per day of week) the location_code per sip account per physical machine would be what they probably want |
| 14:12 |
|
khuckins joined #evergreen |
| 14:27 |
|
stephengwills joined #evergreen |
| 14:30 |
|
RBecker joined #evergreen |
| 14:34 |
|
pastebot joined #evergreen |
| 14:35 |
|
rashma_away joined #evergreen |
| 14:37 |
mmorgan |
rjackson_isl: Regarding sip selfcheck and workstation, see bug 1259196, also http://docs.evergreen-ils.org/3.2/_sip_communication.html |
| 14:37 |
pinesol |
Launchpad bug 1259196 in Evergreen "SIP support workstation option at login" [Wishlist,Fix released] https://launchpad.net/bugs/1259196 |
| 14:37 |
mmorgan |
We haven't done this yet, but it's on our list to look at |
| 14:37 |
|
abowling joined #evergreen |
| 14:39 |
rjackson_isl |
mmorgan++ - another way to skin a cat! |
| 14:39 |
mmorgan |
Eewww |
| 14:43 |
berick |
heh |
| 14:44 |
csharp |
@blame all the cat pelts everywhere |
| 14:44 |
pinesol |
csharp: Your failure is now complete, all the cat pelts everywhere. |
| 14:48 |
rjackson_isl |
but what about the racoons? |
| 14:49 |
rjackson_isl |
I always wanted one of those tails hanging down my back as a kid ;) |
| 14:51 |
rjackson_isl |
probably influenced by the "kilt him a bar when he was only 3" song |
| 14:53 |
* mmorgan |
has never heard the expression "There's more than one way to skin a racoon" |
| 15:07 |
|
jvwoolf joined #evergreen |
| 15:10 |
rjackson_isl |
mmorgan I often wondered what it would take to dress up a road kill racoon for a hat |
| 15:11 |
mmorgan |
Eewww |
| 15:18 |
mmorgan |
What do folks reccommend these days when libraries want to buy new barcode scanners? Laser? 1D imager? 2d imager? |
| 15:22 |
mmorgan |
Definitely looking at 2D imagers for reading drivers' license codes, but what about tech services and general circ? |
| 15:24 |
mmorgan |
Need an imager to read a barcode from a smartphone, I guess I'm wondering if there's any good reason to recommend a laser over an imager? |
| 15:32 |
|
yboston joined #evergreen |
| 15:33 |
gmcharlt |
mmorgan: speed of scanning? (I'm curious, I don't know) |
| 15:36 |
mmorgan |
Used to be that lasers performed better, and metrologic/honeywell was the go to. But when we wanted to scan smartphones, we went with a Datalogic Gryphon and libraries really liked it's general performance. |
| 15:41 |
JBoyer |
mmorgan, laser is 100% out if they want to scan LCD screens like smartphones. |
| 15:41 |
mmorgan |
Now we're looking at 2d scanners to read license data, and if the cost difference isn't a big factor, a 2d imager could be a one size fits all solution. |
| 15:41 |
JBoyer |
CCD 1D imagers (long range is better) are cheap and will scan pretty much whatever you point them at. |
| 15:41 |
JBoyer |
(But if you can find 2D at ~ 1D prices, then +1 to that) |
| 15:41 |
mmorgan |
JBoyer: Right. And right. They're way better than they used to be. |
| 15:42 |
JBoyer |
What I'm used to specifically are Wasp 8905's, but whatever should be fine. |
| 15:44 |
mmorgan |
Yeah. An all purpose scanner was what I was thinking. Not familiar with the Wasp 8905, I'll take a look. Thanks for the sounding board services. :) |
| 16:10 |
|
jvwoolf left #evergreen |
| 17:01 |
|
yboston joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 18:11 |
|
cmalm joined #evergreen |
| 21:17 |
|
sandbergja joined #evergreen |
| 21:20 |
jeff |
mmorgan: what app are you using when scanning pdf417 license barcodes? i've mostly been doing it with apps with a phone camera and then passing the raw data via HTTPS to be parsed. |
| 21:20 |
jeff |
oh. |
| 21:20 |
jeff |
@later tell mmorgan what app are you using when scanning pdf417 license barcodes? i've mostly been doing it with apps with a phone camera and then passing the raw data via HTTPS to be parsed. |
| 21:20 |
pinesol |
jeff: The operation succeeded. |
| 21:21 |
jeff |
and I wonder if your states are better about separating first name and middle name/initial. |
| 21:21 |
jeff |
because michigan fails there. |
| 21:21 |
jeff |
which is an immediate frustration for me. |
| 22:36 |
|
sandbergja joined #evergreen |
| 23:03 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
