| Time |
Nick |
Message |
| 04:43 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 04:48 |
phasefx |
Parse::RecDescent ^ |
| 04:50 |
phasefx |
maybe related to Excel::Writer::XLSX replacing Spreadsheet::WriteExcel::Big above it in the prereq listing? |
| 04:51 |
phasefx |
no, that's settings tester I'm looking at.. |
| 04:51 |
* phasefx |
looks for coffee instead of bugs |
| 05:04 |
phasefx |
ah, I don't see Parse::RecDescent (or libparse-recdescent-perl) in the pre-reqs |
| 06:27 |
|
_bott_ joined #evergreen |
| 06:58 |
|
kmlussier joined #evergreen |
| 08:15 |
|
akilsdonk joined #evergreen |
| 08:31 |
|
_bott_ joined #evergreen |
| 08:32 |
berick |
bshum++ dbs++ # idl2js love |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:38 |
|
rjackson-isl joined #evergreen |
| 08:55 |
|
Shae joined #evergreen |
| 09:08 |
kmlussier |
I'm curious. In the qatests there is a timing section - http://testing.evergreen-ils.org/~live/test.html. What is being measured for those timings? |
| 09:12 |
berick |
kmlussier: not totally sure, but I think it's how long the automated build + testing as a whole took (using the *nix 'time' command) |
| 09:12 |
berick |
or, to put it another way, Evergreen in 30 minutes or less |
| 09:12 |
kmlussier |
berick: Ok, thanks! 30 minutes or less? Wow, not bad. |
| 09:13 |
kmlussier |
I think if I tried to build Evergreen, it would take a lot longer than 30 minutes. |
| 09:15 |
berick |
well, that's what you get for not being a shell script |
| 09:16 |
bshum |
phasefx: So is Parse::RecDescent a pre-req for Spreadsheet::WriteExcel and now that we're no longer using that, it doesn't install on new systems causing that failure? |
| 09:16 |
bshum |
It seems like an easy thing to address with explicitedly adding it to the Makefiles where necessary then. |
| 09:25 |
|
remingtron_ joined #evergreen |
| 09:34 |
|
mllewellyn joined #evergreen |
| 09:38 |
kmlussier |
hmmm...I'm writing a release note entry for bug 868653 and using the docs already written by jihpringle as a reference. |
| 09:38 |
pinesol_green |
Launchpad bug 868653 in Evergreen "secondary permission groups (permission.usr_grp_map)" (affected: 3, heat: 20) [Wishlist,Fix committed] https://launchpad.net/bugs/868653 |
| 09:39 |
kmlussier |
Her docs say "The _Secondary Groups_ button is only visible to those users who have permission to grant secondary permission groups." This statement implies to me that we have a new permission with the code. But when I look at the code, my untrained eyes don't see a new permission. |
| 09:40 |
bshum |
kmlussier: There was not an upgrade script |
| 09:40 |
bshum |
So either there's a missing permission, or the permission existed previously before |
| 09:41 |
bshum |
Back in like the 1.6 times |
| 09:41 |
bshum |
Before the 2.0 redesigned patron editor |
| 09:41 |
kmlussier |
bshum: But the feature is new, so how could the permission have existed in 1.6 times? Or, wait, was this a feature that was availale then? |
| 09:41 |
bshum |
It was available then. |
| 09:41 |
kmlussier |
And then just now reintroduced? |
| 09:41 |
bshum |
They resurrected it. |
| 09:42 |
bshum |
I believe. |
| 09:42 |
bshum |
Or maybe it's a new GUI and it was handled some other way back then. |
| 09:42 |
bshum |
I don't know, I didn't use the feature in those days :) |
| 09:42 |
kmlussier |
It's before my time. |
| 09:43 |
kmlussier |
OK, that's all I need to know for the release notes, but maybe I'll contact jeffdavis and jihpringle for a little more clarification for the docs. |
| 09:43 |
mmorgan |
Hmm. When we originally started using this, I remember a rumor that there was never an interface for this, but the database supported it. |
| 09:43 |
mmorgan |
just a rumor, though. |
| 09:43 |
bshum |
CREATE_USER_GROUP_LINK |
| 09:43 |
bshum |
Is the perm in register.js |
| 09:44 |
bshum |
That is perm 46 in the seed data (pretty old) |
| 09:44 |
bshum |
So it already exists |
| 09:45 |
jeff |
if that is a related permission, it is confusingly named. |
| 09:45 |
kmlussier |
OK, I see that in the code now. I think the permission should be explicitly names in the release notes and the docs. |
| 09:45 |
jeff |
user groups (groupings of patrons) are not permission / profile groups, which is what i think this new UI deals with. |
| 09:45 |
* jeff |
looks at the code |
| 09:46 |
csharp |
@dunno add well, that's what you get for not being a shell script |
| 09:46 |
pinesol_green |
csharp: The operation succeeded. Dunno #32 added. |
| 09:46 |
kmlussier |
hee hee |
| 09:46 |
bshum |
Heh |
| 09:46 |
jeff |
anyone have the LP ticket for this handy? it isn't referenced in the commit message. |
| 09:46 |
kmlussier |
By the end of the day, I often feel like a shell script |
| 09:46 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/868653 |
| 09:46 |
pinesol_green |
Launchpad bug 868653 in Evergreen "secondary permission groups (permission.usr_grp_map)" (affected: 3, heat: 20) [Wishlist,Fix committed] |
| 09:47 |
jeff |
bshum++ thanks |
| 09:47 |
bshum |
fwiw, the permission's description is "Allow a user to add other users to permission groups" |
| 09:48 |
jeff |
bshum: thanks. that certainly sounds different from what i thought it was based on the name/code alone. |
| 09:48 |
kmlussier |
That's a little different from how I read the documentation. |
| 09:48 |
* bshum |
shrugs |
| 09:49 |
bshum |
Not all perms were created equal |
| 09:49 |
csharp |
we just do/did that from the database |
| 09:50 |
csharp |
it requires careful perm setup, otherwise the perm profiles fight with each other when each assigned profile has the same perm at different levels |
| 09:50 |
jeff |
and indeed, that perm is consulted by open-ils.actor.user.set_groups which deals with permission.usr_grp_map, so forget what I was saying about the perm name sounding unrelated to permissions. :-) |
| 09:52 |
mmorgan |
jeff is right, though, the code "CREATE_USER_GROUP_LINK" is highly misleading. |
| 09:52 |
bshum |
REMOVE_USER_GROUP_LINK is listed in the seed data too, but unused by the new code. |
| 09:53 |
* bshum |
shrugs |
| 09:54 |
bshum |
If someone writes a patch to change all this, I'll be happy to review and push it in. Otherwise, I'm also happy to leave stuff that's been untouched since 2011 alone :) |
| 09:54 |
kmlussier |
I have no desire to change it at the moment, just to document it. But I'll re-document if necessary. :) |
| 09:55 |
jeff |
since open-ils.actor.user.set_groups takes a userid and a list of groups as arguments, and removes the user from all groups then adds the user to the groups supplied in the argument, it returns a permission error if the caller does not have BOTH CREATE_USER_GROUP_LINK and REMOVE_USER_GROUP_LINK |
| 09:57 |
jeff |
in current code, it would be pointless to assign one of those permissions and not the other, as (speaking only in the middle layer context) they are both used (at present) by only the method in question. |
| 09:57 |
bshum |
jeff: That is an important detail. |
| 09:57 |
jeff |
(my "only in the middle layer context" is a required qualification there because the UI also pays attention to one of those permissions) |
| 09:57 |
* dbs |
would greatly prefer that what is required simply be documented, even if it's confusing, because 2011. |
| 09:58 |
* dbs |
always used the permission of "direct database INSERT/DELETE statements" to manipulate perm.usr_grp_map since 2009 |
| 09:59 |
jeff |
CREATE_USER_GROUP_LINK is required for the UI to display, and CREATE_USER_GROUP_LINK and REMOVE_USER_GROUP_LINK are required for the UI to not return a permission error. :-) |
| 10:04 |
csharp |
jeff++ |
| 10:07 |
bshum |
Indeed, jeff++ |
| 10:08 |
bshum |
And kmlussier++ for docs/notes |
| 10:15 |
* kmlussier |
now tries to figure out why jihpringle's images didn't display in her docs. |
| 10:15 |
kmlussier |
Ah, I see. |
| 10:25 |
csharp |
hmmm - I'm looking for a non-convoluted path from payment to the workstation where the payment was accepted - so far I see money.bnm_desk_payment, but I'm not sure what that's pull the ws information from |
| 10:25 |
dbs |
It would be _really_ awesome to have a doc build server that would build requested branches, so people could check their work before asking for a merge |
| 10:25 |
csharp |
end goal is to create a report on forgive payments based on the workstation where applied |
| 10:26 |
csharp |
dbs: is that something that would need to be built or is there something out there for docs like buildbot? |
| 10:27 |
dbs |
csharp: ultimately I think it would make sense to integrate the docs build into buildbot (getting doc-appropriate make & makefile.install targets into master) |
| 10:27 |
* dbs |
can wish/ideate but has very tuits... burned most of them last night (but yay RDA / secondary user groups) |
| 10:29 |
* csharp |
understands, being up to his neck right now too ;-) |
| 10:31 |
eeevil |
csharp: money.bnm_desk_payment.cash_drawer == actor.workstation.id |
| 10:31 |
* dbs |
apparently has had his phone set to not accepting voice mail for the last month. Which is pretty awesome |
| 10:32 |
eeevil |
csharp: or do you mean, where in the code is ws id coming from... |
| 10:33 |
csharp |
eeevil: yeah, where in the code? |
| 10:34 |
csharp |
my problem right now is finding a link in the reporter between forgive payments and a workstation, and I'm coming up short |
| 10:34 |
csharp |
I'm happy to submit a patch to fm_IDL.xml if that makes it work ;-) |
| 10:34 |
eeevil |
csharp: when a staff client logs in, it sends its name. the id is looked up and kept with the auth token as part of ... oh, forgive is staff-user specific |
| 10:35 |
csharp |
ah |
| 10:36 |
csharp |
the problem I have is that the only way a library can see "my staff's activity" is based on the home ou of the staff user, which as we know, isn't necessarily the work OU |
| 10:36 |
eeevil |
csharp: now, it won't help in a report, but if you just need to track down the exact workstation for a specific case, the auth logs for the day the payment was made can help you |
| 10:37 |
csharp |
eeevil: I'll keep thinking on it - thanks for the assistance ;-) |
| 10:38 |
eeevil |
but it sounds like you want workstation tracking for all "bnm" payment types. work, forgive, goods, in addition to cash, check, card. that data just isn't there (except in the logs) today |
| 10:38 |
csharp |
yes - that's what I was expecting to be ther |
| 10:38 |
csharp |
e |
| 10:38 |
csharp |
I'll file a wishlist bug |
| 10:44 |
csharp |
huh - there is a convoluted looking path from the Workstation source back to payments via Circulations/Transactions - I'll attempt that workaround (still filing the bug though) |
| 10:46 |
csharp |
bug 1354482 filed |
| 10:46 |
pinesol_green |
Launchpad bug 1354482 in Evergreen "reports: need workstation tracking for all payment types" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1354482 |
| 10:47 |
jeff |
csharp: that convoluted path likely will not give you what you want -- it would be giving you payments on a circulation based on the circulation being associated with a given workstation. |
| 10:49 |
jeff |
csharp: money.forgive_payment inherits from money.bnm_payment inherits from money.payment, and none of those tables have any column for workstation, so as eeevil stated, the data in question just isn't there other than by [taking the even more convoluted path of] extracting it from logfiles |
| 10:49 |
csharp |
ah - yeah - I was just beginning to doubt it too |
| 10:51 |
pinesol_green |
[evergreen|Kathy Lussier] Secondary permission groups release note - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6e6b483> |
| 11:11 |
|
bmills joined #evergreen |
| 11:25 |
|
vlewis joined #evergreen |
| 12:00 |
csharp |
@hate money reports |
| 12:00 |
pinesol_green |
csharp: The operation succeeded. csharp hates money reports. |
| 12:01 |
* mmorgan |
reads backscroll about money tables |
| 12:01 |
mmorgan |
So what does the "bnm" stand for? |
| 12:02 |
jeff |
mmpbbt (not for 2.7, alas) and jasper make our money reports users happy. |
| 12:02 |
jeff |
mmorgan: "brick and mortar" |
| 12:02 |
jeff |
mmorgan: "payments that take place in the library, not online" |
| 12:02 |
jeff |
though due to the way we do our credit card payments here, i think we count them as the same -- i don't know what the tpac payment options do without looking. |
| 12:03 |
|
_bott_1 joined #evergreen |
| 12:03 |
mmorgan |
Ah! makes perfect sense, but wouldn't have guessed it. |
| 12:03 |
jboyer-isl |
They leave cash_drawer null, which is aggrivating. |
| 12:04 |
mmorgan |
So cash_drawer IS workstation if you're looking at the individual payment tables? |
| 12:05 |
jboyer-isl |
mmorgan: yes. |
| 12:06 |
|
mrpeters joined #evergreen |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:15 |
* mmorgan |
is determined to understand money tables. |
| 12:15 |
mmorgan |
Looking at admin - local admin - cash reports, User payments show forgive payments, so how does that link back to the org unit I choose to view reports for? |
| 12:18 |
* jeff |
looks |
| 12:24 |
jeff |
mmorgan: that Cash Reports interface gives you a date range and lets you pick an org unit (that you have permissions to VIEW_TRANSACTIONS for. it then reports on "desk payments" associated with workstations during the date range at the org unit in question, and it reports on "user payments" during that date range based on the current home_ou of the user accepting the payments. |
| 12:25 |
csharp |
oh - I didn't know that |
| 12:25 |
jeff |
Those "user payments" (not "desk payments") include payments of type Forgive, Work, Credit, and Goods |
| 12:25 |
kmlussier |
Anyone want to add any last-minute availability to http://doodle.com/2dx9h3cccwbp84v4 before I try to decided between August 26 and 27? |
| 12:25 |
csharp |
that's flawed, because home libary may not = work location |
| 12:26 |
* csharp |
wonders if that's a separate bug from his reporting one |
| 12:26 |
jeff |
in the same interface, the "desk payments" include payments of type Cash, Check, or Credit Card. those are selected based on the date range and the owning_lib of the workstation object associated with the payments. |
| 12:26 |
csharp |
s/'s/ should be/g |
| 12:27 |
tsbere |
csharp: As a general note, I suspect part of the issue is that not all payments are guaranteed to have a workstation? |
| 12:27 |
jeff |
tsbere: right |
| 12:27 |
|
bmills joined #evergreen |
| 12:27 |
csharp |
but those "non-monetary" payments would *always* be applied at a workstation, no? |
| 12:27 |
tsbere |
csharp: Even some *monetary* payments won't have one. |
| 12:28 |
tsbere |
Any payment in the opac, for example |
| 12:28 |
jeff |
csharp: i think it's part of the same bug that you just filed -- a desire for all payments to have a workstation associated (with the probable exception of online credit card payments, though we use a dummy ws for those) |
| 12:28 |
jeff |
there's been separate work/discussion on getting SIP based payments to have a workstation/etc, iirc. |
| 12:29 |
csharp |
ah |
| 12:29 |
jeff |
i would like to go dig those back up and see what i can do there. |
| 12:29 |
csharp |
@eightball does everything have to grow heads? |
| 12:29 |
pinesol_green |
csharp: The outlook is hazy, please ask again later. |
| 12:29 |
jeff |
without breaking too much in the field -- i suspect that oils_sip.xml config options will be required to ensure a smooth transition. |
| 12:30 |
csharp |
I think the concept of "cash drawer" vs "workstation where this payment was applied" might be at issue? |
| 12:31 |
jeff |
"cash drawer" == "workstation" |
| 12:31 |
csharp |
yeah, I get that |
| 12:31 |
jeff |
ah. then i don't get your last statement. please continue. :-) |
| 12:31 |
tsbere |
Though for "forgive" type payments there isn't a "cash drawer" as there is no location the "payment" was stored |
| 12:31 |
tsbere |
Which I suspect is the difference |
| 12:31 |
jeff |
csharp: ah, i think i see your point. |
| 12:31 |
csharp |
I'm just saying that the thinking appears to have been "these payments are monetary and need a 'cash drawer', but these non-monetary payments don't need a 'cash drawer" |
| 12:32 |
tsbere |
"We need to know where the money was physically put" compared to "there was no money to put somewhere" |
| 12:32 |
jeff |
yep. |
| 12:32 |
csharp |
right |
| 12:33 |
jeff |
as opposed to "the system forgave this" ;-) |
| 12:33 |
* jeff |
ducks |
| 12:33 |
csharp |
heh - yeah, that too |
| 12:34 |
* csharp |
remembers a conversation with Dyrcona at last year's hack-a-way about how all financial software is lacking |
| 12:38 |
jeff |
at least an error is thrown when you attempt to "refund" a forgive payment. |
| 12:43 |
mmorgan |
yeah, but forgive payments still look an awful lot like money when bills and fines are voided... |
| 12:44 |
csharp |
our libraries are very confused about void vs. forgive |
| 12:44 |
csharp |
and when to use each |
| 12:47 |
mmorgan |
Yes, void vs forgive is a very confusing concept. |
| 12:48 |
dbs |
@who shall forgive the void? |
| 12:48 |
pinesol_green |
dbs shall forgive the void. |
| 12:48 |
dbs |
YES |
| 12:48 |
jeff |
heh |
| 12:49 |
jeff |
avoid the void. |
| 12:49 |
mmorgan |
avoid forgiving the void. |
| 12:50 |
mmorgan |
or voiding the forgive... |
| 14:40 |
kmlussier |
@dessert |
| 14:40 |
* pinesol_green |
grabs some Tiramisu for kmlussier |
| 14:40 |
kmlussier |
Oooh! I lucked out. |
| 14:47 |
csharp |
@dessert |
| 14:47 |
* pinesol_green |
grabs some Coconut Cream Cake for csharp |
| 14:47 |
csharp |
@quote random |
| 14:47 |
pinesol_green |
csharp: Quote #9: "<sylvar> Late-night boredom. Some folks write a replacement Minix kernel, some people set fire to stuff." (added by gmcharlt at 08:32 AM, May 17, 2011) |
| 15:34 |
jeff |
Hrm. I'm trying to track down a _print_tree error in offline mode in 2.5 -- no sign of a launchpad bug, and I see hbrennan mentioned it once, but I thought there was more discussion/diagnosis (or at least, more reports of it). Anyone remember? |
| 15:34 |
|
_bott_ joined #evergreen |
| 15:35 |
jeff |
I seem to recall it was a lack of initial "save printer settings" or similar. |
| 15:35 |
* jeff |
checks the reported line number |
| 15:37 |
jeff |
oh. it's a line number in JSAN.js -- one that doesn't exist. |
| 15:41 |
jboyer-isl |
jeff: When we've seen _print_tree errors, it's been when entering offline mode after logging into a live server (such as a mid-day outage situation), and they error doesn't appear if you just start the client and go directly to offline (do not pass Go, etc.) |
| 15:44 |
jeff |
jboyer-isl: thanks! i was just testing to see if that was the issue here. |
| 15:44 |
jeff |
(noticed i was logged in and in offline mode) |
| 15:47 |
kmlussier |
akilsdonk: I've started a 2.7 doc needs page at http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.7_needs. Would you or Erica be willing to identify the docs ESI is already working on (or completed)? |
| 15:48 |
kmlussier |
I'll wait until the ESI docs have been identified before sending an e-mail to the DIG list to recruit more documenters. |
| 15:51 |
akilsdonk |
kmlussier: of course! I'll gather that information and update the wiki |
| 15:51 |
kmlussier |
akilsdonk++ Thanks! |
| 15:56 |
|
hbrennan joined #evergreen |
| 16:00 |
jeff |
jboyer-isl++ thanks again, and for confirming |
| 16:05 |
jboyer-isl |
jeff++ for looking into it! |
| 16:44 |
|
_bott_ joined #evergreen |
| 16:46 |
kmlussier |
Hmmm...I know berick opted not to include bug 1351317 in the release notes because there are no functional improvements, but I envision Evergreen acq staff around the world jumping for joy if they see acq speed improvements in the release notes. |
| 16:46 |
pinesol_green |
Launchpad bug 1351317 in Evergreen "Various ACQ fund selectors are slow to render" (affected: 3, heat: 14) [Undecided,Fix committed] https://launchpad.net/bugs/1351317 |
| 16:46 |
kmlussier |
I think I'll add something there. |
| 16:49 |
|
Dyrcona joined #evergreen |
| 16:51 |
berick |
kmlussier++ |
| 16:52 |
kmlussier |
berick++ eeevil++ #for making *our* acq staff jump for joy |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:22 |
kmlussier |
Good news! Only had to add two release note entries for this release. |
| 17:22 |
kmlussier |
developers++#Adding release note entries and making my job easy. :) |
| 17:24 |
Dyrcona |
Heh. It's not my fault this time. |
| 17:24 |
* Dyrcona |
points at QA test failure. |
| 17:24 |
pinesol_green |
[evergreen|Kathy Lussier] Release note repairs and additions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=12e4ca0> |
| 17:25 |
kmlussier |
Yeah, those were there earlier today too. |
| 17:30 |
|
mmorgan left #evergreen |
| 17:43 |
|
mrpeters left #evergreen |
| 17:47 |
Dyrcona |
Well, I only signed in to bug tsbere about something in the office, so I'm signing back out. |
| 17:47 |
Dyrcona |
G'night all! |
| 18:12 |
|
kmlussier joined #evergreen |
| 18:58 |
|
mrpeters joined #evergreen |
| 19:00 |
|
mrpeters left #evergreen |
| 19:55 |
|
kmlussier joined #evergreen |
| 21:21 |
|
kmlussier joined #evergreen |
| 21:26 |
kmlussier |
Looks like we're missing images from some of Erica's new docs. I'm guessing because the image file extensions are in all caps? http://docs.evergreen-ils.org/2.6/_marc_fixed_field_editor_right_click_context_menu_options.html |
| 21:26 |
* kmlussier |
is beginning to think dbs' idea for a doc build server is an excellent one. :) |
