| Time |
Nick |
Message |
| 03:46 |
|
zerick joined #evergreen |
| 07:40 |
|
jboyer-isl joined #evergreen |
| 07:43 |
|
collum joined #evergreen |
| 07:50 |
|
kmlussier joined #evergreen |
| 08:05 |
|
akilsdonk joined #evergreen |
| 08:08 |
kmlussier |
Good morning! |
| 08:23 |
|
rjackson-isl joined #evergreen |
| 08:31 |
|
Dyrcona joined #evergreen |
| 08:32 |
|
ericar joined #evergreen |
| 08:32 |
|
ericar left #evergreen |
| 08:33 |
|
tspindler joined #evergreen |
| 08:34 |
|
Shae joined #evergreen |
| 08:39 |
|
mrpeters joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 09:29 |
jeff |
good morning! :-) |
| 09:31 |
mmorgan |
Good Morning! |
| 09:34 |
|
yboston joined #evergreen |
| 10:01 |
Dyrcona |
kmlussier: Just a warning: I'm going to load the branch from lp 1347774 on my dev machine this morning. You shouldn't notice, but you might get logged out if you're doing anything at the time. |
| 10:01 |
pinesol_green |
Launchpad bug 1347774 in Evergreen "Backend logic has leaked into the TPAC (and friends)" (affected: 2, heat: 12) [Wishlist,New] https://launchpad.net/bugs/1347774 |
| 10:04 |
kmlussier |
Dyrcona: OK, thanks. |
| 10:05 |
Dyrcona |
kmlussier: Actually, this requires a recompile of C code, and I pulled in the latest commit to master, so I'll just do my usual rebuild script which will make a new client. |
| 10:08 |
Dyrcona |
Not good: * timed out waiting on open-ils.storage pid=16024 to die |
| 10:08 |
Dyrcona |
kmlussier: Were you doing something? |
| 10:09 |
kmlussier |
Dyrcona: No, I logged out as soon as you said you were loading the branch. I wasn't doing anything there anyway. I just have a tendency to leave the client open when I'm working on something else. |
| 10:11 |
|
jwoodard joined #evergreen |
| 10:12 |
Dyrcona |
OK. I also built so you won't need to download a new client after all. |
| 10:15 |
Dyrcona |
Everything should be running again, if there's anything else you wanted to look at. |
| 10:18 |
|
tsbere_ joined #evergreen |
| 10:18 |
|
jboyer-isl joined #evergreen |
| 10:20 |
|
eeevil joined #evergreen |
| 10:29 |
kmlussier |
eeevil: Thanks for that clarification. I don't think I put the correct indicator information in the docs, so I'll have to update those. |
| 10:30 |
eeevil |
kmlussier: ah, I see. I default to the code :) |
| 10:30 |
eeevil |
kmlussier: if there's more info you need that you think I might be able to dig up quickly, just let me know |
| 10:31 |
kmlussier |
Is there a reason why we accept an ind1 value of 1 in located URI's and not in the other 856 fields? |
| 10:33 |
kmlussier |
If it was just an oversight. I would be willing to make a branch to make the unadorned 856 links consistent with Located URI's. |
| 10:34 |
eeevil |
kmlussier: the tpac code was just developed separately, and with more iteration |
| 10:35 |
eeevil |
when I did the LURI code I didn't see any reason to not allow FTP urls |
| 10:41 |
kmlussier |
Yeah, I don't know that there are many cases where FTP urls would be used in the non-located 856 tags, but I'm a big fan of making things consistent to minimize confusion. |
| 11:07 |
mmorgan |
Is UPDATE_HOLD the only permission that applies when transferring a hold from one title to another? |
| 11:11 |
* tsbere |
isn't even sure how to move a hold from one title to another without merging things |
| 11:12 |
mmorgan |
"Actions for this record" allows marking a bib as the transfer destination. |
| 11:12 |
tsbere |
Huh. That sounds dangerous in a parts world. |
| 11:12 |
mmorgan |
For certain! |
| 11:13 |
mmorgan |
Actions for this record also has "Transfer all title level holds" |
| 11:13 |
jeff |
iirc, it'll also happily move bibs that are on-shelf, and reset/retarget them. |
| 11:13 |
jeff |
i dug into that a bit ago, but i don't remember if i found something bugworthy or if it ended up being a manual retargeting. |
| 11:13 |
* jeff |
makes a note to check notes :P |
| 11:14 |
mmorgan |
problem is "Actions for selected hold" has "transfer to marked title", but more than once users have transferred all intending to transfer only some. |
| 11:14 |
mmorgan |
much retargeting ensues ... |
| 11:15 |
kmlussier |
mmorgan: Is that because they select too many holds from "Actions for selected holds" or because they are using the "Transfer all title level holds" option on the bib record? |
| 11:15 |
mmorgan |
kmlussier: They are choosing the wrong option under the record action, instead of the hold action. |
| 11:16 |
mmorgan |
the clicks are similar, and for users that do it often, it can happen. |
| 11:16 |
mmorgan |
they dutifully select the holds they want to move, but then just click the wrong "actions" button and choose the similar sounding function. |
| 11:16 |
kmlussier |
I'm also wondering what the use case is for transferring *all* title level holds from one record to another. I can see it being useful in the case of bib record merges, but since holds are automatially transferred during a record merge, I'm not seeing when it would be desired. |
| 11:18 |
mmorgan |
good question. I am not sure I can think of one either. |
| 11:18 |
tsbere |
kmlussier: "Ooops, this was supposed to be flagged as a non-holdable electronic resource with no copies, lets move the holds over to the record for the *book*" |
| 11:19 |
mmorgan |
tsbere: but you could certainly do that by selecting the holds and transferring the selected ones. |
| 11:27 |
jboyer-isl |
jeff: I thought it bugworthy in bug 1312824 |
| 11:27 |
pinesol_green |
Launchpad bug 1312824 in Evergreen "open-ils.circ.hold.change_title(.specific_holds) APIs cancel previously captured holds at other locations, confusing staff and patrons" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1312824 - Assigned to Jeff Godin (jgodin) |
| 11:28 |
jboyer-isl |
I'm not certain if my proposed fix was the best way to do it, but we've been humming along fine with it here for some time. |
| 11:30 |
jeff |
jboyer-isl: ah! thanks for the reminder! in my notes, I'm sure I would have found "assigned bug to self for fixing" :-) |
| 11:31 |
csharp |
so apparently I *can* run authority imports that run into the workday without issue ;-) |
| 11:31 |
csharp |
started 2 files of 10K auth records last night at around 9:30 that are still running |
| 11:32 |
|
kmlussier1 joined #evergreen |
| 11:33 |
hopkinsju |
Based on the documentation I would think that setting 'Show evening_phone field on patron registration' true would show the field on the patron self registration form. This doesn't seem to be the case. Am I missing something? |
| 11:33 |
hopkinsju |
(Repost from yesterday... Hopefully I'm not in the middle of another meeting) |
| 11:33 |
csharp |
hopkinsju: STOP INTERRUPTING ME! |
| 11:33 |
mmorgan |
jboyer-isl: jeff: That certainly would help matters! |
| 11:34 |
mmorgan |
still have the permission question, though... |
| 11:34 |
csharp |
hopkinsju: let me test that on our system |
| 11:34 |
mmorgan |
hopkinsju: maybe the "Suggest evening_phone..." is what you need? Are you defaulting to suggested fields? |
| 11:36 |
kmlussier1 |
I would like to make an argument for removing the "transfer all title level holds" options from the client. It just seems too dangerous, and it's not like there aren't other ways to perform the same operation. |
| 11:36 |
* kmlussier1 |
prepares a message to the list. |
| 11:37 |
* mmorgan |
agrees with kmlussier |
| 11:37 |
kmlussier1 |
mmorgan: Sorry, I don't know the answer your permissions question. |
| 11:38 |
tsbere |
mmorgan: My thought was for "why you might want to move them all without a bib merge" that kmlussier couldn't come up with a reason for ;) |
| 11:38 |
tsbere |
*how* you move them all is another story entirely |
| 11:38 |
hopkinsju |
mmorgan: We are not defaulting to suggested fields. I just set the suggestion of evening_phone - lemme see if that worked. |
| 11:39 |
hopkinsju |
That didn't do it. |
| 11:39 |
tsbere |
hopkinsju: Those settings are for the staff interface patron registration. |
| 11:39 |
csharp |
hopkinsju: I can confirm that show and suggest do not affect the self-reg interface |
| 11:39 |
* tsbere |
never rigged anything like that for the self-reg interface |
| 11:39 |
bshum |
This came up in IRC another time. |
| 11:40 |
bshum |
There's a problem with the DIG docs or the description for the settings I think |
| 11:40 |
hopkinsju |
Alright, that's good to know. I think the documentation is incorrect then. Let me re-read - I may have misinterpreted it. |
| 11:40 |
bshum |
And we think they ought to be related, but they are not |
| 11:40 |
* eeevil |
reads up |
| 11:40 |
hopkinsju |
Yeah. http://docs.evergreen-ils.org/dev/_patron_self_registration.html |
| 11:40 |
eeevil |
mmorgan: both manual bib merges and orphaned holds (last copy goes missing) can make use of that action... those are the cases I recall |
| 11:41 |
* csharp |
checks out register.tt2 |
| 11:42 |
bshum |
Yeah, we talked about it on http://irc.evergreen-ils.org/evergreen/2014-05-30 |
| 11:44 |
csharp |
huh - I've seen that work before, though - where you require/suggest something for the staff client and it affects self-reg |
| 11:44 |
csharp |
didn't work for all fields I tested, but some |
| 11:45 |
* tsbere |
didn't rig that, but if someone else did... |
| 11:45 |
tsbere |
Though it would still likely require that self-reg *have* the field in question |
| 11:45 |
pastebot |
"csharp" at 64.57.241.14 pasted "relevant section of register.tt2" (19 lines) at http://paste.evergreen-ils.org/10 |
| 11:48 |
csharp |
ah - I see how it works now |
| 11:48 |
csharp |
if it's not in the list of fields, it's not even processed |
| 11:48 |
csharp |
so it's just a matter of learning how to add the desired field to the list |
| 11:49 |
* csharp |
assumes "class" there refers to fm_IDL.xml |
| 11:49 |
tsbere |
csharp: Which itself will refer to a database table that would likely need to have a field added too |
| 11:50 |
csharp |
fortunately, evening_phone *is* already in the fieldmapper file in the stgu class |
| 11:52 |
csharp |
hopkinsju: you might try adding '{class => 'stgu', name = 'evening_phone', label => l('Evening Phone')}' to your list and see if that Just Works™ |
| 11:53 |
csharp |
hey - it works! |
| 11:53 |
csharp |
for me anyway |
| 11:57 |
hopkinsju |
csharp: I'll give it a go |
| 12:01 |
Dyrcona |
csharp++ # If you don't watch out, you'll be programming before too long. ;) |
| 12:01 |
csharp |
heh |
| 12:02 |
|
mtcarlson joined #evergreen |
| 12:11 |
hopkinsju |
csharp++ Yep, that worked. Thanks man. |
| 12:11 |
hopkinsju |
The library also wanted to add password, within city limits, and something else - but none of those worked. |
| 12:11 |
hopkinsju |
Oh, notification preferences. |
| 12:12 |
hopkinsju |
I think that we can expect other libraries to ask for fields that are a part of the patron profile to be a part of the self registration process. |
| 12:38 |
Dyrcona |
hopkinsju: You know self-registration isn't meant to be final, right? The patron is expected to show up at the library some time to finish the process. |
| 12:39 |
hopkinsju |
Dyrcona: Oh yeah, of course. But I assume the reason for collecting as much information as we do is, at least in part, an effort to save the library staff the time and effort of data entry. |
| 12:39 |
hopkinsju |
So it stands to reason that we'd want the ability to include any field. |
| 12:41 |
* hopkinsju |
gooes to make chili |
| 12:42 |
* jeff |
nods |
| 12:42 |
jeff |
i've toyed with the idea of feeding user settings and stat cats for staged users |
| 12:50 |
jcamins |
jeff: if you feed stat cats, they will follow you home, and you'll have to share your tuna or put up with an endless chorus of complaining. (p > 0.99) |
| 12:52 |
Dyrcona |
:) |
| 12:53 |
gmcharlt |
@quote add <jcamins> if you feed stat cats, they will follow you home, and you'll have to share your tuna or put up with an endless chorus of complaining. (p > 0.99) |
| 12:53 |
pinesol_green |
gmcharlt: The operation succeeded. Quote #86 added. |
| 12:56 |
eeevil |
jeff: statcats are supported to a degree right now, if the names line up ... at least in the db side (or, they were in my first version...) |
| 12:57 |
Dyrcona |
@quote random |
| 12:57 |
pinesol_green |
Dyrcona: Quote #71: "< rfrasur> I dunno what that means, but I'll bet it's funny." (added by csharp at 09:48 AM, December 13, 2013) |
| 13:03 |
kmlussier |
We have 86 quotes? Wow. |
| 13:04 |
Dyrcona |
kmlussier: Not exactly, some have been delted. |
| 13:04 |
Dyrcona |
deleted, even. |
| 13:05 |
jeff |
eeevil: i think i remember that -- that as far as using the stagin api went, it was just a matter of throwing the correct object in (may have required stat cat ids -- dunno) |
| 13:32 |
csharp |
hopkinsju: password is also available in that same stgu source |
| 13:32 |
csharp |
just FYI |
| 13:32 |
csharp |
the others would probably be more involved |
| 13:37 |
Dyrcona |
I don't think you want patrons choosing their stat cats anyway. |
| 13:38 |
Dyrcona |
At least, not the way that we use them at MVLC. |
| 13:39 |
eeevil |
Dyrcona: oh, surely not :) |
| 13:39 |
Dyrcona |
But, then again, we don't use them for much. |
| 13:40 |
eeevil |
statcat support was for batch imports from a student system originally |
| 13:40 |
Dyrcona |
eeevil: Makes sense |
| 13:51 |
jeff |
some stat cats make sense for patron entry, some do not. |
| 13:51 |
jeff |
very much a local-practices specific thing :-) |
| 14:19 |
Dyrcona |
EDI-- |
| 14:19 |
Dyrcona |
EDI-- # 'cause once is not enough |
| 14:20 |
kmlussier |
Dyrcona: Is this the problem with the EDI invoice? |
| 14:21 |
Dyrcona |
I have no idea. |
| 14:21 |
Dyrcona |
Vendor says its us. I see nothing. |
| 14:21 |
Dyrcona |
EDI is just another crap standard. |
| 15:10 |
|
tspindler left #evergreen |
| 15:18 |
|
hbrennan joined #evergreen |
| 15:34 |
|
mtcarlson joined #evergreen |
| 15:49 |
Dyrcona |
@quote get 4 |
| 15:49 |
pinesol_green |
Dyrcona: Error: There is no Quote with id #4 in my database for #. |
| 15:52 |
jeff |
Invalid indicators "" forced to blanks in record 8185 for tag 440 |
| 16:12 |
Dyrcona |
berick: Do you think you need more work on the latest branch on lp 1308239 ? |
| 16:12 |
pinesol_green |
Launchpad bug 1308239 in Evergreen "Support targeting and fulfillment of precat copy holds (for ILL)" (affected: 2, heat: 10) [Wishlist,In progress] https://launchpad.net/bugs/1308239 - Assigned to Bill Erickson (erickson-esilibrary) |
| 16:13 |
Dyrcona |
I verified the checkout failure, loaded the new branch, and it resolves that. |
| 16:15 |
berick |
Dyrcona: I don't think so. my change mimics the previous logic, only in a less explody way, so I'm confortable w/ it |
| 16:15 |
Dyrcona |
Ok. I just wondered when I saw the status was changed to "in progress." |
| 16:15 |
berick |
i have no other code to push for it, either |
| 16:15 |
berick |
oh, my bad |
| 16:16 |
Dyrcona |
I'll push it to master, then. |
| 16:16 |
Dyrcona |
np. |
| 16:16 |
berick |
i should have changed that and removed myself |
| 16:16 |
berick |
Dyrcona++ |
| 16:16 |
berick |
thanks |
| 16:17 |
|
mtcarlson joined #evergreen |
| 16:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1308239 precat holds fulfillment logic repair - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e46f332> |
| 16:44 |
Dyrcona |
kmlussier++ |
| 16:45 |
Dyrcona |
I meant to ask about sandboxes in #koha today, but got busy with other things. |
| 16:45 |
Dyrcona |
I also want to do a little research on my own first. |
| 16:45 |
kmlussier |
EDI? :) |
| 16:47 |
Dyrcona |
EDI among other things. |
| 17:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:21 |
|
mmorgan left #evergreen |
| 17:42 |
|
kmlussier joined #evergreen |
| 18:05 |
|
zerick joined #evergreen |
| 20:39 |
|
artunit joined #evergreen |
| 22:35 |
* jeff |
yawns |
| 22:40 |
gmcharlt |
wake up! |
