| Time |
Nick |
Message |
| 00:56 |
|
gsams joined #evergreen |
| 00:57 |
|
dbwells_ joined #evergreen |
| 01:31 |
|
dbwells joined #evergreen |
| 01:55 |
|
dbwells_ joined #evergreen |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
Dyrcona joined #evergreen |
| 08:09 |
bshum |
I approved the new po templates in Launchpad translations and kicked off a new import of those files |
| 08:10 |
bshum |
Looks like the new templates are showing up in the list now. |
| 08:14 |
|
mrpeters joined #evergreen |
| 08:25 |
|
remingtron joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:49 |
|
bos20k joined #evergreen |
| 09:09 |
|
maryj joined #evergreen |
| 09:29 |
|
yboston joined #evergreen |
| 09:34 |
mrpeters |
interesting -- they are having you install grunt and bower now in the EVERGREEN step |
| 09:34 |
mrpeters |
oops wrong window :P |
| 09:34 |
mrpeters |
make sure you don't install it both with opensrf and evergreen 2.11 alpha :P |
| 09:36 |
mrpeters |
so all of the webby stuff happens within the confines of a normal Evergreen 2.11.alpha install from tarball? no need to install those packages independently? |
| 09:43 |
Dyrcona |
mrpeters: If the -c option is used with the make release script, the web client steps are done when the tarball is built. |
| 09:44 |
Dyrcona |
mrpeters: So, there's no need to do them again from a tarball. |
| 09:44 |
mrpeters |
right -- awesome! |
| 09:44 |
Dyrcona |
AFAIK, we've been building all release tarballs since 2.8 with that option. |
| 09:45 |
Dyrcona |
I know I've been doing that for 2.9, and in fact, I made sure that I could login with the web client for the 2.9.7 tarball. |
| 09:45 |
mrpeters |
ah, interesting. we had been using debs since those projects weren't changing much |
| 09:46 |
mrpeters |
but, i assume websockets still need to be set up manually as a part of opensrf |
| 09:46 |
Dyrcona |
Well, I don't know what your debs building process does. |
| 09:46 |
Dyrcona |
Yes, I believe it does. |
| 09:46 |
Dyrcona |
I usually build OpenSRF from git when testing tarballs. |
| 09:47 |
Dyrcona |
It's typically already installed on my vm, anyway. |
| 09:47 |
|
Callender joined #evergreen |
| 09:47 |
mrpeters |
the debs were just packages of the latest version of the bower/grunt modules from npm |
| 09:48 |
mrpeters |
but i dont think we will need them anymore since that all happens as a part of the Evergreen install from a tarball, which is great |
| 09:48 |
Dyrcona |
Well, grunt, etc. are not installed. It's just that the steps that require them are already run, so there's no need to install them. |
| 09:50 |
mrpeters |
i se |
| 09:50 |
mrpeters |
*see |
| 09:50 |
mrpeters |
no need to do the npm installs manually |
| 09:50 |
* Dyrcona |
has been meaning to do a blog about making a custom installation tarball. |
| 09:51 |
Dyrcona |
Right, unless you want to do something fancy later, like patch things and rebuild the staff client. |
| 09:51 |
mrpeters |
csharp can tell you a bit about how we make our custom tarball |
| 09:52 |
mrpeters |
i dont think i have the command handy, but it works really nicely |
| 09:52 |
Dyrcona |
I'm sure it does. :) |
| 09:52 |
csharp |
we basically do a git diff against the stock version, tar up the files from that list, then extract them on top of the stock files before building our deb |
| 09:53 |
Dyrcona |
See, I'd do it differently. |
| 09:53 |
mrpeters |
^^ there ya go, couldnt remember if it was a git diff or something else |
| 09:53 |
Dyrcona |
I'd make my own git branch with the customizations, and use make_release with the origin set to whatever my previous branch was. |
| 09:54 |
Dyrcona |
That's what I plan to do for the C/W MARS upgrade to 2.10.6 in October. |
| 09:54 |
Dyrcona |
And pretty much what I plan to document in a blog one day. |
| 09:54 |
mrpeters |
Dyrcona++ that will be good to have documented! |
| 09:54 |
csharp |
Dyrcona: I'd be very interested in that method |
| 09:55 |
Dyrcona |
It could make a decent conference session, too, I think. |
| 09:55 |
csharp |
we've always built from the release tarball rather than directly from git |
| 09:55 |
csharp |
because we want to be as close to "stock" as possible |
| 09:56 |
Dyrcona |
Yeah. I've usually just built from git, but I think a tarball will work better at C/W MARS. |
| 09:56 |
Dyrcona |
There's some basic documentation on using the make_release script here: http://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8 |
| 09:57 |
Dyrcona |
It's toward the bottom. |
| 09:58 |
Dyrcona |
If I do the blog soon enough, I might show making a tarball to go from 2.9.7 to 2.11.0 or the latest 2.10. |
| 09:59 |
Dyrcona |
For C/W MARS, we'd be going from 2.9.5 to 2.10.6. |
| 09:59 |
Dyrcona |
On the alternate patron view working branch. |
| 10:00 |
Dyrcona |
Anyway, I've got a slightly complicated DB update script that I should get working on. ;) |
| 10:31 |
csharp |
berick: thanks for your comment (https://bugs.launchpad.net/evergreen/+bug/1617318/comments/1) - I'm remembering now that we've looked into that before |
| 10:31 |
pinesol_green |
Launchpad bug 1617318 in Evergreen "Collections API should create a standing-penalty-based note" [Wishlist,New] |
| 10:32 |
csharp |
the only issue with that is that the alert/penalty isn't applied at the consortium level, so the blocks and alert only work within the system that put the patron into collections |
| 10:32 |
berick |
csharp: you can modify the penalty depth to 0 |
| 10:32 |
berick |
so it's applied globally |
| 10:32 |
berick |
unless you don't want to do that for other reasons |
| 10:33 |
csharp |
well, if we do that, it's unclear which library put the patron in collections |
| 10:33 |
berick |
so you can have multiple applications of the penalty at different locatiosn... |
| 10:33 |
* csharp |
ponders that |
| 10:34 |
berick |
csharp: does it help that the actor.usr_standing_penalty has the org_unit? staff may never see that, though |
| 10:34 |
berick |
can't remember |
| 10:36 |
* csharp |
looks at the table |
| 10:36 |
tsbere |
berick / csharp: The org_unit is determined in part by the depth, so if depth is 0 the org unit is the top of the tree |
| 10:38 |
csharp |
right - that's the dilemma for us - if we want it set for PINES, we lose which library set the penalty |
| 10:38 |
csharp |
and staff need to know that |
| 10:38 |
tsbere |
csharp: I do believe that the user who set it (when applicable) is available... |
| 10:38 |
* tsbere |
isn't sure you have a suitable user in this case, though |
| 10:39 |
csharp |
well, in this case it would all be the UMS user |
| 10:40 |
tsbere |
csharp: The best solution I can come up with right now is "make a global version of the penalty as a custom one, then either use triggers or a cron job to update it with a list of libraries they are in collection for in the descriptive text" |
| 10:40 |
berick |
the money.collections_tracker contains the org unit passed by UMS, regardless of any penalty configuration |
| 10:41 |
|
mrpeters joined #evergreen |
| 10:42 |
berick |
ugh, which is what I meant to say before, not actor.usr_standing_penalty |
| 10:42 |
berick |
and to restate the complication there, staff may never see money.collections_tracker data as it stands today |
| 10:43 |
berick |
but we have the data, so that's a start |
| 10:44 |
csharp |
well, maybe I can add the library to the "note" field of the ausp |
| 10:45 |
csharp |
I'll look into how the penalty is created |
| 10:50 |
csharp |
looks like adding "added by LIBRARY-SHORTNAME" or somesuch to the note wouldn't be too much trouble |
| 10:52 |
csharp |
so I would imagine making the top-level org the penalty org_unit for these is a sane default |
| 11:00 |
tsbere |
csharp: I frequently wonder if anything in the library world can be considered "sane" ;) |
| 11:02 |
* Dyrcona |
frequently wonders if anything at all in the modern world can be considered sane. |
| 11:05 |
csharp |
so if the penalty depth is 0, it's visible everywhere no matter which org puts the patron into collections, right? |
| 11:06 |
berick |
csharp: the penalty is visible everywhere, yes |
| 11:06 |
csharp |
if so, the only code change necessary would be adding to the note which org_unit added the penalty |
| 11:06 |
berick |
well, it's applied everywhere |
| 11:07 |
berick |
csharp: if that's the route you're taking.. but you'd also have to remove org units as the patron is removed from collections for each org. sounds like a mess. |
| 11:07 |
berick |
i don't think a new penalty would be added for every instance |
| 11:08 |
berick |
though, i'm not sure about that |
| 11:08 |
tsbere |
As far as I know it won't add them for each instance, if it already exists for that org depth then it won't create a new one |
| 11:08 |
|
book` joined #evergreen |
| 11:08 |
tsbere |
(it will create them for each system/branch when at those depths, though) |
| 11:11 |
berick |
hm, I don't see anything in the code that would prevent duplicate penalties. |
| 11:12 |
tsbere |
berick: I could be wrong, or only correct in certain situations. I never looked at the collections penalties. |
| 11:12 |
berick |
csharp: another issue.. if you have multiple penalties of the same type and org unit, when the penalty conditions are met to remove the penalty, they will all be removed. |
| 11:18 |
berick |
well, wait, what happens when you have multiple grp/penalty thresholds for a single shared/global penalty? |
| 11:19 |
berick |
there's no way to know which usr_standing_penalty instance is linked to a given org unit once it's created, cuz the org_unit will be 1 (root org) for depth=0 penalty types |
| 11:19 |
tsbere |
berick: The code stops at the first one it sees as it walks up the tree. Also, grp/penalty threshold penalties may ignore depth and set at the threshold org unit/depth instead... |
| 11:24 |
berick |
looks like actor.calculate_system_penalties returns all matching usr_standing_penalty's |
| 11:25 |
tsbere |
I know at least once in the past I found that the code wasn't bothering to update consortia-wide penalties if there was a branch or system threshold for that penalty as well |
| 11:25 |
berick |
ah, yes, that does make sense |
| 11:26 |
berick |
but here we're talking about a single global penalty type |
| 11:26 |
berick |
the more I think about it, it really does not make sense to apply a global penalty more than once. |
| 11:27 |
berick |
it's just not how it's intended to work |
| 11:30 |
berick |
when the time came to remove one user penalty, they would either all be removed (I think) or removed arbitrarily (also not ideal) -- they would not be removed in any org-specific manner, since they all share the same org unit. in csharp's case, this would lead to a mismatch between user penalties and the data in the collections tracker. |
| 11:35 |
berick |
what csharp needs are standing penalty types that are non-global (e.g. applied at the branch/system in question), but are globally visible in the staff client. |
| 11:36 |
berick |
a "watch list" penalty ;) |
| 11:36 |
|
Christineb joined #evergreen |
| 11:36 |
csharp |
berick: exactly |
| 11:36 |
tsbere |
berick: And for that my best solution is "make a custom one that gets updated by triggers or cronjob that lists the org units that the non-global ones are applied at" ;) |
| 11:37 |
berick |
tsbere: ah, i missed that. yeah, that would get the job done. |
| 11:38 |
berick |
csharp: do you plan to apply blocks to patron_in_collections |
| 11:38 |
berick |
? |
| 11:38 |
berick |
or, in the case of tsbere's suggestion, the meta-penalty? |
| 11:38 |
csharp |
I'm hoping for one single penalty that visible in all locations in the consortium, marked with a note that indicates which library applied the penalty |
| 11:39 |
csharp |
berick: ideally, yes, with the blocks applied everywhere, not just at the org that set it, but we need to *see* the org that set it |
| 11:39 |
csharp |
right now our libraries are abusing "barred" for that purpose |
| 11:39 |
tsbere |
csharp: My solution would be "have a trigger/cronjob create/maintain a global one with a note similar to 'This patron is in collections at the following locations: <list>'" |
| 11:40 |
berick |
csharp: you could do that in Collections.pm. before applying the penalty, look for an existing instance of the penalty. then create/update the penalty note to include all org units represented in money.collections_tracker for that user. |
| 11:40 |
csharp |
berick: that's where I'm looking |
| 11:41 |
csharp |
one incidental question, where should I enter the string that should be in the note? in the locale dtd? |
| 11:46 |
berick |
csharp: well, the note could just be a list of org unit shortnames. no English, etc. text. *shrug* |
| 11:46 |
csharp |
ah - even better |
| 11:46 |
berick |
well, the fee_note comes from UMS. I wonder if they are using it. |
| 11:47 |
csharp |
I don't see any fee notes entered |
| 11:47 |
berick |
guess not, then |
| 11:47 |
csharp |
I can check with them |
| 11:47 |
berick |
but it is part of the API... |
| 11:47 |
csharp |
right |
| 11:48 |
csharp |
I was going to add any fee note to the end of the note field after the org shortname |
| 11:48 |
|
bmills joined #evergreen |
| 11:48 |
* berick |
nods |
| 11:50 |
Dyrcona |
So, I'm guessing that if I'm going to setup gitolite on a server, it's probably better to clone it from github than to use the O/S package? |
| 11:50 |
Dyrcona |
Almost all of the examples for quick setup that I can find say to clone the github repo. |
| 11:54 |
|
jihpringle joined #evergreen |
| 11:56 |
Dyrcona |
Easy peasy, and done before lunch. :) |
| 12:02 |
csharp |
gmcharlt: do you think we should have a DB upgrade script that sets people's PATRON_IN_COLLECTIONS to staff_alert = TRUE or is that too much to assume? |
| 12:02 |
* csharp |
just wrote one in automatic developer mode then used his brain |
| 12:03 |
gmcharlt |
csharp: I think it's too much to assume without asking, but a reasonable thing to ask input for on open-ils-general |
| 12:03 |
csharp |
ok |
| 12:03 |
csharp |
I'm tempted to just write release notes and call it done |
| 12:04 |
csharp |
such an easy thing to change |
| 12:08 |
miker |
maybe I'm being too simple, but why not just show the in-collections information as a stopsign alert? no need to generate notes or anything, afaict |
| 12:09 |
miker |
as in, the list of orgs that have placed the user in collections currently. it's there, it's authoritative... |
| 12:09 |
berick |
miker: i was musing the same thing |
| 12:09 |
berick |
and I think that's a better long-term solution |
| 12:09 |
berick |
use the data we have |
| 12:09 |
miker |
and easier, I'd think, than writing code to write note (that will be ignored because notes are terrible ;) ) |
| 12:10 |
berick |
well, UI dev is its own special thing (especially with 2 active UI's) so I get the desire not to go down that path |
| 12:10 |
berick |
but, yeah.. |
| 12:11 |
berick |
if we showed the tracker data, we could also show dates applied |
| 12:11 |
miker |
I can attest that the stopsign page in webstaff is not particularly hairy. it's the first preexisting one I touched :) |
| 12:11 |
berick |
and per-instance UMS notes (when they exist) |
| 12:12 |
miker |
as for the xul one, meh ;) |
| 12:12 |
* berick |
feels the same |
| 12:12 |
berick |
but.. that doesn't help csharp ;) |
| 12:13 |
miker |
well, it's a feature, and that's verboten by consensus ... but anyone can lobby for anything, and convince a committer it's important enough |
| 12:14 |
miker |
seems adjusting the existing penalty will get csharp >50% there, though, if the primary goal is staff knowing there's a problem at all |
| 12:16 |
miker |
launchpad has foresaken me just as I was going to update the bug for this ... oh well |
| 12:22 |
|
mrpeters left #evergreen |
| 12:47 |
|
bmills1 joined #evergreen |
| 13:09 |
_adb |
Dyrcona: a few weeks ago you were looking at web frontends for git... did that pan out? looks like i'll be setting one up |
| 13:09 |
Dyrcona |
_adb: I'm going with gitweb. |
| 13:09 |
_adb |
thanks, i'll check it out |
| 13:10 |
Dyrcona |
It's what we use on git.evergreen-ils.org. It's pretty basic. |
| 13:13 |
|
maryj joined #evergreen |
| 13:35 |
|
gsams_ joined #evergreen |
| 14:49 |
|
abowling joined #evergreen |
| 15:09 |
mmorgan |
Quick queston for anyone around who's using opt-in notice triggers - is there a way to control the order in which the notification types appear to the patron when logged in? |
| 15:12 |
mmorgan |
Looks like they are sorted by the user setting type label. |
| 15:29 |
|
bmills joined #evergreen |
| 15:44 |
|
jihpringle joined #evergreen |
| 16:50 |
|
ejk joined #evergreen |
| 17:02 |
berick |
miker: dbwells: found some merge conflict markers and an unstamped DB upgrade in master. pushed a fix commit to working/user/berick/master-sql-fixes |
| 17:02 |
|
mmorgan left #evergreen |
| 17:03 |
berick |
the penultimate DB upgrade for 1000, yeehaw |
| 17:17 |
Dyrcona |
Hmm. for some reason, I've forgotten how to grep a file for < . When I don't escape it, I get nothing. When I do escape it, I get every line in the file.... |
| 17:18 |
berick |
Dyrcona: quoting it works for me |
| 17:18 |
berick |
(no escape) |
| 17:18 |
Dyrcona |
Yeah. I was looking in the wrong place. *sigh* |
| 17:19 |
Dyrcona |
When I look for '^<' I found stuff, but '^<<' didn't find anything, 'cause like I said... |
| 17:20 |
Dyrcona |
Look in Pg/ and there it is. |
| 17:20 |
Dyrcona |
berick++ |
| 17:20 |
Dyrcona |
I suppose I could push that. |
| 17:21 |
Dyrcona |
Instead, I'll call it a day. |
| 17:27 |
dbwells |
berick++ |
| 17:28 |
dbwells |
and DANGGIT |
| 17:28 |
pinesol_green |
[evergreen|Bill Erickson] Stamp 0999 upgrade; remove merge conflict markers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e07ac6c> |
| 17:30 |
berick |
dbwells++ |
| 18:00 |
|
_adb left #evergreen |
| 18:07 |
|
bmills joined #evergreen |
| 19:05 |
miker |
berick++ # totally missed the second file, doh! merge mountain got me :) |
| 19:22 |
|
ejk joined #evergreen |
| 21:29 |
|
ejk joined #evergreen |
