| Time |
Nick |
Message |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:43 |
|
sarabee joined #evergreen |
| 07:54 |
|
ericar joined #evergreen |
| 08:01 |
|
jboyer-isl joined #evergreen |
| 08:03 |
|
collum joined #evergreen |
| 08:07 |
|
rjackson_isl joined #evergreen |
| 08:19 |
|
akilsdonk joined #evergreen |
| 08:20 |
|
akilsdonk_ joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:46 |
* kmlussier |
yawns |
| 08:47 |
|
Shae joined #evergreen |
| 08:47 |
|
maryj joined #evergreen |
| 08:47 |
mmorgan |
@coffee kmlussier |
| 08:47 |
* pinesol_green |
brews and pours a cup of Ethiopia Sidamo Guji, and sends it sliding down the bar to kmlussier |
| 08:49 |
|
mrpeters joined #evergreen |
| 08:49 |
|
Stompro joined #evergreen |
| 08:55 |
|
akilsdonk__ joined #evergreen |
| 08:58 |
kmlussier |
mmorgan: Thanks! |
| 09:00 |
|
akilsdonk__ joined #evergreen |
| 09:04 |
|
akilsdonk__ joined #evergreen |
| 09:07 |
|
Dyrcona joined #evergreen |
| 09:21 |
mmorgan |
Hmm. So when a hold is cancelled by staff (staff forced), the staff user that cancelled the hold doesn't seem to be recorded anywhere. Am I missing something? |
| 09:28 |
|
Shae joined #evergreen |
| 09:35 |
Dyrcona |
Too many things at once.... |
| 09:40 |
bshum |
mmorgan: that seems accurate as far as the stock database goes. |
| 09:41 |
Dyrcona |
mmorgan: No one way to find that out that I can see, unless maybe you're auditing action.hold_request then it would be in audit_user. |
| 09:41 |
bshum |
Presumably it's possible to dig that information out of logging if you really, really wanted to know. |
| 09:42 |
* Dyrcona |
twitches at the mention of logs.... |
| 09:43 |
mmorgan |
bshum: Dyrcona: Thought so, we aren't auditing action.hold_request. |
| 09:43 |
Dyrcona |
Yeah, no one that I know of audits anything in action.* stuff changes so fast there, plus possible privacy issues if you're aging circs and holds. |
| 09:43 |
mmorgan |
I don't mind wading through logs, but, unfortunately, we don't have logs for this time period anymore. |
| 09:44 |
Dyrcona |
Sounds like an enhancement idea. |
| 09:45 |
* mmorgan |
twitches at the thought of ever growing auditor tables. |
| 09:45 |
* Dyrcona |
is going to see about fixing up Open-ILS/xsl/locDoc2xml.xsl for the 2.9 release. |
| 09:46 |
* Dyrcona |
has a local ticket to add the 020$q to tooltips. |
| 09:47 |
|
yboston joined #evergreen |
| 09:48 |
Dyrcona |
Good morning, yboston! |
| 09:48 |
Dyrcona |
I haven't had a chance to look at your branch, yet. |
| 09:50 |
yboston |
Dyrcona: buenos días |
| 09:52 |
yboston |
Dyrcona: today I will work on creating a new branch rebased/squashed from master; with the new style commit. I could force push on my current working branch, but I was hoping folks would be looking at it, so I don't want to change it |
| 09:53 |
Dyrcona |
ok |
| 10:02 |
Dyrcona |
mmorgan: My enhancement idea was "Add the user who canceled the hold to action.hold_request." ;) |
| 10:15 |
|
Christineb joined #evergreen |
| 10:15 |
|
ericar_ joined #evergreen |
| 10:17 |
bshum |
Dyrcona: I'm not sure I'll make it to the dev meeting this week (meeting conflicts), but I'll try to add notes if I can regarding i18n discussion topic. |
| 10:17 |
|
esi joined #evergreen |
| 10:19 |
Dyrcona |
Well apart from "I didnt do it exactly right because of the 2.8 release process on the wiki," I'm not sure there is much to discuss. |
| 10:27 |
Bmagic |
When all of the line items on a purchase order are received or canceled, shouldn't the state be updated to "complete" ? |
| 10:28 |
Bmagic |
or "received" rather |
| 10:33 |
|
shae joined #evergreen |
| 10:37 |
kmlussier |
Bmagic: bug 1257915 |
| 10:37 |
pinesol_green |
Launchpad bug 1257915 in Evergreen "Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled" (affected: 8, heat: 44) [Medium,Confirmed] https://launchpad.net/bugs/1257915 |
| 10:37 |
|
pmurray joined #evergreen |
| 10:37 |
|
pmurray left #evergreen |
| 10:39 |
Bmagic |
kmlussier++ |
| 10:49 |
Bmagic |
kmlussier: I guess it's a bug. Under the conditions discussed there (keep_debts = false) the PO should* be marked received, however, the bug is still outstanding? |
| 10:52 |
kmlussier |
Bmagic: Yes, it's still outstanding. No code on the LP ticket. |
| 10:55 |
mmorgan |
Dyrcona: I like your enhancement idea to action.hold_request. I'm willing to open a launchpad ticket - unless there already is one that I missed. |
| 11:05 |
jeff |
if we're looking at changing action.hold_request with regard to hold cancellation, i'd suggest also changing how hold un-cancellation works. :-) |
| 11:11 |
mmorgan |
jeff: So, record the last editor of the hold? Whether it be cancelled, uncancelled, frozen, thawed, etc.? |
| 11:13 |
jeff |
might help. mostly i was making reference to the fact that hold un-cancellation revives the original hold in a way that it's not easy/possible to tell that it was ever cancelled in the first place, or why, etc. |
| 11:14 |
jeff |
on a few occasions i've thought about event tables associated with some objects as a middle ground between "nothing" and "audit tables" |
| 11:14 |
jeff |
probably needs a little more thought, though. |
| 11:18 |
mmorgan |
Ah. ok, also confusing. I guess same would be true for frozen then thawed holds. |
| 11:29 |
dbs |
This is probably a FAQ, but why are system-generated penalties shown under a "Staff-generated penalties/messages" label? |
| 11:36 |
csharp |
dbs: heh - I've actually never noticed that |
| 11:37 |
* mmorgan |
never has either. |
| 11:39 |
dbs |
So, maybe s/Staff-generated// for the label? |
| 11:39 |
csharp |
yeah, I think that would work |
| 11:40 |
* dbs |
is opening a bug |
| 11:42 |
* dbs |
notes that https://webby.evergreencatalog.com/eg/staff/circ/patron/1612/messages currently displays {{mainLabel}} as a bonus :) |
| 11:43 |
csharp |
dbs++ |
| 11:45 |
dbs |
bug 1490616 for excising "Staff-generated" |
| 11:45 |
pinesol_green |
Launchpad bug 1490616 in Evergreen ""Staff-Generated Penalties/Messages" label in patron display form misleading" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1490616 |
| 11:46 |
|
akilsdonk__ joined #evergreen |
| 11:48 |
miker |
dbs: heh, there seem to be issues with webby there, atm. thanks for mentioning ;) |
| 11:56 |
dbs |
miker: my pleasure! |
| 11:56 |
dbs |
bug 1490616 now has a working branch, for anyone interested |
| 11:56 |
pinesol_green |
Launchpad bug 1490616 in Evergreen ""Staff-Generated Penalties/Messages" label in patron display form misleading" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1490616 |
| 11:57 |
miker |
looks like another instance of the controller not waiting for the app resolver to complete |
| 12:06 |
bshum |
dbs: Regarding the string change, should that be backported, or should we only apply it towards master with an eye on the next release series now that strings are frozen for 2.9? |
| 12:07 |
bshum |
And if it's a change in the way it appears anyways, maybe it should be accompanied by a release note explaining why it's better soon. |
| 12:08 |
dbs |
bshum: I mostly wanted the ability to backport it easily for sites that want to customize it |
| 12:08 |
bshum |
Just ignore me if I'm being too pedantic about that approach. |
| 12:09 |
dbs |
I'd say it would be a nice-to-have for 2.9, but we've lived with it for years already, so not important enough to force another string i18n cycle |
| 12:09 |
dbs |
I can add a release notes commit if we're really going into that level of release notery |
| 12:09 |
* bshum |
assumes Dyrcona can make exceptions for 2.9 |
| 12:10 |
bshum |
I was only asking cause traditionally, we didn't make changes to labels after beta freeze. |
| 12:11 |
dbs |
bshum: I'm fine with that! It's not like a bug that's eating people's data or whatever |
| 12:12 |
dbs |
Totally appropriate to just pick it to master and be done with it. The only reason I mentioned 2.7 in the bug report is because that's where I was seeing it on our system. |
| 12:17 |
|
jihpringle joined #evergreen |
| 12:27 |
|
ericar_ joined #evergreen |
| 12:45 |
|
rfrasur joined #evergreen |
| 12:52 |
miker |
dbs: so, it looks like it's just firefox. berick, have you any thoughts on the cause of what we're seeing on webby? (controller function runs before startup.go()) |
| 12:52 |
miker |
dbs: or, rather, it's /not/ happening for me in chrome or chromium |
| 12:54 |
* berick |
reads up |
| 12:57 |
|
buzzy joined #evergreen |
| 12:58 |
berick |
i'm seeing {{mainLabel}} in chrome in the UI dbs posted. |
| 12:59 |
berick |
seeing it on my local vm, too. |
| 13:00 |
berick |
apparently page stops rendering after an error is thrown in the grid? |
| 13:02 |
berick |
just to clarify, though, controllers only wait on startup.go() if they are set as a via $routeProvider with a resolve handler (or they manually run startup.go() inside the controller) |
| 13:03 |
berick |
s/set as a/linked/ |
| 13:03 |
berick |
not saying that's at issue here, just mentioning it. |
| 13:08 |
dbs |
Chrome version 45.0.2454.78 beta (64-bit) / Linux for me for that webby issue |
| 13:09 |
berick |
miker: this fixes it for me http://pastie.org/10387804 -- somewhere along the way, the grid started assuming there would be a $scope.features array though it's not guaranteed |
| 13:10 |
berick |
the sanity check code was happening after array acces |
| 13:11 |
miker |
berick: that fixes the grid errors, but what about "Error: egCore.env.aous is undefined"? or are you not seeing that, or does the grid change also fix that in FF? |
| 13:12 |
berick |
oh, i'm not seeing that. |
| 13:12 |
miker |
in firefox? |
| 13:12 |
berick |
checking.. |
| 13:12 |
miker |
it does not happen in chrom{e|ium} |
| 13:16 |
|
akilsdonk__ joined #evergreen |
| 13:16 |
miker |
berick: thanks for that, pushed to the branch |
| 13:17 |
berick |
oh, duh, actually, i am seeing that. and I know what the problem is.. |
| 13:17 |
berick |
i pushed a fix in one of my working branches |
| 13:17 |
berick |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=ebfc001e4cf704ba882ec06c7a4fc7dac677b9aa |
| 13:17 |
berick |
(nothing magical there)( |
| 13:17 |
miker |
I'll pick it |
| 13:18 |
berick |
so, the patron app page-level controller PatronCtrl does not wait on startup.go() |
| 13:19 |
miker |
berick: but, egCore.env.aous gets populated by a class loader during startup ... how .. right, why is it not waiting |
| 13:19 |
berick |
it's sort of a container controller, whose child controllers wait on startup.go |
| 13:20 |
berick |
only the controllers linked to a resolve handler (in the .config) wait on startup.go() |
| 13:20 |
berick |
i was never able to find a way to tell angular to make every controller always wait. |
| 13:20 |
|
jlitrell joined #evergreen |
| 13:21 |
berick |
if some code needs to wait and it's controller does not wait, then it has to into a startup.go().then(...) |
| 13:21 |
miker |
so the waiter is always the "wrong" one -- the one that loads the data in an orderly fashion waits, but the one that uses the data never will |
| 13:21 |
miker |
is that right? |
| 13:21 |
berick |
s/it's/its/ |
| 13:23 |
miker |
I worked around that by wrapping the important stuff in a $timeout to run later ... startup.go().then() did not seem to work properly in FF at the time |
| 13:23 |
berick |
i think it's more common not to have a page-level controller like that patron app does. if you look at circ/renew/app.js, which is much simpler, there's just one controller and it waits |
| 13:25 |
|
vrani_ joined #evergreen |
| 13:27 |
berick |
page-level controllers are good for sharing data with sub-controllers (which generally wait), but if they need to render their own async data, they'll need their own startup.go().then(...) (or some other type of sanity checking like my patch above) |
| 13:28 |
|
Aj91 joined #evergreen |
| 13:29 |
miker |
berick: picked and pushed. thanks |
| 13:29 |
berick |
cool, thanks |
| 13:34 |
miker |
berick: I must be confused. I've got a controller named in a router provider and it is not waiting for startup.go() ... cat/volcopy/app.js ... in fact, the controller function runs twice, first not seeing the routerParams and then seeing them on the second run |
| 13:34 |
|
tspindler joined #evergreen |
| 13:38 |
berick |
miker: ah, ok, since you are loading EditCtrl via route provider, you'll want to remove it from the template. the: ctx.page_ctrl = "EditCtrl"; |
| 13:38 |
miker |
berick: the context does not need a controller, then? |
| 13:38 |
miker |
if so, perfect! |
| 13:39 |
berick |
only if there angular stuff happening in your template outside of the <div ng-view></div> |
| 13:39 |
berick |
then you'd need a view-specific template and a page-level template |
| 13:39 |
berick |
looks like in this case you don't need it |
| 13:40 |
miker |
nope, no scope stuff referenced outside the ng-view element. I'll remove that now |
| 13:41 |
miker |
perfect |
| 13:50 |
|
akilsdonk__ joined #evergreen |
| 13:51 |
|
Aj91 joined #evergreen |
| 13:52 |
dbs |
sanity check: SYS1 and SYS2 have different default loan periods for "Faculty" group, thus I need to define those with org_unit SYS1 / org_unit SYS2 (or org_unit CONS, copy_circ_lib SYS1/SYS2) in config.circ_matrix_matchpoint |
| 13:53 |
dbs |
and because there are different default loan periods for grps at SYS1/SYS2, I therefore have to create one rule for every SYS1 + Faculty + Circ Modifier where that default rule needs to be overridden |
| 13:53 |
dbs |
and then multiply that by every similar group? |
| 13:54 |
dbs |
Long story short: we have reserves items with a circ modifier of "RESERVE 2 HOURS" which should trump every other consideration, but instead of being able to define it once, it seems I have to define it for every System + Patron Group |
| 13:55 |
dbs |
This is made easier with the likes of "INSERT INTO... SELECT...", just ensuring that I'm not missing something before I go any further |
| 13:57 |
csharp |
circ policies have "fall through" capabilities, so some of it should be inheritable |
| 13:58 |
* csharp |
tries to re-wrap his head around in-db circ |
| 13:58 |
csharp |
this bug captures some of the lack, I think: https://bugs.launchpad.net/evergreen/+bug/1242708 |
| 13:58 |
pinesol_green |
Launchpad bug 1242708 in Evergreen "Evergreen needs the ability for comparison of columns in in-db circ/holds" (affected: 2, heat: 12) [Wishlist,Triaged] |
| 13:59 |
dbs |
csharp: that's what I was trying to do, but if we need to have special rules for Faculty (Undergrads, Staff) at SYS1, that will override the CONS rules for RESERVE 2 HOURS |
| 13:59 |
dbs |
So hey RESERVE 2 HOURS circmod that goes to a faculty member, you just got a 4-month loan! |
| 14:01 |
dbs |
So then we need special rules for RESERVE 2 HOURS at SYS1 level, but it's not clear to me how the precedence of FACULTY vs. RESERVE 2 HOURS is sorted out in that case |
| 14:01 |
Dyrcona |
Yeah, I think usr_grp might trump circ mod in that case. |
| 14:01 |
Dyrcona |
It's in the weights. You can change which weights you're using. |
| 14:03 |
dbs |
oh, that makes sense. |
| 14:03 |
dbs |
Searching docs.evergreen-ils.org for "weights" doesn't turn up much, hmm |
| 14:03 |
dbs |
lemme see if I can figure that out. |
| 14:04 |
csharp |
dbs: I had to read through the action.find_circ_matrix_matchpoint before weights clicked for me |
| 14:05 |
csharp |
s/matchpoint/matchpoint source code/ |
| 14:06 |
Dyrcona |
dbs: https://jason.mvlcstaff.org/looking-glass/notes.html might be helpful. |
| 14:08 |
Dyrcona |
I don't know where the rest of it went... Probably down the rabbit hole. :) |
| 14:09 |
dbs |
thanks Dyrcona, csharp |
| 14:12 |
|
pmurray_away joined #evergreen |
| 14:13 |
|
Shae joined #evergreen |
| 14:14 |
dbs |
Timestamp: 31/08/15 02:12:36 PM |
| 14:14 |
dbs |
Error: uncaught exception: _CUD: Error creating, deleting or updating {"__c":"ccmw","__p":[null,"Circ Modifier trumps",0,5,5,5,0,5,10,5,0,0,0,0,0,0,0,0,0]} |
| 14:14 |
dbs |
Guess that's still broken |
| 14:18 |
|
pmurray joined #evergreen |
| 14:18 |
|
pmurray left #evergreen |
| 14:20 |
Dyrcona |
I'm sure if senator were still around it would be fixed. :) |
| 14:20 |
Dyrcona |
may be a permission issue. |
| 14:23 |
csharp |
@seen senator |
| 14:23 |
pinesol_green |
csharp: senator was last seen in #evergreen 1 year, 27 weeks, 4 days, 2 hours, 31 minutes, and 47 seconds ago: <senator> short term, you may consider disabling autosuggest until you figure why there are so many of those or why they take a long time/error out/whatever |
| 14:23 |
csharp |
:-( |
| 14:23 |
bshum |
:( |
| 14:26 |
dbs |
Dyrcona: yeah, I suspect it's a permission issue |
| 14:26 |
dbs |
weird that it shows up in the staff client menu but whatever, i'm a psql guy anyway |
| 14:28 |
dbs |
Yay, set up a "Circ Modifier trumps ALL!" weight and associated it as the default, and it seems to work. |
| 14:28 |
rfrasur |
Ugh, I completely forgot about the GoToMeeting test call, tspindler. My apologies. |
| 14:29 |
bshum |
rfrasur: tspindler: I knew I was forgetting something too... sigh :( |
| 14:29 |
* bshum |
has been in other meetings too |
| 14:29 |
rfrasur |
bshum, I can't blame other meetings, but I did put together 3 telescopes (and only swore twice). |
| 14:30 |
bshum |
Dyrcona: fwiw, I think I did keep our slides at http://evergreen-ils.org/~bshum/eg12/rabbithole and http://evergreen-ils.org/~bshum/eg12/looking-glass/ |
| 14:30 |
bshum |
The looking-glass notes are the best though |
| 14:31 |
Dyrcona |
bshum++ |
| 14:31 |
Dyrcona |
I had that it all up on my server at some point, but got a new server or something happened and that was all I could find. |
| 14:32 |
Dyrcona |
Anyway, I'm investigating what looks like a permissions issue and this one is surprising to turn up after four years on Evergreen. |
| 14:41 |
tspindler |
bshum: its ok, Chauncey, Yamil and Andrea were on. I think we saw enough of the functionality to report back. We might want to try a large test later to see how its performance is with a larger number. |
| 14:42 |
|
akilsdonk joined #evergreen |
| 14:43 |
|
mmorgan1 joined #evergreen |
| 14:45 |
bshum |
tspindler: Cool deal, thanks for the update. |
| 14:45 |
bshum |
tspindler: I'm curious, presuming you guys were testing on Windows, maybe a Mac from yboston. Did any other OS make it in the mix? |
| 14:47 |
* bshum |
has used GoToMeeting sorta on his android phone, but remembered some oddities with his Ubuntu workstations once upon a time. |
| 14:48 |
jlitrell |
Last I heard was partial html5 support, so it should (kinda) work in lunix too. |
| 14:51 |
dbs |
hmm, maybe the circ weight matrix problem wasn't permssions, according to our logs: Returning method exception with message: An unknown server error occurred |
| 14:51 |
dbs |
fancy! |
| 14:51 |
dbs |
psql worked, so... |
| 14:52 |
tspindler |
yboston had a mac and the rest windows. I'm not sure it would run on linux without something like wine. never tried. |
| 14:59 |
kmlussier |
tspindler / bshum: I used my linux laptop with web GoToMeeting during conference planning calls last year. |
| 14:59 |
kmlussier |
Support wasn't great. I could never get my headset to work with it properly. |
| 15:07 |
Dyrcona |
dbs: I always mess with the matrices in the database. I think the admin interface for that is...lacking. |
| 15:08 |
bshum |
Agreed. |
| 15:08 |
rfrasur |
I've used GoToMeeting, but it's generally been for webinars and rarely using the microphone (at least not recently). I'm pretty ambivalent and will go with the flow. |
| 15:09 |
* rfrasur |
has to go see a dude about some old magazines. |
| 15:22 |
Bmagic |
Will I encounter issues if I just update the state of a purchase order manually to 'received' ? |
| 15:27 |
Bmagic |
I was wanting to go ahead and mark some purchase orders as 'received' manually in leu of a fix for the bug 1257915. Are there functions/code that uses the state column on the PO that I need to be aware of? |
| 15:27 |
pinesol_green |
Launchpad bug 1257915 in Evergreen "Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled" (affected: 9, heat: 48) [Medium,Confirmed] https://launchpad.net/bugs/1257915 |
| 16:04 |
jihpringle |
Bmagic: we do that for at least one of our libraries every few months and haven't run into any issues |
| 16:05 |
Bmagic |
jihpringle++ that makes me feel confident |
| 16:05 |
jihpringle |
we did it on our test server first |
| 16:05 |
Bmagic |
right on |
| 16:06 |
jihpringle |
when she gets back from lunch, Christineb is going to try and find our ticket from when we tested this to see if we noted any issues/things to be aware of when testing |
| 16:07 |
|
tspindler left #evergreen |
| 16:08 |
jeff |
jihpringle++ Christineb++ |
| 16:29 |
jihpringle |
Bmagic: just confirmed in our ticket, all we do is change the state to = received and we've had no reports of issues from libraries |
| 16:29 |
jihpringle |
update acq.purchase_order set state = 'received' where id in (8,21); |
| 16:31 |
Bmagic |
right on! Thanks again |
| 16:31 |
jihpringle |
you're welcome :) |
| 17:02 |
|
mrpeters left #evergreen |
| 17:07 |
|
mmorgan1 left #evergreen |
| 19:16 |
|
mnsri joined #evergreen |
| 21:23 |
|
sbrylander joined #evergreen |
| 21:24 |
|
TaraC joined #evergreen |
| 22:05 |
|
artunit joined #evergreen |
