Evergreen ILS Website

IRC log for #evergreen, 2016-08-26

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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/ever​green/+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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat