| Time |
Nick |
Message |
| 06:58 |
|
Mark__T joined #evergreen |
| 07:53 |
|
rjackson_isl joined #evergreen |
| 07:56 |
|
rlefaive joined #evergreen |
| 08:15 |
|
Dyrcona joined #evergreen |
| 08:27 |
|
mrpeters joined #evergreen |
| 08:35 |
|
mmorgan1 joined #evergreen |
| 08:45 |
|
krvmga_ joined #evergreen |
| 08:47 |
Dyrcona |
@tea |
| 08:47 |
* pinesol_green |
brews and pours a pot of Huang Shan Mao Feng Green Tea, and sends it sliding down the bar to Dyrcona (http://ratetea.com/tea/teavivre/huang-shan-mao-feng-green-tea/6041/) |
| 08:58 |
|
ericar joined #evergreen |
| 09:09 |
|
maryj joined #evergreen |
| 09:12 |
|
yboston joined #evergreen |
| 09:22 |
kmlussier |
Dyrcona: That's the same tea I was just given in the code4lib channel. Cheers! |
| 09:22 |
* Dyrcona |
doesn't hangout in code4lib. It was too "nosiy." |
| 09:22 |
Dyrcona |
noisy, even. |
| 09:43 |
|
Shae joined #evergreen |
| 10:54 |
|
Christineb joined #evergreen |
| 10:59 |
|
vlewis joined #evergreen |
| 10:59 |
|
vlewis_ joined #evergreen |
| 11:29 |
* tsbere |
is looking at the queue position information and is sorely tempted to comment out the actual checks and replace the returned value with a hardcoded "*shrug*" |
| 11:30 |
miker |
tsbere: I wouldn't fault you. hold order is non-deterministic WRT actual capture order, for reasons. :) |
| 11:30 |
dbs |
Heh. Or maybe @dice |
| 11:30 |
dbs |
@dice 1d10 |
| 11:30 |
pinesol_green |
dbs: 1 |
| 11:30 |
dbs |
YES |
| 11:31 |
tsbere |
miker: For added fun, the existing logic has a flaw as well. I am also trying to decide if I should make a branch to fix that or see about making a wholesale replacement instead. <_< |
| 11:32 |
miker |
tsbere: depends on if the flaw is significant ... there won't be a replacement that is both performant and correct, I feel quite certain. |
| 11:33 |
tsbere |
miker: When there are no copy maps it looks for holds by target/type, ignoring canceled, captured, and expired holds. The flaw is not checking for filled as not all filled holds are captured. |
| 11:34 |
miker |
hrm... how does a hold have a fulfillment time but no capture time? |
| 11:34 |
tsbere |
checkout fills related hold |
| 11:34 |
tsbere |
or at least that is my assumption based on what I am seeing |
| 11:35 |
miker |
hrm... that should set capture time, IM(strong)O ... I'd consider it a bug if it didn't |
| 11:35 |
* mmorgan1 |
would agree with miker. |
| 11:35 |
miker |
in fact, I'd say the data fix for that would be to set the capture time to the fulfillment time where it's null, at upgrade |
| 11:38 |
tsbere |
Well, that should probably be done to aged holds too if it is done |
| 11:45 |
miker |
agreed |
| 11:46 |
jeff |
current code sets capture_time on a hold at "checkout fills related hold" time, unless there is already a capture time set on the hold. |
| 11:46 |
jeff |
(which isn't to say that there aren't corner cases or bugs that could still result in capture_time not being set for some reason) |
| 11:46 |
miker |
a fulfilled hold should always be captured ... we could use the bludgeon of a trigger to enforce that |
| 11:47 |
jeff |
i have five holds with a fulfillment_time and no capture_time. most recent fulfillment_time was last month. |
| 11:49 |
* mmorgan |
has 415 such holds |
| 11:50 |
mmorgan |
Three of those were filled 2 days ago. |
| 11:52 |
tsbere |
We have over 500 total, most aged at this point, most recent couple were the beginning of this week. |
| 11:53 |
csharp |
PINES has 158 hold requests with null capture_time non-null fulfillment time, FYI |
| 11:53 |
csharp |
*and* non-null... |
| 11:58 |
|
Callender joined #evergreen |
| 12:00 |
tsbere |
Well, given that our current installed code supposedly sets capture time as well when filling on that setting I am at a bit of a loss on figuring out what is going on there. |
| 12:01 |
mmorgan |
Hmm. Many of these non-captured-but-fulfilled holds also have a cancel_time. |
| 12:02 |
|
dMiller_ joined #evergreen |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:02 |
jeff |
stale staff interface actions? |
| 12:02 |
jeff |
staff clearing a holdshelf based on loaded data that no longer reflects reality? |
| 12:06 |
Bmagic |
Can anyone confirm that holds placed vua "request item" from the holds screen results in blank information on the hold slip upon capture? |
| 12:08 |
Bmagic |
/vua/via |
| 12:08 |
mmorgan |
81 holds that have both a fulfillment time and a cancel time. For most, cancel and fulfill differ by a fraction of a second. |
| 12:09 |
bshum |
Bmagic: That sounds familiar. |
| 12:09 |
Bmagic |
I must not have enough coffee in my blood. /holds screen/item status screen |
| 12:10 |
kmlussier |
@coffee Bmagic |
| 12:10 |
* pinesol_green |
brews and pours a cup of Kenya AA, and sends it sliding down the bar to Bmagic |
| 12:10 |
Bmagic |
thanks! |
| 12:10 |
mmorgan |
Bmagic: Isn't Request Item a booking function? |
| 12:10 |
jeff |
most recent example here shows the hold was reset shortly after checkout. |
| 12:11 |
Bmagic |
mmorgan: oh? Honestly, I didn't know how this feature worked. One of our branches started placing holds this way, and noticed the issue. |
| 12:11 |
Bmagic |
mmorgan: so, this is by design then? Not really the way libraries should place traditional holds |
| 12:12 |
bshum |
My recollection is that it'll put values for notification in if the user has them set in their account |
| 12:12 |
bshum |
But not by default otherwise |
| 12:12 |
bshum |
But I might be wrong. |
| 12:13 |
Bmagic |
bshum: aparently, their defaults are not filled out either |
| 12:14 |
bshum |
mmorgan: Bmagic is referring to the "Item Hold/Recall/Force" GUI which can create copy holds, among the others. |
| 12:15 |
bshum |
But yeah, I think we told people to avoid using that interface for making those holds. |
| 12:15 |
Bmagic |
so it's not a bug then? |
| 12:16 |
bshum |
Bmagic: It's really for staff-related functionality, not patrons. It depends on whether you view it as a bug aka incomplete feature, or it's built as designed and therefore it's as complete as they originally wanted it to be based on what they planned to use it for. |
| 12:16 |
bshum |
Bmagic: If you want to file something and then work on a solution, that'd be awesome though ;) |
| 12:17 |
bshum |
(But in the meantime, I recommend telling your library to shy away from that interface) |
| 12:17 |
* bshum |
doesn't expect it to get fixed quickly |
| 12:18 |
Bmagic |
bshum: right on. I was sorta hoping it wasn't a bug |
| 12:18 |
Bmagic |
So that I could tell them that it's by design |
| 12:19 |
|
mllewellyn joined #evergreen |
| 12:19 |
bshum |
Bmagic: You can tell them whatever you think is best ;) |
| 12:19 |
bshum |
Personally I view that interface as intended primarily to perform the staff recall functions. |
| 12:19 |
bshum |
Having the ability to place copy holds there is still mostly for staff |
| 12:20 |
bshum |
(purposes) |
| 12:20 |
bshum |
But /shrug |
| 12:20 |
jeff |
none of my fulfilled-but-not-captured holds have a cancel_time set. |
| 12:21 |
Bmagic |
hmmmm, well, it certainly could* place the hold with the specified patron's defaults in the email_notify, sms_notify, sms_carrier buuuuut, I think perhaps it's not a big enough deal to just place the hold the "correct" way |
| 12:23 |
|
dMiller_ joined #evergreen |
| 12:39 |
* mmorgan |
catches up. |
| 12:39 |
miker |
the patron hold interface allows selection/editing of hold notice info per hold, while the "quick" interface does not |
| 12:39 |
miker |
so, using the defaults is "stronger" than what the normal interface does |
| 12:40 |
miker |
we erred on the side of not guessing intent for notification when they would normally get to disable it, but not in this interface |
| 12:40 |
miker |
IOW, it's by design |
| 12:40 |
miker |
(he says after reading up) |
| 12:40 |
miker |
Bmagic: -^ |
| 12:42 |
mmorgan |
So, in the 'quick' interface, there's no notification to the patron at all. |
| 12:42 |
miker |
well, it's a staff interface, AIUI, right? |
| 12:43 |
mmorgan |
Sure, but a patron barcode can be entered there. |
| 12:45 |
miker |
right ... the UI could be expanded, but then it wouldn't be very quick :) ... but I do recall the argument for not guessing at notification settings, fwiw |
| 12:45 |
miker |
IOW, yes, it's by design |
| 12:48 |
mmorgan |
Ok. It's not an interface that we encourage our libraries to use, though I'm sure some have discovered it. Good to know that there's no notification built in there. |
| 12:50 |
miker |
FWIW, the main use case was for non-circ folks to use for force and recall holds. copy holds (useful for patrons) was added because it is essentially the same, so it was cheap to add |
| 12:52 |
miker |
(that's my recollection of the use case, anyway ... it's been, um, a while) |
| 12:52 |
mmorgan |
miker: Thanks, also good to know. So is the target for holds place this way always a copy id? |
| 12:53 |
miker |
mmorgan: yes indeed |
| 12:53 |
Bmagic |
miker++ bshum++ mmorgan++ |
| 12:54 |
mmorgan |
Gotcha. Thanks. |
| 13:14 |
|
ericar joined #evergreen |
| 13:24 |
* jeff |
looks once more at one of those fulfilled but not captured holds |
| 13:27 |
* mmorgan |
got pulled in other directions, but wonders if the fulfilled but not captured holds has something to do with transits. |
| 14:25 |
jeff |
mmorgan: it's interesting to me that we have such a low number compared with others. |
| 14:27 |
|
Callender joined #evergreen |
| 14:28 |
|
Callender left #evergreen |
| 14:29 |
|
Callender joined #evergreen |
| 14:37 |
mmorgan |
jeff: true. also interesting in the precat discussion yesterday that you have many fewer of those. |
| 14:51 |
|
bmills joined #evergreen |
| 15:23 |
* bshum |
hates on search_path |
| 15:24 |
bshum |
I was like, why can't it find that function? Oh right... |
| 15:27 |
bshum |
0945 is not a happy camper |
| 15:27 |
bshum |
DETAIL: view reporter.classic_current_billing_summary depends on view reporter.demographic |
| 15:27 |
bshum |
view reporter.classic_current_circ depends on view reporter.demographic |
| 15:27 |
bshum |
So if you use the reporter extensions from PINES, that'll break that script. |
| 15:27 |
bshum |
Guess we have to drop that other view too and then recreate it. |
| 15:28 |
bshum |
Or alter how it's created. |
| 15:28 |
bshum |
Comes from - https://bugs.launchpad.net/evergreen/+bug/838525 |
| 15:28 |
pinesol_green |
Launchpad bug 838525 in Evergreen "Timestamp on dob can make date appear off by a day" [Medium,Fix committed] |
| 15:29 |
bshum |
Think I should add a note on that bug and reopen it, or start a new one? (I imagine we need to modify the content in 0945 to account for things) |
| 15:30 |
Dyrcona |
Ah... You know what. I think that may have broke my actor.usr_auditor, too. |
| 15:31 |
Dyrcona |
ERROR: type of parameter 39 (date) does not match that when preparing the plan (timestamp with time zone) |
| 15:32 |
Dyrcona |
That came after I tried an actor.usr update just a little bit ago. |
| 15:32 |
bshum |
Yuck. |
| 15:32 |
Dyrcona |
It's the weird error that I mentioned to you in private chat. |
| 15:32 |
* bshum |
decides to rollback these changes for now and avoid them during his upgrade weekend. |
| 15:33 |
bshum |
New master (okay, 2.9.0-ish) tomorrow night! |
| 15:33 |
Dyrcona |
I updated a bunch of users this morning with no problem, but I don't think they had birth dates. |
| 15:33 |
bshum |
In that case, with your finding and mine I think we should re-open that original bug and get some fixes to complete things. |
| 15:33 |
bshum |
With the caveat that master is a bit borked right now |
| 15:34 |
Dyrcona |
Sounds good, or open a new ticket. |
| 15:34 |
* bshum |
could open a new ticket too |
| 15:35 |
bshum |
But that ticket would be called bug 838525 broke stuff :) |
| 15:35 |
pinesol_green |
Launchpad bug 838525 in Evergreen "Timestamp on dob can make date appear off by a day" [Medium,Fix committed] https://launchpad.net/bugs/838525 |
| 15:35 |
* bshum |
could call it that. |
| 15:41 |
Dyrcona |
Well, that's special. Can't just alter the column on auditor.actor_usr_history, 'cause a rule and/or a view depend on it. |
| 15:41 |
bshum |
Dyrcona: I decided to reopen the original bug and added a comment on my issue. |
| 15:41 |
bshum |
Dyrcona: Please feel free to add notes on what you're finding for auditor there too. |
| 15:41 |
bshum |
Ugh. |
| 15:42 |
tsbere |
On the broken auditor bit: There is an update auditors function, but I dunno if it fixes types... |
| 15:43 |
tsbere |
It was more intended for new columns being added |
| 15:44 |
|
jlitrell joined #evergreen |
| 15:45 |
bshum |
google_drive-- |
| 15:45 |
bshum |
Their outage is annoying me |
| 15:47 |
Dyrcona |
So, kmlussier, circ is fixed on my development machine, but updating users is apparently borked. |
| 15:48 |
bshum |
Bleh :( |
| 15:51 |
Dyrcona |
tsbere++ |
| 15:51 |
Dyrcona |
https://bugs.launchpad.net/evergreen/+bug/838525/comments/24 |
| 15:51 |
pinesol_green |
Launchpad bug 838525 in Evergreen "Timestamp on dob can make date appear off by a day" [Medium,Triaged] |
| 15:51 |
bshum |
tsbere++ |
| 15:51 |
Dyrcona |
And updating users is unborked. |
| 15:52 |
tsbere |
Apparently I made it more robust than I thought. Yay me! |
| 15:52 |
* tsbere |
forgets the full details of what he was breaking when he wrote it, though |
| 16:12 |
Dyrcona |
Hmm. Maybe a better fix for the auditor problem in 0945 is to alter the auditor table while the lifecycle view is dropped. |
| 16:13 |
Dyrcona |
Wonder if the function would then be a problem..... |
| 16:13 |
|
dMiller_ joined #evergreen |
| 16:13 |
Dyrcona |
Guess if I look into it, it will wait for Tuesday. |
| 16:26 |
pinesol_green |
[evergreen|Remington Steed] Docs: Rename bullet images to fix epub build error - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=08f8938> |
| 16:26 |
pinesol_green |
[evergreen|Remington Steed] Release Notes: Move/copy relevant sections to Upgrade Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e19a01d> |
| 16:54 |
Bmagic |
Im trying to find the glue for secondary permission groups in the database. This commit http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ef04f72cf613b0c31cc6a42bd46e609f1a0d5323 refers to permission.usr_grp_perm_map which doesnt exist in our database |
| 16:54 |
pinesol_green |
[evergreen|James Fournie] Add multiple permission groups editor to user registration form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ef04f72> |
| 16:57 |
jeff |
Bmagic: should probably be permission.usr_grp_map |
| 16:57 |
Bmagic |
ha! I just realized the date is 2012. That's probably not around. Are the secondary permissions simply in permission.usr_grp_map ? |
| 16:57 |
jeff |
i believe permission.usr_grp_perm_map is just a typo in the commit message. |
| 16:58 |
Bmagic |
jeff: thanks! I don't know why I was confused! jeff++ |
| 16:58 |
* Dyrcona |
agrees with jeff. |
| 16:58 |
Dyrcona |
The secondary groups are indeed in permission.usr_grp_map. |
| 16:59 |
jeff |
The Javascript UI in that commit uses the API call open-ils.actor.user.set_groups to set the secondary groups for the user. |
| 17:04 |
|
mmorgan left #evergreen |
| 17:05 |
|
dMiller__ joined #evergreen |
| 17:37 |
|
dMiller_ joined #evergreen |
| 17:50 |
|
jlitrell joined #evergreen |
| 18:03 |
|
dMiller_ joined #evergreen |
| 18:31 |
|
kenstir joined #evergreen |
| 18:33 |
kenstir |
Hey folks, I am a total n00b at opensrf, and I want to explore using osrfsh (as gmcharlt recommended). But I am having trouble building opensrf on CentOS7. Where would you recommend I start? |
| 18:34 |
|
bmills joined #evergreen |
| 18:51 |
kmlussier |
Hi kenstir! I'm not a good person to ask about opensrf, but I do know that support for CentOS is limited. |
| 18:51 |
gmcharlt |
Debian or Ubuntu is much better support; for a RedHat-like, Fedora is supported as well |
| 18:54 |
kmlussier |
gmcharlt: Heh, I didn't think anyone else would be around to help out at this hour on a Friday. :) |
| 18:58 |
kenstir |
So do you suggest I just spin up an Ubuntu VM and compile it from sources? I would like to use osfrsh against a live system (C/W MARS) |
| 19:01 |
gmcharlt |
kenstir: srfsh operates at the wrong level for that -- it's meant for inside-the-system use |
| 19:02 |
gmcharlt |
so, spinning up an Ubuntu VM and installing OpenSRF and Evergreen on it would get you a way to trying things out without pointing at a production |
| 19:02 |
gmcharlt |
*production system |
| 19:05 |
kmlussier |
kenstir: Also, if you want an easier way to install Evergreen than by going through all the steps in the readme, I've heard the Trusty installer script at http://wiki.evergreen-ils.org/doku.php?id=server_installation:semi_automated works fairly well. |
| 19:07 |
kenstir |
Is osrfsh the only way to introspect the search methods? I'm trying to make search better on the android app, and I need to better understand what's available. |
| 19:07 |
kenstir |
kmlussier: wow, that looks promising, thanks! |
| 19:50 |
gmcharlt |
kenstir: you can also use the gateway (same as what the Android app does) - e.g. every service has a "opensrf.system.method" method, which you can pass the name of the method whose documentation you want |
| 19:55 |
gmcharlt |
e.g., http://demo.evergreencatalog.com/gateway?service=open-ils.search&method=opensrf.system.method&param=%22open-ils.search.biblio.multiclass%22 |
| 19:57 |
kenstir |
ah, that is cool. What should I use to read that? |
| 20:02 |
kenstir |
(json_pp does not grok it and it's messy in chrome) |
| 20:07 |
kenstir |
If I remove the C-style comments, it is valid json and I can prettify it. |
| 20:11 |
|
bmills joined #evergreen |
| 22:51 |
jcamins_ |
@later tell kmlussier If I wanted to stay in Boston and come visit the hackaway for the day, do you think I'd be able to do so without needing a car? |
| 22:51 |
pinesol_green |
jcamins_: The operation succeeded. |
| 22:52 |
jcamins_ |
Bah. Who is jcamins? |
| 22:52 |
jcamins_ |
I'm only signed on once that I can see. |
| 22:54 |
jcamins |
I saw wrong. |
| 23:41 |
bshum |
jcamins: That sounds... intriguing. |
