| Time |
Nick |
Message |
| 01:09 |
|
dbwells_ joined #evergreen |
| 02:04 |
|
dbwells__ joined #evergreen |
| 02:19 |
|
gsams joined #evergreen |
| 02:27 |
|
gsams joined #evergreen |
| 02:44 |
|
geoffsams joined #evergreen |
| 03:08 |
|
gsams joined #evergreen |
| 03:16 |
|
abuss joined #evergreen |
| 03:17 |
|
abuss left #evergreen |
| 06:32 |
|
Callender_ joined #evergreen |
| 06:51 |
|
mnsri joined #evergreen |
| 07:01 |
|
wsmoak joined #evergreen |
| 07:17 |
|
artunit joined #evergreen |
| 07:30 |
|
rjackson-isl joined #evergreen |
| 08:00 |
|
akilsdonk joined #evergreen |
| 08:28 |
|
sarabee joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:39 |
|
collum joined #evergreen |
| 08:44 |
|
Shae joined #evergreen |
| 08:49 |
|
mrpeters joined #evergreen |
| 08:49 |
|
wsmoak joined #evergreen |
| 08:49 |
|
wsmoak joined #evergreen |
| 08:51 |
|
jwoodard joined #evergreen |
| 08:52 |
mrpeters |
dbwells++ thank you for the great info last night. so, we have retrieve_all, search_, are there others? any documentation on this I can read? |
| 09:11 |
dbwells |
mrpeters: I'm not sure if there is any thorough documentation for that. A few bits and pieces exist in various tutorials, mostly the work of dbs. |
| 09:12 |
mrpeters |
10-4 yeah, he has lots of great stuff for opensrf |
| 09:12 |
mrpeters |
i think i have this working, about to fire up and test |
| 09:12 |
mrpeters |
i was missing declaring my $auth along with $ident_type |
| 09:13 |
dbwells |
mrpeters: The usual CRUD (create/retrieve/update/delete) commands are all available, as well as search, batch_retrieve, and retrieve_all. |
| 09:13 |
mrpeters |
ok, very cool |
| 09:13 |
mrpeters |
well crap, no dice on the alpha sort |
| 09:14 |
mrpeters |
http://pastie.org/9732401 |
| 09:15 |
mrpeters |
maybe I'm not hitting upon the second return in the sub get_user_ident_types |
| 09:16 |
mrpeters |
it seems like it already has the values for $ident_types loaded, so the new bit of code isn't executed. any advice on why there are 2 cases there? |
| 09:17 |
|
krvmga joined #evergreen |
| 09:17 |
krvmga |
does anyone have an evergreen implementation where users can switch the language of the interface (say, from english to french or english to spanish)? |
| 09:17 |
tsbere |
mrpeters: ident_types almost never change, so it is caching the first time it is ever called |
| 09:18 |
krvmga |
in the OPAC, that is |
| 09:19 |
dbwells |
mrpeters: I've got a 9:30am meeting, but I'll check back later. Unless ident_types is also set by a different function, your new line should be running at least once after the service starts. |
| 09:19 |
|
RoganH joined #evergreen |
| 09:20 |
|
rjackson-isl joined #evergreen |
| 09:22 |
mrpeters |
10-4 dbwells thank you -- i think they do get cached during the login process |
| 09:22 |
mrpeters |
Retrieved list for cit objects |
| 09:23 |
tsbere |
mrpeters: For more fun, they are not only cached at login, the order they come out doesn't matter. They are converted to a hash by whatever their identifying column is. |
| 09:24 |
mrpeters |
tsbere: is that happening with javascript for register.tt2? |
| 09:25 |
tsbere |
mrpeters: That is happening in data.js OpenILS/data.js, basically |
| 09:25 |
mrpeters |
ah interesting i overlooked that in my code surfing |
| 09:25 |
tsbere |
Given that I can't find any other part of the system calling the backend function in question (at all) I assume that is where the items are being cached |
| 09:26 |
mrpeters |
so perhaps a change to the perl is pointless |
| 09:29 |
mrpeters |
and the focus should be on getting that javascript to order things alphabetically |
| 09:29 |
|
kmlussier joined #evergreen |
| 09:30 |
tsbere |
mrpeters: As a general note, the caching javascript can't order alphabetically, as hashes have no fixed order. :p |
| 09:30 |
mrpeters |
do you think this is an impossible to fix bug then? |
| 09:30 |
tsbere |
mrpeters: Er, what bug is this anyway? |
| 09:30 |
mrpeters |
https://bugs.launchpad.net/evergreen/+bug/506689 |
| 09:30 |
pinesol_green |
Launchpad bug 506689 in Evergreen "Patrons > Identification Type > (Sort order)" (affected: 1, heat: 8) [Wishlist,Confirmed] |
| 09:34 |
tsbere |
Well, the default ident type is already covered |
| 09:35 |
mrpeters |
right, by a yaous |
| 09:35 |
mrpeters |
if you set one |
| 09:41 |
mrpeters |
i think this is less about a default value, but some libraries have quite a few ident type values, and they sort by id which makes it difficult to find what you want |
| 09:41 |
tsbere |
mrpeters: I am not sure how deep into things you have to go to change that sort order |
| 09:41 |
tsbere |
mrpeters: I think you have to dig into AutoFieldWidget and beyond. >_> |
| 09:41 |
mrpeters |
i think the perl that dbwells helped me with will do that, but yeah if its going to get mangled again later on it may not be the right approach |
| 09:42 |
tsbere |
mrpeters: The perl would help if the resulting order wasn't being ignored. |
| 09:43 |
mrpeters |
yeah, thats why i am wondering if i can elimiate that first return $ident_types if $ident_types; -- im not really sure what that does |
| 09:43 |
tsbere |
mrpeters: That says "if we have ever looked up the ident types, cache it, and then return the cache instead of running to the DB every time" |
| 09:44 |
mrpeters |
ok, thats what i figured but wanted to be sure |
| 09:44 |
tsbere |
mrpeters: AKA, to avoid a lot of DB run-arounds, don't touch that line. :P |
| 09:44 |
mrpeters |
it can't be that big of a hit to the db though, can it? |
| 09:45 |
mrpeters |
it actually doesn't work anyways if i remove that line, still sorted by id which, as you say, is probably the data.js |
| 09:45 |
mmorgan |
tsbere: for this type of field, would clearing cache in the client cause it to pull from the db? |
| 09:45 |
|
RoganH joined #evergreen |
| 09:46 |
tsbere |
mrpeters: data.js isn't sorting. It is un-sorting by storing a hash of IDs. |
| 09:46 |
tsbere |
mmorgan: For identification types the only way to get it to pull new values from the db is restart services, then log out of and back into the client. |
| 09:48 |
mmorgan |
ok, thanks. |
| 09:48 |
mrpeters |
ok, so the goal would be to get it passed the id values in whatever order would be equivelant to alpha -- could be 4, 1, 2, 5, 3 for example where 4 = "starts with A", 5 = "starts with M" and then you have the defaults in there |
| 09:49 |
mrpeters |
which are actually not alpha either, so it would be more like 4,1,3,5,2 i guess |
| 09:50 |
tsbere |
mrpeters: You are welcome in advance. http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/sort_ident_type |
| 09:51 |
mrpeters |
oh...thank you...im sorry i wasn't intending for you to have to fix the bug yourself |
| 09:52 |
mrpeters |
i just latched on to this one because i thought it might be something i could fix, i have no real ties to it |
| 09:52 |
mrpeters |
but im sure the folks who wanted that feature appreciate it |
| 09:52 |
tsbere |
mrpeters: Was more of a "does that work?" and when the answer was yes it was then as simple as "make it a commit on a new branch" :P |
| 09:52 |
mrpeters |
tsbere++ |
| 09:53 |
mrpeters |
id like to try to understand what you did there. i understand we're looking at fm_IDL.xml (i beleive thats what fmcls/fmfield stand for) |
| 09:54 |
mrpeters |
what is the dijitArgs.fetchProperties? is that an Evergreen command? dojo? |
| 09:54 |
tsbere |
"If we are building the widget for au->ident_type then add a fetchProperties member to the dijitArgs hash specifying a sort order" |
| 09:54 |
tsbere |
dijitArgs being "things to be passed through to the dojo widget" basically |
| 09:54 |
|
gsams joined #evergreen |
| 09:55 |
mrpeters |
ok, i follow you. what other members are available for dijitArgs? |
| 09:55 |
tsbere |
and fetchProperties lets you modify how the widget reads the data store. The data store in this case being the cached list of ident_type values that would, without that, be ordered by their hash key, aka by ID |
| 09:55 |
tsbere |
dijitArgs has quite a few, some the code already sets in there, and some vary by the widget that will be created. |
| 09:56 |
mrpeters |
someone mentioned wanting to sort the permission profiles alphabetically, under each heading (Users, Staff, etc.) could I apply the same principals there? |
| 09:56 |
* mmorgan |
is listening because of lp 816615 which sounds similar |
| 09:56 |
pinesol_green |
Launchpad bug 816615 in Evergreen "patron profile permission group sort order" (affected: 4, heat: 30) [Wishlist,Triaged] https://launchpad.net/bugs/816615 |
| 09:56 |
tsbere |
You can see just above that we set popupClass to an empty string if we are looking at the DOB field and ui.patron.edit.au.dob.calendar is not set to a "true" value. That suppresses any attempts at calendar popups. |
| 09:56 |
csharp |
tsbere: if you have a second, I'm troubleshooting why a hold request for a particular title isn't allowing the hold request... is it hold_request_permit_test() that I want? |
| 09:57 |
tsbere |
mrpeters/mmorgan: That would still be a fetchProperties thing, though getting that to sort properly may be more complicated. |
| 09:57 |
tsbere |
csharp: That sounds about right, but I am not looking at that part of the system right now ;) |
| 09:58 |
mrpeters |
is your concern that it would sort the group headings too, because of the way the tree gets built? |
| 09:58 |
csharp |
tsbere: understood - thanks! |
| 10:00 |
tsbere |
mrpeters: Gimme a sec to test something quick. |
| 10:01 |
tsbere |
mrpeters: Yea, a standard sort kindof ignores the "tree" part of things... |
| 10:02 |
mrpeters |
ok, i think phasefx mentioned that in the bug as a possible side effect |
| 10:03 |
mrpeters |
your sort_ident_type branch works perfect, signoff forthcoming |
| 10:03 |
* bshum |
just realized that once alpha sort for ident_type goes in, he will no longer have "Yes" (id 1) before "No" (id 2) in his patron registration. |
| 10:03 |
mrpeters |
sorry all i can offer is a signoff |
| 10:03 |
tsbere |
bshum: I put a comment in my commit message "maybe we want this to be toggled by YAOUS" :P |
| 10:03 |
mrpeters |
maybe it doesnt have to go in to master, but can be out there for people who want it that way |
| 10:03 |
* bshum |
needs to alter more customizations |
| 10:03 |
mrpeters |
until we get a yaous |
| 10:04 |
tsbere |
adding yaous isn't that hard either. I am just not all that interested in doing so. |
| 10:04 |
tsbere |
MVLC has a whopping one ident_type in the list. :P |
| 10:05 |
bshum |
I think we altered the question from specifying a specific ident_type to asking "Do you use the ident field?" basically. That's why ours is a Yes/No answer. |
| 10:05 |
bshum |
But yeah, maybe YAOUS would be nicer for me :) |
| 10:05 |
bshum |
But I'm using it in a nontraditional manner. |
| 10:06 |
bshum |
Less YAOUS is good for keeping complications low sometimes :( |
| 10:06 |
bshum |
Maybe I'll just have to make it "Yes" vs. "no" :D |
| 10:07 |
bshum |
Or maybe "No" should go first anyways, since that's commonly the default. |
| 10:07 |
* bshum |
reverses his opinion and moves on to continuing to hate on parts |
| 10:07 |
mmorgan |
bshum: Did I miss something, can you not use the ou setting to set the default ident type? |
| 10:08 |
* mmorgan |
attempts to distract bshum from parts ;-) |
| 10:08 |
bshum |
mmorgan: No, I'm just being grumbly on parts today because of continued issues stemming from https://bugs.launchpad.net/evergreen/+bug/904472 |
| 10:08 |
pinesol_green |
Launchpad bug 904472 in Evergreen "Transferring items with monographic parts to a new bib record causes problems with holds placement" (affected: 4, heat: 34) [Undecided,Triaged] - Assigned to Dan Pearl (dpearl) |
| 10:08 |
bshum |
I think we should just add something to the code to kill off the part/copy mapping when transferring the copy from original bib to new bib. |
| 10:09 |
* kmlussier |
will continue to hate negative balances while bshum continues to hate parts. |
| 10:10 |
bshum |
mmorgan: And yes, we do use the default ident type to specify between schools and public libraries (schools use the "Yes", publics use the "No") and 99% of the time, nobody will change that, so I guess it hardly matters what the actual listed order appears like in the interface :) |
| 10:10 |
* bshum |
prefers consistency |
| 10:10 |
bshum |
So no YAOUS, don't do it! |
| 10:10 |
bshum |
it should just be in alpha order, end of it. |
| 10:11 |
bshum |
kmlussier: I hate negative balances too :) |
| 10:11 |
kmlussier |
bshum: Yes, I figured that was something we could all agree upon. :) |
| 10:11 |
mrpeters |
as soon as i get my key issue for working sorted out ill push up my signoff then, and update the bug with pullrequest |
| 10:11 |
mrpeters |
tsbere++ |
| 10:15 |
tsbere |
So, yea, to make the permission groups sort we have to edit our custom widget. |
| 10:16 |
* tsbere |
isn't in the mood to figure that one out |
| 10:17 |
|
yboston joined #evergreen |
| 10:18 |
tsbere |
mrpeters: Feel free to dig into FilteringTreeSelect.js to see if you can cause the _makeNodeList function to sort children by a specified field (if such a field has been specified, anyway, I wouldn't apply a default, but that is me). |
| 10:18 |
mrpeters |
cool, thank you |
| 10:40 |
kmlussier |
Just realized we need to add Evergreen for Academics to http://evergreen-ils.org/communicate/committees/ |
| 10:49 |
bshum |
kmlussier: Should probably also remove/update the conference organizing committee list :) |
| 10:49 |
kmlussier |
bshum: Yes, I contacted buzzy earlier this week about that one. I just want to make sure I'm not missing anyone when I update it. |
| 10:51 |
kmlussier |
krvmga: In response to your earlier question, you might want to check with dbs. Laurentian has both English and French - https://laurentian.concat.ca/eg/opac/home?locg=105 |
| 10:52 |
krvmga |
kmlussier: thanks. i sent him a message. |
| 10:53 |
kmlussier |
krvmga: I don't know how far you've gotten in your explorations, but http://docs.evergreen-ils.org/2.4/_setting_a_default_language_and_adding_optional_languages.html, addresses this topic a bit. |
| 10:53 |
kmlussier |
But I don't think the list of languages if entirely accurate. |
| 10:54 |
krvmga |
kmlussier: thanks. i'm just doing the early exploration into adding this to our catalog. |
| 10:57 |
krvmga |
kmlussier: i notice that the table of currently supported languages for 2.6 does not include Spanish. this is actually the language i'm most interested in for our patron base. |
| 10:57 |
kmlussier |
krvmga: As I said, I think this table is out of date. |
| 10:57 |
bshum |
krvmga: The spanish TPAC file has not been fully translated. Once upon a time, Biblio's libraries helped to create the JSPAC file, but we haven't had time to update it for TPAC's strings. |
| 10:58 |
krvmga |
bshum: very interesting. is there anything we can do to help? |
| 10:58 |
kmlussier |
bshum: I was thinking the library in Mexico would have been updating it. No? |
| 10:59 |
bshum |
You can always check the progress of translations by looking at Launchpad |
| 10:59 |
kmlussier |
https://translations.launchpad.net/evergreen |
| 10:59 |
bshum |
https://translations.launchpad.net/evergreen/master/+lang/es |
| 10:59 |
bshum |
"tpac" is only 70% translated presently |
| 11:00 |
bshum |
So that file needs finishing |
| 11:00 |
kmlussier |
Ooh. I hadn't seen that screen before. Nice! |
| 11:00 |
bshum |
And then we have to sync it with master at some point during the next release cycle. |
| 11:00 |
bshum |
i.e. something to work on before 2.8.0 is cut/released |
| 11:01 |
bshum |
We only update translations at major release series as far as I know. |
| 11:01 |
bshum |
To avoid drift between what's in master for strings vs. Launchpad vs. specific series. |
| 11:01 |
bshum |
So, krvmga, two big ways to proceed I think |
| 11:02 |
bshum |
1) You go to the site, get an LP account and add strings for anything untranslated |
| 11:02 |
bshum |
You can page through it and see what's left to translate and add suggestions |
| 11:02 |
bshum |
Or 2) You can download the entire PO file for tpac |
| 11:02 |
bshum |
And then update the strings in there enmasse |
| 11:02 |
bshum |
Then upload it back to Launchpad |
| 11:02 |
bshum |
And import a bunch at the same time |
| 11:03 |
krvmga |
bshum: thx. that's great. i think i've already added some things to that file in the past. i'll look through it and see what i can do. |
| 11:03 |
bshum |
Won't necessarily help till 2.8, but it's a good contributor goal to make before the next release. |
| 11:04 |
bshum |
There's always strong interest in getting Spanish done, but it's a matter of doing it :) |
| 11:04 |
bshum |
Based on LP |
| 11:04 |
bshum |
I'd say Russian TPAC is no |
| 11:05 |
bshum |
0% there |
| 11:05 |
bshum |
Armenian is close, 89.9% |
| 11:06 |
bshum |
Czech is 100% |
| 11:06 |
bshum |
(and with the fixes I made last release for 2.7, they should finally be in reasonably good sync at last) |
| 11:07 |
bshum |
Portuguese is only 46% done, so not enough of that either. |
| 11:07 |
kmlussier |
Finnish is pretty far along too. |
| 11:08 |
kmlussier |
I think that page of the docs should just link to Launchpad so that we don't have to continually update it as languages are added. |
| 11:08 |
kmlussier |
I think we've had this conversation here before. :-/ |
| 11:13 |
|
dreuther_ joined #evergreen |
| 11:18 |
|
nhilton joined #evergreen |
| 11:20 |
|
nhilton_ joined #evergreen |
| 11:45 |
|
dreuther joined #evergreen |
| 12:01 |
bshum |
yboston: kmlussier: Wasn't the academics meeting supposed to be last Thursday? There's an EOB meeting this afternoon at 2pm EST at the same time you announced the other. |
| 12:01 |
bshum |
Oh, nevermind |
| 12:01 |
bshum |
I misread the email |
| 12:01 |
kmlussier |
bshum: I was just ending out minutes |
| 12:01 |
bshum |
The title confused me |
| 12:01 |
bshum |
:) |
| 12:01 |
kmlussier |
sending even |
| 12:01 |
bshum |
Nevermind, clearly I need lunch |
| 12:02 |
kmlussier |
Sorry, I should have sent a new e-mail rather than replying to one from last week. My bad. |
| 12:03 |
|
nhilton joined #evergreen |
| 12:10 |
|
dreuther_ joined #evergreen |
| 12:15 |
Stompro |
mrpeters: tsbere: It was fun watching the process of fixing bug 506689, I spent a couple hours looking at that last week trying to track it down based on how the stat cats are displayed. Catching up after being in a meeting all day yesterday. |
| 12:15 |
pinesol_green |
Launchpad bug 506689 in Evergreen "Patrons > Identification Type > (Sort order)" (affected: 2, heat: 12) [Wishlist,In progress] https://launchpad.net/bugs/506689 |
| 12:16 |
tsbere |
Stompro: I kindof stumbled into the solution on accident and went "hey, will that work here?" and it did. |
| 12:16 |
mrpeters |
glad to hear it Stompro -- all credit to tsbere, i was way off base |
| 12:16 |
mrpeters |
dug all the way to the bottom of the perl code for nothin :P |
| 12:17 |
|
montgoc1 joined #evergreen |
| 12:17 |
* mrpeters |
is determined to actually fix something today...its been too log |
| 12:20 |
mrpeters |
looking at https://bugs.launchpad.net/evergreen/+bug/978040 now -- i've got it throwing up a window.alert("No users were found with that database id. Please try again."); in the blank obj.set_tab() (portal page) but its always appearing, i need to get an else in there so that if usr_id = '' or usr_id is not a number it throws the window alert, and leave things alone and open the patron tab if the database id is found |
| 12:20 |
pinesol_green |
Launchpad bug 978040 in Evergreen "No result found search for patron by database id results in return to wrong interface" (affected: 1, heat: 6) [Low,Confirmed] |
| 12:20 |
mrpeters |
im just not sure menu.js has access to the database to query and find out if the entered au.id exists |
| 12:21 |
tsbere |
mrpeters: menu.js has a lot of things it can do.....but the question is more "is that the place to do the check" |
| 12:21 |
mrpeters |
i think it would have to be, to prevent loading the search for patron by barcode tab on an invalid id (which just throws "DATABASE_QUERY_FAILED" now |
| 12:22 |
mrpeters |
so the error message is even less helpful in current master |
| 12:23 |
mrpeters |
im at http://pastie.org/9732735 now -- which is good, i know my window.alert will work, i just need to move it to a proper location since it shows up on a valid, and invalid au.id right now |
| 12:30 |
tsbere |
mrpeters: What interface are we aiming to return to? |
| 12:30 |
Stompro |
mrpeters: Bug 1124498 - I have this almost tested after adding in the repeat delay bit. An event is generated but stays in collected state, just need to figure out how to get it to move on from there. |
| 12:30 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 4, heat: 30) [Wishlist,In progress] https://launchpad.net/bugs/1124498 - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 12:31 |
tsbere |
mrpeters: I will point out that the "interface" you seem to want (prompt for another ID) isn't actually an "interface" at all... |
| 12:31 |
mrpeters |
tsbere: it is the "Search" > "Retreieve patron by Database ID" |
| 12:31 |
mrpeters |
and you are right, it is just a prompt |
| 12:31 |
|
jihpringle joined #evergreen |
| 12:33 |
mrpeters |
http://pastie.org/9732760 -- i think this is an improvement, since it would throw a helpful error message if you enter non-numeric or an empty field |
| 12:34 |
tsbere |
If you want to get at that prompt you would have to pass it down into the windows from menu.js - Specifically, make the cmd_search_usr_id oncommand available (somehow) from inside of the patron tab area...which is easier said than done, I think, then set a flag to say that is how you got to the bad user ID in the same function (because that is the *wrong* behavior if something else causes it) |
| 12:34 |
mrpeters |
so, i need to figure out where cmd_search_usr_id passes the prompt to make it query the database |
| 12:35 |
tsbere |
mrpeters: cmd_search_usr_id doesn't query the database. Ever. It just says "oh, hey, patron display interface, please load this patron by ID" - The latter then goes "Er, that ID wasn't found" and bounces you out to the normal entry point for it, which happens to be the barcode entry box. |
| 12:36 |
mrpeters |
so wouldnt it be acceptable to bounce you to a window.alert and the portal page for the entry point? |
| 12:36 |
mrpeters |
if invalid |
| 12:36 |
tsbere |
mrpeters: I could argue "send them to patron search instead" but the amount of work to re-make the prompt isn't worth it. :P |
| 12:37 |
mrpeters |
yeah, that would be a fair redirect too. from the way the code looks, i think this might have just been a quick add for someone who was testing something |
| 12:37 |
tsbere |
mrpeters: Basically, "send them to something else, with that something else being uniform across the board" would be fairly easy. Making it know how you got there and sending you back, including to a prompt that isn't even a page, not so much. |
| 12:38 |
tsbere |
mrpeters: Note that the functionality exists (beyond the menu item) for things like "load patron from the hold/circ/whatever" type menus. So whatever is changed needs to take those into account as well, so you can't just make it always prompt for a new ID (or barcode). |
| 12:39 |
tsbere |
Which is why it goes to the main barcode entry box, I think. >_> The menu item causing it to do that is just pre-existing functionality triggering on bad inputs. |
| 12:39 |
mrpeters |
well, lets see. cmd_patron_search already redirects you to the patron search interface |
| 12:39 |
mrpeters |
this does an obj.set_patron_tab just like cmd_patron_search does, but it tries to pass the id you entered |
| 12:40 |
mrpeters |
maybe that is why it jumps to barcode search, and not just back to the full patron search? |
| 12:41 |
mrpeters |
hmm interseting, the search by barcode isnt even defined in menu.js, at least not under the /* Search Menu */ section |
| 12:42 |
|
jihpringle joined #evergreen |
| 12:43 |
tsbere |
mrpeters: I think some of what you are seeing is because "patron search" and "load patron" are, on the surface, the same interface. Patron search has no ID or barcode provided, load patron has an id or barcode provided. |
| 12:44 |
tsbere |
The interface determines which one to load based on if it was given input or not, basically |
| 12:44 |
mrpeters |
ok, that makes sense -- i do notice that it appears to load the same interface but quickly flips to the actual patron record if valid |
| 12:46 |
mrpeters |
and in all reality, we have to pass it the usr_id in order for the retrieve by id to work at all, so throwing a popup if you enter an illegal database id format would help, but it wouldnt handle the original issue reported -- you'd still get DATABASE_QUERY_FAILED as long as the format of your id is "valid" |
| 12:46 |
mrpeters |
which wouldnt be much of an improvment i guess |
| 12:56 |
|
nhilton_ joined #evergreen |
| 12:57 |
|
dreuther joined #evergreen |
| 13:00 |
Stompro |
kmlussier++ for pointing out the google doc that mmorgan++ created on getting the 30 day pre expire notice working. The Processing Group Context Field needs to be blank, not set to usr. |
| 13:02 |
mrpeters |
oh, nice you guys were able to create that? |
| 13:03 |
mrpeters |
and keep it recurring? |
| 13:07 |
mmorgan |
Stompro: Glad the notes helped! |
| 13:07 |
mmorgan |
we have not yet implemented it, but it worked in testing |
| 13:08 |
mmorgan |
assuming the recurrence will work based upon the interval that now be set in the action trigger. |
| 13:10 |
kmlussier |
mmorgan: What did you set the interval at? I know Stompro asked a question back on what a good interval would be, and I suggested 30 days. |
| 13:10 |
kmlussier |
s/back/a while back |
| 13:13 |
mmorgan |
so I guess that's actually "Event Repeatabilty Delay"? |
| 13:14 |
mmorgan |
didn't actually set that because we don't have it in production, but I would say that it may depend on your expiration date interval. |
| 13:33 |
|
RoganH joined #evergreen |
| 13:35 |
|
vlewis joined #evergreen |
| 13:50 |
|
chatley joined #evergreen |
| 13:51 |
|
nhilton joined #evergreen |
| 13:55 |
|
bbqben joined #evergreen |
| 13:57 |
bbqben |
hi all - JFYI that the EOB meeting starts here @ the top of the hour. cheers |
| 14:00 |
|
abneiman joined #evergreen |
| 14:01 |
bbqben |
ok, here we go |
| 14:01 |
bbqben |
#startmeeting Evergreen Oversight Board Meeting, 20.11.14 |
| 14:01 |
pinesol_green |
Meeting started Thu Nov 20 14:01:15 2014 US/Eastern. The chair is bbqben. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:01 |
pinesol_green |
The meeting name has been set to 'evergreen_oversight_board_meeting__20_11_14' |
| 14:01 |
bbqben |
#topic introductions |
| 14:01 |
RoganH |
#info RoganH = Rogan Hamby, SCLENDS |
| 14:01 |
csharp |
#info csharp = Chris Sharp, GPLS |
| 14:01 |
montgoc1 |
#info montgoc1 = Chauncey Montgomery, Consortium of Ohio Libraries |
| 14:01 |
bbqben |
#info bbqben = Ben Hyman, BC Libraries Co-op |
| 14:01 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 14:01 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Kent County Public Library |
| 14:02 |
graced |
#info graced is Grace Dunbar, Equinox |
| 14:02 |
bbqben |
Thanks all - noting that yboston will be late |
| 14:02 |
bbqben |
#topic 2. Minutes / Actions from last meeting |
| 14:03 |
bbqben |
#info http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-10-16-14.02.html |
| 14:03 |
|
akilsdonk joined #evergreen |
| 14:03 |
|
rfrasur joined #evergreen |
| 14:04 |
bbqben |
kmlussier - did you want to provide an update on code of consuct procedures? |
| 14:04 |
kmlussier |
Sure |
| 14:04 |
kmlussier |
We have work-in-progress draft procedures at https://docs.google.com/document/d/1J6v_EytMv3vQfFQ9QcLh_3M4knSIC671GnMaYt8qVRs/edit?usp=sharing |
| 14:05 |
kmlussier |
And at https://docs.google.com/document/d/1ZhBsQvudCcEa06DD3L7Id086pb_FkeGh31WI9HNca1Y/edit?usp=sharing |
| 14:05 |
kmlussier |
I don't think their quite ready to be finalized yet. |
| 14:05 |
bbqben |
you've all been busy! |
| 14:05 |
kmlussier |
But I do think we all agree that we would like to have some volunteer safety staffers to be available to handle reports. |
| 14:06 |
kmlussier |
bbqben: There was a lot of copying and pasting from the PyCon procedures. :) |
| 14:06 |
kmlussier |
dbs++ for sharing those with me. |
| 14:06 |
bbqben |
kmlussier++ |
| 14:06 |
rfrasur |
(everybody clicks the link) |
| 14:06 |
bbqben |
anyone have comments for kmlussier et al? |
| 14:06 |
kmlussier |
I was thinking it might be good to solicit volunteers now so that they can be involved in the finalization of procedures. Also, after they get trained, I imagine there will be more adjustment of the procedures. |
| 14:07 |
bshum |
#info bshum = Ben Shum, Bibliomation |
| 14:07 |
montgoc1 |
kmlussier: that's a good idea. They may have some good ideas to refine the procedures. |
| 14:07 |
kmlussier |
abneiman++ montgoc1++ gmcharlt++ csharp++ for helping with the procedures |
| 14:07 |
rfrasur |
kmlussier: can we edit that? |
| 14:08 |
csharp |
kmlussier++ # herding cats |
| 14:08 |
montgoc1 |
Especially if they have some experience, training, etc. |
| 14:08 |
* rfrasur |
doesn't touch without permission. |
| 14:08 |
kmlussier |
rfrasur: I just gave permission for people with the link to comment, which I *think* means you can edit in suggesting mode. |
| 14:08 |
kmlussier |
It helps us more easily track any changes that are made. |
| 14:09 |
rfrasur |
I can technically...but it more of an ettiquette question (that seems like too many t's) |
| 14:09 |
kmlussier |
rfrasur: Yes. :) |
| 14:09 |
bbqben |
#action kmlussier to call for volunteers re: penultimate code of conduct procedures |
| 14:10 |
rfrasur |
(oh, I just crashed a meeting...sorry...talk about bad ettiquette). |
| 14:11 |
bbqben |
rfrasur++ |
| 14:11 |
bbqben |
:) |
| 14:11 |
bbqben |
moving on in 5... |
| 14:11 |
rfrasur |
(I'm ashamed) |
| 14:11 |
bbqben |
#topic Financial Report |
| 14:11 |
bbqben |
#info #info http://list.evergreen-ils.org/pipermail/eg-oversight-board/2014-November/000928.html |
| 14:12 |
bbqben |
oops |
| 14:12 |
bbqben |
gmcharlt++ |
| 14:12 |
bbqben |
and noting no change since last |
| 14:12 |
bbqben |
so moving on... |
| 14:12 |
* gmcharlt |
jumps in to make a quick note that bshum is in the process of get the keys to the (financial reporting) kingdom |
| 14:12 |
gmcharlt |
*getting |
| 14:13 |
bshum |
gmcharlt: I did send an email, but I haven't gotten any action from bkuhn yet. I was going to poke again later today. |
| 14:13 |
kmlussier |
gmcharlt: Are you still planning to train us on the financial reporting kingdom? |
| 14:13 |
gmcharlt |
yep |
| 14:13 |
bbqben |
bshum++ gmcharlt++ |
| 14:13 |
bbqben |
#action bshum mastering the financial kingdom |
| 14:14 |
bbqben |
#topic Evergreen Conference Report |
| 14:14 |
bbqben |
noting that Buzzy isn't here - anyone else have an update? |
| 14:14 |
kmlussier |
The only update I have is that I'm looking at potential WordPress plug-ins that will allow us to handle registration on the Evergreen site. |
| 14:15 |
csharp |
oooooh |
| 14:15 |
csharp |
that sounds awesome |
| 14:15 |
bbqben |
aaaah |
| 14:15 |
kmlussier |
Which will save us from paying Eventbrite fees. |
| 14:15 |
csharp |
yeah, registration is always a bugaboo |
| 14:16 |
kmlussier |
I just pinged Tony Sebro to see how things are going with the contract, but he's not around. |
| 14:16 |
bbqben |
kmlussier - thanks on all fronts. registration via site would be a great addition |
| 14:16 |
bbqben |
moving on in 5... |
| 14:17 |
bbqben |
#topic Evergreen 2.8 Planning |
| 14:17 |
bshum |
#info berick is the new 2.8 release manager |
| 14:17 |
csharp |
berick++ |
| 14:17 |
graced |
berick++ |
| 14:17 |
csharp |
kcls++ |
| 14:17 |
kmlussier |
berick++ |
| 14:17 |
bbqben |
berick++ |
| 14:17 |
berick |
i'm around, but also on a call, so kind of distracted at the moment :) |
| 14:17 |
montgoc1 |
berick++ |
| 14:18 |
bshum |
#link http://markmail.org/message/4a7hfqmdox3rbbro (berick's email to the lists) |
| 14:18 |
bshum |
I added the link for the notes |
| 14:19 |
bshum |
I guess we'll have more soon once plans continue to be worked on :) |
| 14:19 |
bshum |
berick++ |
| 14:20 |
bbqben |
bshum++ |
| 14:20 |
bbqben |
moving on in 7.... |
| 14:21 |
bbqben |
and I'm going to mess with the agenda JIC yboston isn't here yet |
| 14:21 |
bbqben |
#topic Research design proposal |
| 14:21 |
bbqben |
#info http://list.evergreen-ils.org/pipermail/eg-oversight-board/2014-October/000900.html |
| 14:22 |
bbqben |
We had some feedback from the EOB, all positive, but wanted to check in formally today before issuing a letter of support for this to proceed |
| 14:23 |
RoganH |
No objections from me. |
| 14:23 |
abneiman |
Go for it |
| 14:23 |
|
yboston left #evergreen |
| 14:23 |
csharp |
no objections here either |
| 14:24 |
|
yboston joined #evergreen |
| 14:24 |
bbqben |
lets have some fun with a vote, while we're here then :) - standby |
| 14:25 |
bbqben |
#startvote Should the EOB issue a letter of support for Michelle Purcell to proceed with her research proposal re: Evergreen? Yes, No, Abstain |
| 14:25 |
pinesol_green |
Begin voting on: Should the EOB issue a letter of support for Michelle Purcell to proceed with her research proposal re: Evergreen? Valid vote options are Yes, No, Abstain. |
| 14:25 |
pinesol_green |
Vote using '#vote OPTION'. Only your last vote counts. |
| 14:25 |
RoganH |
#vote yes |
| 14:25 |
bshum |
#vote yes |
| 14:25 |
montgoc1 |
#vote Yes |
| 14:25 |
abneiman |
#vote yes |
| 14:25 |
bbqben |
#vote yes |
| 14:25 |
csharp |
#vote Yes |
| 14:25 |
kmlussier |
#vote Yes |
| 14:25 |
graced |
#vote Yes |
| 14:26 |
bbqben |
#endvote |
| 14:26 |
pinesol_green |
Voted on "Should the EOB issue a letter of support for Michelle Purcell to proceed with her research proposal re: Evergreen?" Results are |
| 14:26 |
pinesol_green |
Yes (8): kmlussier, abneiman, bbqben, graced, RoganH, montgoc1, csharp, bshum |
| 14:26 |
bbqben |
#action bbqben will issue the letter |
| 14:27 |
bbqben |
#topic Evergreen web FAQ development |
| 14:27 |
bbqben |
yboston - you able to hop in here? |
| 14:27 |
yboston |
not yet |
| 14:27 |
bbqben |
ok, we'll come back |
| 14:28 |
bbqben |
#topic new business |
| 14:28 |
bbqben |
he says, thinking there may be - anyone? |
| 14:28 |
kmlussier |
bbqben: I have something |
| 14:29 |
bbqben |
kmlussier - you have the floor |
| 14:29 |
kmlussier |
In case anyone missed it, we will have an intern working on a user interface style guide over the next few months as part of the OPW program. |
| 14:29 |
kmlussier |
You can read up on the details on the community blog. |
| 14:29 |
kmlussier |
#link http://evergreen-ils.org/welcome-julia-to-the-evergreen-opw-internship-program/ |
| 14:30 |
kmlussier |
dbwells and graced will be mentors for the project |
| 14:30 |
kmlussier |
dbwells++ graced++ |
| 14:31 |
bbqben |
intern++ ;) dbwells++ graced++ kmlussier++ |
| 14:32 |
bbqben |
any q's for kmlussier? |
| 14:32 |
graced |
julialima++ (the intern) |
| 14:33 |
bbqben |
ah, julialima++ |
| 14:33 |
csharp |
all_y'all++ |
| 14:33 |
kmlussier |
julialima++ |
| 14:33 |
bbqben |
moving on - any other new business? |
| 14:34 |
bbqben |
ok, circling back to yboston (and we can table until next time of the timing's still bad) |
| 14:34 |
bbqben |
*if* |
| 14:35 |
yboston |
I can talk now |
| 14:35 |
bbqben |
whoa |
| 14:35 |
bbqben |
graet - over to you |
| 14:35 |
yboston |
#topic vendor FAQ |
| 14:35 |
yboston |
#link http://evergreen-ils.org/dokuwiki/doku.php?id=faqs:evergreen_companies:faqs |
| 14:35 |
yboston |
Jason from ESI (phasefx) made a bunch of updates to my initial draft. I really like what he added. Feel free to add your own. |
| 14:36 |
yboston |
thatis basically it |
| 14:36 |
yboston |
any comments or questions? |
| 14:37 |
bshum |
Interesting. |
| 14:37 |
bshum |
yboston++ phasefx++ |
| 14:37 |
csharp |
yboston: looks like a great guide |
| 14:37 |
montgoc1 |
Looks good. Easy to follow. |
| 14:37 |
csharp |
yboston++ phasefx++ |
| 14:37 |
montgoc1 |
yboston++ phasefx++ |
| 14:38 |
graced |
yboston++ phasefx++ |
| 14:38 |
bbqben |
yboston++ phasefx++ |
| 14:38 |
kmlussier |
yboston++ phasefx++ |
| 14:38 |
bbqben |
#action (all) further suggestion and edits for vendor FAQ |
| 14:40 |
bbqben |
running ahead a bit today... |
| 14:40 |
bbqben |
#topic next meeting |
| 14:41 |
bbqben |
Looks like we meet 18 December - rough show of hands - will we achieve quorum that close to the holidays? |
| 14:41 |
bshum |
So far, so good for me. |
| 14:41 |
abneiman |
OK here |
| 14:41 |
graced |
I'll be here |
| 14:41 |
yboston |
good for me too |
| 14:41 |
kmlussier |
I'll be there |
| 14:41 |
montgoc1 |
I should be OK. |
| 14:42 |
bbqben |
me too, looks like we're covered then. |
| 14:42 |
graced |
(workaholics) |
| 14:42 |
csharp |
I'll be here too |
| 14:42 |
kmlussier |
graced: It's not like I'm planning to work on Christmas. :) |
| 14:42 |
bbqben |
Great, misery loves company - and y'all are good company :) |
| 14:43 |
graced |
fair enough, kmlussier :) |
| 14:43 |
abneiman |
We public services people are lucky to have any days in addition to Christmas off :) |
| 14:43 |
bbqben |
kmlussier - slacker ;) |
| 14:43 |
RoganH |
We have Christmas and Christmas Eve off, that's it. |
| 14:43 |
montgoc1 |
I'll be counting fine money on Christmas Eve until midnight at least. |
| 14:43 |
kmlussier |
Same here, but I'm taking a week's vacation too. |
| 14:44 |
kmlussier |
Same here on the getting Christmas and Christmas Eve off. Not on counting fine money. |
| 14:44 |
kmlussier |
montgoc1: That sounds like something Scrooge would be doing. ;) |
| 14:44 |
montgoc1 |
Perhaps a visit from ghosts later too. |
| 14:44 |
bbqben |
if I thought it'd help, we could vote on making a week mandatory paid vacation at xmas, Evergreen-wide |
| 14:45 |
csharp |
#vote Yes |
| 14:45 |
graced |
csharp++ |
| 14:46 |
bbqben |
:) |
| 14:46 |
bbqben |
Thanks for your time today, everyone - see you soon |
| 14:46 |
bbqben |
#endmeeting |
| 14:46 |
pinesol_green |
Meeting ended Thu Nov 20 14:46:20 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 14:46 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-11-20-14.01.html |
| 14:46 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-11-20-14.01.txt |
| 14:46 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-11-20-14.01.log.html |
| 14:46 |
bshum |
bbqben++ |
| 14:46 |
graced |
bbqben++ |
| 14:46 |
* csharp |
usually gets a lot of time off at Christmas so isn't complaining ;-) |
| 14:46 |
montgoc1 |
bbqben++ |
| 14:46 |
csharp |
bbqben++ |
| 14:46 |
kmlussier |
bbqben++ |
| 14:47 |
abneiman |
bbqben++ |
| 14:47 |
kmlussier |
remingtron_: Thanks for sending that reminder out. I somehow missed it when you first sent it. |
| 14:49 |
bshum |
serial.unit-- # woe is me :( |
| 14:49 |
kmlussier |
And there is the first e-mail sitting unread in my Inbox. :-/ |
| 14:51 |
bshum |
So I randomly ended up with an active undeleted entry in asset.copy and one in serial.unit with the same barcode. |
| 14:51 |
bshum |
And that caused, say... confusion for a bit. |
| 14:52 |
eeevil |
yeah, we just need to bite the bullet and add a trigger to both to protect against that |
| 14:53 |
kmlussier |
There's a bug in LP about that, isn't there? |
| 14:54 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1081551 |
| 14:54 |
pinesol_green |
Launchpad bug 1081551 in Evergreen 2.6 "No error message when using duplicate barcodes in Serials Batch receive interface" (affected: 6, heat: 28) [Undecided,New] |
| 14:54 |
eeevil |
kmlussier: aye. I have performance concerns, but we might be able to mitigate it with appropriate WHEN clauses on the triggers. |
| 14:55 |
kmlussier |
So the follow-up to that one is https://bugs.launchpad.net/evergreen/+bug/1362743 |
| 14:55 |
pinesol_green |
Launchpad bug 1362743 in Evergreen "No error message when using duplicate barcodes with Replace Barcode in Holdings Maitenance interface" (affected: 1, heat: 6) [Undecided,Confirmed] |
| 14:55 |
berick |
+1 to trigger, though |
| 14:57 |
* kmlussier |
's head starts to hurt whenever she sees the phrase 'performance concerns.' |
| 15:01 |
* mmorgan |
is confused about barcodes in asset.copy and serial.unit, same data seems to exist in both tables. Should the same barcode not exist in both tables? |
| 15:01 |
remingtron |
kmlussier: you're welcome. Just following the good example of other EG pollsters |
| 15:02 |
kmlussier |
mmorgan: In this case, they are two distinct items |
| 15:02 |
mmorgan |
ok, with different ids, I get it. |
| 15:13 |
eeevil |
kmlussier: just the overhead of running a trigger every single time a copy is updated (status change, etc) |
| 15:14 |
eeevil |
or, /another/ trigger, I should say. one that looks at another table |
| 15:16 |
kmlussier |
Yup. My head still hurts. |
| 15:16 |
kmlussier |
I'm not saying that it's better if the system allows us to use duplicate barcodes. :) |
| 15:17 |
kmlussier |
I just want a perfect world we not only fix a bug, but magically see improved performance. Am I asking too much? ;) |
| 15:17 |
jboyer-isl |
Having never looked at any serials code or tables, is there any value in making serials copies just "special" acp's, so the existing unique barcode constraint can be used as-is? |
| 15:18 |
jboyer-isl |
Note that I have no idea if that's even possible without a complete rewrite of the entire feature. |
| 15:18 |
* mmorgan |
thinks kmlussier is not asking too much :) |
| 15:24 |
dbwells |
jboyer-isl: I don't think it's out of the question to rethink the inherited table design. It did come with a long trail of gotchas which we perhaps didn't fully appreciate. I could think of a number of ways to move forward, but none I could confidently say "this will be easy!" |
| 15:26 |
jboyer-isl |
I'll have to admit I'm also a little light on details re: psql's inherited tables. (I did \d+ serial.unit and was very confused until I got to the Inherits: line) |
| 15:27 |
jboyer-isl |
Ah, I think child tables is the other feature I was thinking about, but that would make every acp look like a busted su, so that's no good. |
| 15:28 |
jboyer-isl |
dbwells++ for wading into those waters. |
| 15:32 |
dbwells |
If I were under threat to life and limb to redo it as effortlessly as possible, I'd probably first try to make it a more typical "might-have" style table with an acp.id FK, then explore making serial.unit an updatable view. My gut tells me something wouldn't work out the way I would hope, though. |
| 15:33 |
mrpeters |
dbwells: dont know if you saw, but tsbere used his magic to fix the sort order of that Ident Type field right back at the template toolkit level. Thank you for your help last night and this morning. Just wanted to make sure you saw, so you didn't waste time on me :) |
| 15:35 |
jboyer-isl |
It looks like the *_contents fields are the only addition to stock acp, could those just be moved to serial.item and that would then point to an acp instead of an su (which would be gone)? |
| 15:37 |
dbwells |
mrpeters: Thanks for letting me know. I figured you were trying to learn, so I was avoiding looking too deeply into the code. Glad it got worked out. |
| 15:37 |
mrpeters |
i indeed was, i wish i could have figured it out but tsbere saw a faster way and went on and fixed it |
| 15:38 |
mrpeters |
was a good lesson all the way down through the code clear to CDBI perl stuff though |
| 15:38 |
tsbere |
Had I not stumbled on the easy, quick, and correct solution and basically put the right code in place to test if the solution would even work I would have left it more to mrpeters ;) |
| 15:38 |
dbwells |
jboyer-isl: sitem to sunit is one-to-many |
| 15:38 |
mrpeters |
i think your suggestion would have worked for, say a srfsh request of the values |
| 15:38 |
mrpeters |
but i guess that tree unsorts things |
| 15:39 |
tsbere |
once again, a quick recap: The client fetches the data, gets the array, and then disregards the array order as it moves them into a hash based on the primary key of the table they came from. The hash thus has no ordering remaining. |
| 15:39 |
jboyer-isl |
dbwells, I see. I didn't look that closely. (It's probably safe to say that if the fix were that simple none of us would be having this discussion. :) ) |
| 15:40 |
mrpeters |
tsbere: do you agree that if you did a srfsh query with the order_by stuff in the perl would have ordered them alphabetically? |
| 15:40 |
mrpeters |
i'm looking for some silver lining that i might have at least done SOMETHING that was on the right track :P |
| 15:41 |
tsbere |
mrpeters: I have no doubt it likely would have. |
| 15:41 |
tsbere |
mrpeters: Just that once you are 3 layers further down the chain the original order ceased to matter ;) |
| 15:41 |
mrpeters |
cool, so it wasn't all in vain |
| 15:41 |
dbwells |
jboyer-isl: Yeah. We tried extra hard to make the serials stuff usable for every case, and thereby nearly unusable for any case :) |
| 15:44 |
mrpeters |
perl question -- http://pastie.org/9733087 trying to make sense of the $resp->content there -- is that just saying that as long as the timeout of 2 hours hasn't elapsed, continue to push the data that the API call (in this case, open-ils.collections.users_of_interest.retrieve) is sending into the @data variable? |
| 15:45 |
mrpeters |
i've got an old collections script that, for some libraries, dies out after about 5 minutes -- but if i translate the perl into a srfsh query, i get the json that i would expect to get |
| 15:45 |
mrpeters |
** content() isn't there. Please create me somewhere (like in OpenSRF::DomainObject::oilsMethodException)! is the error returned by the perl script |
| 15:45 |
mrpeters |
at line 23, which is line 1 of the pastie above |
| 15:48 |
berick |
mrpeters: that happens when the API call returns an exception and the script is not safely checking for an exception |
| 15:48 |
berick |
which this script is not doing |
| 15:48 |
mrpeters |
berick: ah, i bet you wrote this :P |
| 15:48 |
berick |
good chance |
| 15:48 |
mrpeters |
PINES collections |
| 15:49 |
mrpeters |
it stopped working a few weeks back for a few particular libraries |
| 15:49 |
berick |
though the script could be improved to better report the error, the real question is why are you getting a OpenSRF::DomainObject::oilsMethodException response. |
| 15:49 |
berick |
which shold be in the log |
| 15:50 |
mrpeters |
ah, you know what it sure is....at the bottom of my srfsh too |
| 15:50 |
mrpeters |
Received Exception: |
| 15:50 |
mrpeters |
Name: osrfMethodException |
| 15:50 |
mrpeters |
Status: *** Call to [open-ils.collections.users_of_interest.retrieve] failed for session [1416515351.333446.1416515351406], thread trace [1]: |
| 15:50 |
mrpeters |
Can't call method "barcode" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Application/Collections.pm line 299. |
| 15:53 |
mrpeters |
thanks berick -- i just wasn't seeing the end of the json response in srfsh because of how large it is |
| 15:54 |
tsbere |
mrpeters: I bet one of the "users of interest" has a null card. |
| 15:54 |
berick |
mrpeters: no problem. collection code might need to be taught how to process users that don't have cards. |
| 15:54 |
berick |
jinx |
| 15:54 |
mrpeters |
i think i know exactly what caused this, too. PINES did some mass patron merges and i wonder if this is trying to pull some of those subordinates |
| 15:55 |
|
nhilton_ joined #evergreen |
| 15:57 |
mrpeters |
evergreen=# SELECT count(id) FROM actor.usr WHERE card IS NULL; |
| 15:57 |
mrpeters |
count |
| 15:57 |
mrpeters |
------- |
| 15:57 |
mrpeters |
45899 |
| 15:57 |
mrpeters |
(1 row) |
| 15:57 |
mrpeters |
betcha that is it |
| 15:57 |
tsbere |
mrpeters: Note that deleted patrons generally have a null card. Adding an "AND NOT deleted" to the where clause might give you more info. |
| 15:58 |
mrpeters |
yeah, i think i can tweak this to not included null cards, or deleted patrons -- either way |
| 15:58 |
mrpeters |
a patron can only have a null card if deleted is true, right? because of db constraints? |
| 15:59 |
berick |
mrpeters: no, cards are not required |
| 15:59 |
kmlussier |
I wish I knew how to answer Matt Lewin's question just because I love the fact that he's developing an app for his daughter that talks to Evergreen. |
| 15:59 |
mrpeters |
oh , interesting. i thought they were. |
| 15:59 |
mrpeters |
kmlussier: which list? |
| 15:59 |
kmlussier |
open-ils-dev |
| 16:00 |
mrpeters |
will have to check that out |
| 16:00 |
|
nhilton joined #evergreen |
| 16:00 |
mrpeters |
i've been tossing around the idea of using evergreen (the opac especially) to create a "discography" for a particular musical artist, all of the varied UPC's, pressings, formats, etc. |
| 16:02 |
mrpeters |
kind of like discogs.com -- but my thought was to use 856 tag to include links to samples, etc. |
| 16:03 |
mrpeters |
may be way out in space on that idea though haha, but i think it could be a creative use for the software |
| 16:03 |
kmlussier |
mrpeters: I think that could be fun! |
| 16:04 |
mrpeters |
yeah, some friends were putting it together in a spreadsheet and i thought wait....we could use Evergreen for this |
| 16:04 |
mrpeters |
to make it searchable in many different ways, added content, etc. |
| 16:05 |
mrpeters |
that Matt Lewin question is pretty cool. Sounds like he just wants a little app to log in and retrieve what she has checked out and when it is due. |
| 16:07 |
|
bbqben joined #evergreen |
| 16:07 |
mrpeters |
or maybe this is more of a "have i already had this item" type of thing |
| 16:07 |
bshum |
Hmm |
| 16:07 |
bshum |
Seems we need a new perm for "COPY_STATUS_LOST_AND_PAID.override" |
| 16:08 |
bshum |
In order to check in those copies, I mean |
| 16:08 |
bshum |
Or otherwise use them again |
| 16:11 |
|
akilsdonk_ joined #evergreen |
| 16:11 |
|
bbqben joined #evergreen |
| 16:12 |
kmlussier |
bshum: But if you can't check them in, then a negative balance can't be created. ;) |
| 16:12 |
kmlussier |
Some people may see that as a postive. |
| 16:12 |
kmlussier |
positive even |
| 16:12 |
bshum |
kmlussier: Yeah literally that's what jventuro said once I granted the permission to her. |
| 16:12 |
bshum |
"aww, negative balances aren't fixed yet" |
| 16:12 |
bshum |
No, no, they're not :( |
| 16:15 |
jeff |
heh |
| 16:16 |
mmorgan |
negative_balances-- |
| 16:17 |
mrpeters |
would adding to Collections.pm, something like; my $usr = $e->search_actor_usr({deleted != {1}, {}}) take care of deleted users appearing in the "users_of_interest"? |
| 16:18 |
tsbere |
mrpeters: I would be more concerned with non-deleted users with null cards. Or rather, null cards in general. Oh, and you will need different syntax there either way. Generally, look for where barcode is being referenced and protect against "there is no barcode". |
| 16:18 |
phasefx |
kmlussier: re: cards, I think a card is needed for the patron display to populate correctly |
| 16:19 |
mrpeters |
tsbere: i think someone just mentioned that a null card is ok |
| 16:19 |
mrpeters |
(3:59:21 PM) berick: mrpeters: no, cards are not required |
| 16:19 |
kmlussier |
Cards? |
| 16:19 |
mrpeters |
he may have meant that for me, kmlussier |
| 16:20 |
phasefx |
kmlussier: mrpeters: fuzzy vision :) |
| 16:20 |
tsbere |
mrpeters: "null card is ok" != "the code is handling it ok" - Your error seems to indicate that the code is blindly saying "every patron has a card" |
| 16:20 |
mrpeters |
heh no worries |
| 16:20 |
mrpeters |
it does seem that Collections.pm does assume that |
| 16:20 |
tsbere |
mrpeters: You need to find where that blindly looking for a card is happening and wrap a protective statement around it |
| 16:20 |
kmlussier |
mrpeters / phasefx: Ok, thanks! |
| 16:20 |
kmlussier |
:) |
| 16:21 |
tsbere |
mrpeters: If you see a ->{card}->{barcode} or similar in there.... |
| 16:22 |
mrpeters |
yeah, im not seeing that -- http://pastie.org/9733176 is the method in question |
| 16:22 |
tsbere |
mrpeters: Or, in this case, $u->card->barcode, I think, in "process_users_of_interest_results" - That assumes that the user has a non-null card |
| 16:22 |
mrpeters |
hmm, im not seeing that |
| 16:23 |
tsbere |
line 298 in master? |
| 16:23 |
mrpeters |
ah, im looking further up |
| 16:24 |
mrpeters |
i see it now |
| 16:25 |
mrpeters |
i was thinking that method was all done -- didn't notice this other sub to process the results |
| 16:25 |
tsbere |
mrpeters: You need to protect that call to ensure that if card isn't defined then it doesn't go looking for a barcode on it. |
| 16:26 |
* tsbere |
can think of multiple ways of doing that off the top of his head, but will let mrpeters figure this out for the time being ;) |
| 16:26 |
mrpeters |
ok, great stuff -- yes, thank you for that |
| 16:32 |
mrpeters |
can i wrap a defined() around $u->card->barcode on 298? |
| 16:32 |
mrpeters |
that would filter out any null cards, i beleive |
| 16:47 |
tsbere |
mrpeters: I don't think that will help because it is still going to try and pull a barcode out of card first. ;) |
| 16:47 |
mrpeters |
yeah, it didnt work |
| 16:48 |
mrpeters |
was worth a shot:) |
| 16:48 |
tsbere |
mrpeters: Hint hint nudge nudge http://perldoc.perl.org/perlop.html#Conditional-Operator |
| 16:48 |
mrpeters |
we do have to pull a card, i know that much |
| 16:49 |
mrpeters |
tsbere++ AWESOME --- sometimes it feels like looking up how to spell a word in a dictionary -- haha if you don't quite know how to spell it, how are you going to find it in the dictionary :) |
| 16:50 |
mrpeters |
but pointing to something i can study like that rocks, thank you |
| 16:50 |
tsbere |
mrpeters: And for more hint hint nudge nudge stuff: You want to check if card is defined, not barcode. ;) |
| 16:50 |
mrpeters |
ah yes, right |
| 16:51 |
|
kmlussier left #evergreen |
| 16:51 |
mrpeters |
should i be focused on the my $u = $e->retrieve_actor_user block, or the hash of usr? |
| 16:52 |
tsbere |
mrpeters: I would be focused on the very line that has card->barcode in it. That would be the only one I would touch for my primary thought on how to resolve the issue. |
| 16:52 |
mrpeters |
cool. ill figure this out and push a patch once my ssh keys are straightened out |
| 16:57 |
mrpeters |
barcode => $u->(card >= undef)? "Card cannot be null" : ->barcode, perhaps? |
| 16:58 |
|
bbqben joined #evergreen |
| 16:58 |
mrpeters |
though, im not sure about what the proper failure action should be if card is undefined |
| 16:58 |
tsbere |
mrpeters, closer, but no. |
| 16:58 |
|
nhilton_ joined #evergreen |
| 16:59 |
tsbere |
Something closer to this, with the empty string being the "there is no barcode" string: defined($u->card) ? $u->card->barcode : '' |
| 16:59 |
tsbere |
(put into the correct slot in the code, obviously, I didn't include the entire line....and it is 100% untested, I may have screwed something up I am not seeing) |
| 16:59 |
mrpeters |
no no, this helps |
| 17:00 |
* tsbere |
leaves mrpeters with that and goes home for the day ;) |
| 17:00 |
mrpeters |
so we're saying, if $u->card is defined, then we can move on with the code |
| 17:00 |
mrpeters |
thank you, sincerely, tsbere |
| 17:01 |
tsbere |
mrpeters: (bool op) ? do this if true : do this if false |
| 17:01 |
mrpeters |
got it |
| 17:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:46 |
mrpeters |
great success! high five! tsbere++ berick++ |
| 17:46 |
mrpeters |
will push dee848f HEAD@{0}: commit: Make users_of_interest test for defined actor.usr.card values to working once my SSH keys are updated |
| 18:05 |
|
mnsri joined #evergreen |
| 18:11 |
|
nhilton joined #evergreen |
| 18:13 |
|
dreuther_ joined #evergreen |
| 18:30 |
|
dreuther joined #evergreen |
| 18:31 |
|
wsmoak joined #evergreen |
| 18:32 |
|
nhilton_ joined #evergreen |
| 19:00 |
|
nhilton joined #evergreen |
| 19:30 |
|
bbqben joined #evergreen |
| 20:11 |
|
StomproJ joined #evergreen |
| 21:48 |
|
dcook joined #evergreen |
| 22:09 |
|
nhilton joined #evergreen |
| 22:33 |
|
bbqben joined #evergreen |
