Evergreen ILS Website

IRC log for #evergreen, 2018-05-16

| 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
02:27 rjackson_isl_ joined #evergreen
06:32 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:02 agoben joined #evergreen
07:18 rjackson_isl_ left #evergreen
07:22 rlefaive joined #evergreen
07:39 collum joined #evergreen
07:40 rlefaive joined #evergreen
07:46 rjackson_isl joined #evergreen
07:51 jvwoolf joined #evergreen
07:51 rlefaive joined #evergreen
07:54 jvwoolf1 joined #evergreen
07:57 dwgreen joined #evergreen
08:01 idjit joined #evergreen
08:24 rlefaive joined #evergreen
08:34 dpearl1 joined #evergreen
08:51 kmlussier joined #evergreen
08:54 Dyrcona joined #evergreen
09:04 bos20k joined #evergreen
09:11 lsach joined #evergreen
09:58 mmorgan joined #evergreen
09:58 gmcharlt apropos of yesterday, bug 1771397
09:58 pinesol_green Launchpad bug 1771397 in Evergreen "web staff client not compatible with AngularJS 1.7.0" [Undecided,New] https://launchpad.net/bugs/1771397
10:01 mmorgan windows-- # carving 1.5 hours out of your day for updates to make your pc better and improve your job performance :-/
10:02 gmcharlt @karma windows
10:02 pinesol_green gmcharlt: Karma for "windows" has been increased 0 times and decreased 1 time for a total karma of -1.
10:03 mmorgan windows--
10:03 mmorgan windows--
10:03 idjit "your computer might restart several times during this process"
10:03 idjit windows--
10:03 gmcharlt "they (don't yet entirely dis)like me! they really really (doest yet entirely dis)like me!"
10:06 yboston joined #evergreen
10:09 Dyrcona So, one of those scammers called about Windows having a problem and you need to pay for this update.
10:09 Dyrcona My wife decided to have some fun with them.
10:10 Dyrcona She said, "No, my Windows work great. They go up. They go down. They let in the light. They have screens."
10:10 Dyrcona "No, the Windows on your computer."
10:10 jvwoolf joined #evergreen
10:10 Dyrcona "I don't have Windows on my computer."
10:10 Dyrcona *click*
10:10 mmorgan :-D
10:10 berick hah :)
10:21 gmcharlt :)
11:06 abowling joined #evergreen
11:14 berick i'd appreciate an eyeball on this before posting to mail lists for reivew:  https://wiki.evergreen-ils.org/doku.php?id​=dev:browser_staff:angjs_to_ang_migration
11:15 berick i'm way too close to it.
11:16 gmcharlt berick: a couple things immediately jump out at me
11:18 gmcharlt one, there should probably be something that (a) uses the <blink> tag (b) and the <marquee> tag, and (c) 72-point type to the effect that unit tests are /crucial/ for core services
11:18 * berick dons geocities cap
11:19 berick good point, thanks gmcharlt
11:20 gmcharlt secondly, the project to angularize acquisitions falls in an uncomfortable place in the timeline you're proposing
11:20 gmcharlt i.e., at least a few of the Dojo acq interfaces may well be Angular(JS) by the 3.2 cutoff
11:22 gmcharlt that's not necessarily a _problem_ per se, but it is a case where we'll need to figure out fairly soon whether to attempt to have the new acq stuff start in Angular or have it start life as AngularJS
11:22 gmcharlt and any pointers you can give about writing AngularJS in a way that reduces effort for subsequent rewriting to Angular would be helpful
11:23 berick indeed, i was concerned about that as well.
11:23 gmcharlt also, how much can we expect in the way of differences in the TT2 templates between the Angular and AngularJS sides?
11:23 gmcharlt er, Bootstrap aside
11:25 gmcharlt berick: otherwise, I think the timeframe is reasonable
11:27 berick gmcharlt: re: pointers, i'd say the main thing is keeping business logic, utility code, etc. as decoupled from angular as possible.  the directives do the bare minimum to display data, but the vast majority of code lives as standalone bits of logic in service code.  functions that can be copied wholesale w/ minimal angularization needed.
11:29 berick gmcharlt: may be unclear in the doc, but my proposal is we don't use TT2 at all in the Angular app.
11:29 * berick nods re: time frame being reasonable
11:29 gmcharlt berick: whoops, I totally missed that, and read it as just applying to i18n
11:30 berick i'll make that more clear
11:30 dbwells Good morning, all.  We're scheduled for point releases today, but I would like to push that out a week to 5/23.  I really want to see the cataloging "omnibus" branch get in, but there is at least one regression noted on one of the tickets.  I think it is worth a few extra days to sort that out, and believe we can get there.  If there are any objections to this plan, please speak up.  Thanks!
11:31 bshum dbwells: Isn't the bug squashing week next week too?
11:32 bshum Perhaps it might be better to do cuts the week after?
11:32 Dyrcona Bug squashing week is rather ill-timed for me.
11:32 bshum (May is a weird month, how is it already the third week??)
11:32 Dyrcona With releases due this week, and bug squashing next week, and our upgrade next weekend.....
11:33 JBoyer dbwells, bshum: That sounds like a good plan; pack the most fixes into the next point release rather than several of them being ready days after the cut.
11:33 Dyrcona I really want to upgrade to 3.0.8 with all of the patches applied, without requiring me to add them locally, so none of this good AFAIC.
11:34 bshum JBoyer: Especially with what happened last release where we released, then a couple days later did a security release too.
11:34 bshum It just seems better to just pull things all together properly.
11:34 bshum But timing is meh always
11:34 JBoyer That is rough timing.
11:34 bshum There's never a good time :)
11:35 Dyrcona Sure, there is: Anytime there is not a long weekend in the US. :)
11:36 Dyrcona dwells: I say move the release to next week or the week after. Don't let the poor timing of my upgrade affect your decision.
11:36 gmcharlt berick: an apparent consequence of ditching TT2: there would no longer be an override mechanism for customiziing templates, and on the AngularJS side, one would want to avoid doing so (unlike the OPAC) to avoid the number of manual changes to carry over to eg2
11:38 gmcharlt berick: now, for operational reasons I /don't/ actually see that as much of a problem, but (a) it should be made clear that such template tweaks are discouraged unless one is using Git to maintain them and (b) we should probably get a sense of what webstaff client tweaks folks want to do/have done and see if we can reasonably support sufficient CSS and JS scripts to do it
11:38 dbwells bshum: JBoyer: Good thoughts, thanks.  I'll see about buildmaster availability, but maybe we can go for a special Friday, 5/25 release.  We'd at least get *most* of the squashing in.
11:38 gmcharlt (or, I suppose, a bunch of YAOUS)
11:39 kmlussier Dyrcona / dbwells: Actually, I would like to push for the maintenance release happening before Memorial Day weekend. There are a lot of bug fixes that I think would be useful for any site that is planning to do an upgrade over the holiday.
11:39 berick gmcharlt: all good points.  i'll add that to the doc.
11:40 kmlussier Even without the cataloging bug fixes, I think it's shaping up to be a very good maintenance release.
11:40 Dyrcona kmlussier: The problem with that is the bug fixes likely won't get in.
11:42 dbwells kmlussier: Is 5/25 still before the weekend in your view, or do you mean earlier than that?
11:43 berick gmcharlt++ # feedback
11:44 kmlussier dbwells: I was thinking earlier, but, to be honest, the only site I know of doing an upgrade on Memorial Day is CW MARS, and I guess Dyrcona already indicated it wouldn't make a difference. I just didn't know if there are other sites counting on having one more point release before that weekend.
11:45 * kmlussier has noticed in previous years that Memorial Day can sometimes be a busy upgrade weekend, but it may not be the case this year.
11:45 Dyrcona Yeah, Memorial Day is just looking bad from a code point of view.
11:45 Dyrcona I kind of like what we did last year, skip 2.11 on Memorial Day and go from 2.10 to 2.12 on Columbus Day.
11:46 Dyrcona I think it would cause too much trauma if I said we should do that, now. Everyone has been getting webinars and training on 3.0.
11:47 miker berick: do you have any concerns abou things like egGrid's compiled templates (as opposed to the default interpolation-only templates)?
11:48 berick miker: as in defining a field whose contents are a mini embedded template?
11:48 miker also, re ditching tt2, I'm not a huge fan of that, fwiw
11:49 miker berick: yes. it's apparently possible today, in the angularjs version, if you give an eggridfield the "compiled" attribute (IIRC)
11:50 kmlussier dbwells: I can withdraw my objections.
11:50 abowling1 joined #evergreen
11:51 dbwells kmlussier: okay, thank you for the clarity.
11:51 berick miker: hmm, i'm not actually familiar with that, if you have an example UI, that'd be great.  I suspect it's not a problem, though.  Angular has a TemplateRef type which makes passing templates around for inclusion in various contexts super easy.
11:52 berick miker: n/m, i found one..
11:52 dbwells re: release date, thanks for the feedback, all.  I think we'll keep it penciled in for 5/23, then judge the momentum of bug squashing at that point to consider extending to Friday.  I'll check back once more in the afternoon, then send an update to the list.
11:53 berick miker: 'compiled' won't be a problem.
11:53 miker berick: I stumbled across it recently in one of gmcharlt's additions. I wasn't actually aware of it, and was loath to implement it myself
11:53 miker cool
11:54 miker because that could make auto-idl mode much more useful :)
11:55 miker ... in complex grids where interpolation alone isn't really enough
11:55 gmcharlt cat/item/t_list.tt2 has an exmaple
11:55 gmcharlt *sigh*
11:56 berick here's an example passing a custom tempalte into the fielmapper editor to override a "description" field
11:56 berick http://git.evergreen-ils.org/?p=working/E​vergreen.git;a=blob;f=Open-ILS/src/eg2/sr​c/app/staff/sandbox/sandbox.component.htm​l;h=b66343436db2cfa4dcd159896bd4875118d57​18f;hb=user/berick/lp1626157-ang6-app#l5
11:57 berick same idea would apply to the grid.  just pass a reference to the thing to render
11:57 berick and some context data
11:57 gmcharlt miker: what's your reasoning for keeping TT2?
11:58 * gmcharlt has no strong feelings either way
11:58 gmcharlt one the one hand, it's slower than serving up direct HTML
11:59 gmcharlt on the other hand, being able to adjust the HTML server side via TT2 logic gives us potential flexibility beyond just i18n
12:01 miker customization is a big one (we'll eventually want some amount of customization -- we always do), but also better control over what is/isn't displayed, and when, on the server side (think: security)
12:01 Bmagic If overriding templates is possible with Angular then getting rid of tt2 seems great to me! Overriding is super important to me and probably everyone else that manages many libraries each with their own derivative of the tt2 files.
12:02 miker Bmagic: that's the thing, it's not really
12:02 miker not without us inventing a scheme of our own
12:02 Bmagic It's possible with ALOT* of work?
12:03 miker which will never be as good as the tool build to do exactly that that's maintained by a larger group that's not us and has been around for 15+ years :)
12:03 Bmagic The payoff is a more webby look and feel for the patron OPAC? Why can't we get the current TT2 system to deliver Angular code?
12:04 miker I don't think berick was suggesting a patron opac rewrite just yet
12:04 berick it's theoretically possible to create per-org angular builds, each with its own templates.  it's something we would have to devise, though.
12:04 Bmagic oops, got ahead of the convo
12:05 miker but, if that happens (which I would love!) then we'll absolutely need template overrides, which tt2 gives us for free along with lots of other stuff
12:05 miker berick: that sounds .... terrible :(
12:06 berick mixing TT2 with angular-cli (building, bundling, i18n, etc.) is a no-go.  it has to parse the html templates.  only option I can see is a pre-compilation step that went from TT-to-HTML on the server.
12:06 jihpringle joined #evergreen
12:06 berick miker: there may be other options.  just spitballing
12:06 jeff that might lose some of the things miker was hoping for, like "better control over what is/isn't displayed, and when, on the server side (think: security)"
12:06 miker berick: there's a tool for that in tt2
12:07 miker jeff: aye, indeed
12:07 jeff which sounded to me like runtime decisions, but maybe not -- can you expand/clarify, miker?
12:07 miker berick: that's something that isn't clear from the wiki page (or I totally missed it)
12:07 jeff (sounds like you just confirmed, at least) :-)
12:08 miker jeff: yes, runtime but server side, so we don't leak to the browser
12:08 miker "that" being "you can't use tt2 with angular6"
12:09 berick yeah, runtime TT2 just won't work.  angular compiles the html into JS at build time.
12:09 berick (for speed, which is arguably as or more important that template overrides)
12:09 miker I don't much care where i18n happens, tbh. I'm concerned with that actual purpose of tt2 ... the i18n stuff we do there is really an add on of our own devising
12:10 miker berick: I think that's not so true from some perspectives (TTFB more important that flexibility of configuration)
12:18 khuckins joined #evergreen
12:23 * berick updates doc to clarify proposal of bypassing TT2 and including unit tests for core services.
12:25 berick i'll post to mail list later so we can resume discussion
12:37 Christineb joined #evergreen
13:01 miker thanks berick!
13:10 miker re my comment about speed vs flexibility: in a "web app" world, while lazy loading is still a thing, most of the cost that tt2 imposes would still be paid on the initial app load, not on each interaction as it is right now in the tpac. the separation of display customization/restriction from page element rendering (in that, today, the "whole page" is rendered only after all logic completes, whereas that cost can be frontloaded in a web app so renderin
13:10 miker is as fast as the immediately required data can be delivered) gives us a tonne of breathing room WRT speed.  for instance, berick's example angular opac is hella fast compared to the tpac because it doesn't repeat itself and just pays the cost of template loading (writ large) up front. TTFB for a web app is not important when TTFB for the interaction-driven rendering is not encumbered by the page scaffolding load time.  all of that to say, if there's
13:10 miker a way to tell angular to fetch its templates from a live url as needed, that'd be super dope.
13:13 kmlussier Where can I see berick's example angular opac that is super fast?
13:14 berick the speed issue is not my main concern, but to be far, that doesn't take into consideration the template rendering time of each component during navigation.  there's an extra layer of html parsing for every component rendered in angularjs vs angular.
13:14 berick maybe not the biggest deal, but it is a thing
13:14 jeff potentially useful with regard to on-demand/runtime loading of components/templates: https://angular.io/guide/dynamic-component-loader
13:15 berick yes, comonents can be dynamically loaded, but they still have to be statically compiled
13:15 berick the component blob can be fetched from the server
13:15 berick but the blob is a pre-compiled angular blob
13:15 jeff sorry, I guess I didn't transcribe some brainstorming that wjr and i were having. ;-)
13:16 berick jeff: no need to apologize, just clarifying
13:16 jeff i think this would support "here's the evergreen blob" + "here's our local stuff" blob.
13:16 berick jeff: yeah, that's a possibility
13:16 jeff which may or may not be different enough from "here's a blob per org" to make the added effort worth it.
13:17 berick kmlussier: https://35.186.179.218/eg2/staff/login
13:18 jeff not surprisingly, berick beat me to the link -- it was referenced here: http://git.evergreen-ils.org/?p=wor​king/random.git;a=blob_plain;f=ang2​-preso.html;hb=collab/berick/eg2018#(19)
13:18 kmlussier Oh, yes, I've seen that before somewhere.
13:19 kmlussier Possibly while sitting in on that very presentation. berick++ jeff++
13:23 beanjammin joined #evergreen
13:24 miker If we can make building the blobs something that doesn't require a developer's environment (as in, the tool needed to refresh the blobs from "source" templates is a single make-web-changes-live.sh or something that lives in /openils/bin/ and understands a configuration file that is analogous to the tt2 template directives in the apache config today) then I could get behind it, certainly
13:26 berick miker: cool.  i will definitely give that some thought
13:26 miker but if we're perforce dropping tt2, we need to figure out how to manage customizations in an Official(tm) way, period IMNSHO ;)
13:27 miker one of the benefits of tt2 is that /is/ a prescribed customization mechanism. letting a thousand flowers bloom under angular will just make us cry in the long run, I fear
13:28 berick i completely agree we need a One True Way
13:29 miker (and that One True Way should not require a source tarball, or 200MB+ of dev env...)
13:30 miker and, ftr, http://www.template-toolkit​.org/docs/tools/ttree.html
13:32 miker not that that helps directly with how we use tt2 today, but if there's still a use for it as a known first-level templating system (pre-angular-cli), then that's the thing we can use to go from small chunks of tt2 to composed (multiple piles of) html ready for angular to digest
13:44 gmcharlt piping up after lunch... I do have concerns about whether for the /web staff/ client we should really be that keen to encourage run-time customization beyond what we can support by readily injecting bits of CSS and JavaScript, similar to Koha's customization features
13:45 gmcharlt and it might be more user-friendly to supply a lot more knobs
13:46 gmcharlt admittedly, that means a lot more YAOUSes
13:52 _bott_ shiny new 3.1.1 install. DB upgraded, searching and web client all happy. But... my highlighting isn't working, and it's driving me nuts. Logs show all the right queries, I just don't get any style changes. Thoughts?
13:55 JBoyer gmcharlt, that's a good point. There probably isn't much call for significant client customization aside from changing what's on the splash page (which can be done differently... say something like bug 1720361 with built-in command names for client actions, regular links for uh, regular links).
13:55 pinesol_green Launchpad bug 1720361 in Evergreen "Custom links for splash page" [Wishlist,New] https://launchpad.net/bugs/1720361
13:56 JBoyer _bott_, any custom template overrides for the CSS or results page?
13:57 rlefaive left #evergreen
14:16 miker gmcharlt: fair point. my fear (theoretical as it is) is having YAOUSen for staff angular and some other (much more flexible, ideally matching the capabilities of tt2, see: the various opacs that don't look like stock EG) customization mechanism for a dreamt-of angular opac
14:18 gmcharlt miker: yeah - implicitly in my statement, I'm viewing the OPAC, both current and a potential angular one, as being a different ball of wax
14:18 miker because we won't be able to de-support the YAOUSen pretty much ever, if history is a guide. and then we have two ways to do one thing
14:18 gmcharlt different from the staff interface, to be clear
14:19 miker yeah, that's a choice we can make, if we are willing to maintain two catalog code bases (that may be slightly hyperbolic, but I honestly don't know to what degree it is)
14:20 berick good to consider now.  as the PoC code is built, it assumes a single-app-for-everything.  we obviously don't have to do that, though.  they can be different apps that use all the same shared code.
14:20 berick and we can share or not-share as much code as we want
14:21 agroff joined #evergreen
14:22 miker if the staff "skin" code is just the baseline upon which we build the patron stuff, having a directive that wraps the catalog up in a bundle might be a good separation point. if that even makes sense in angular6+...
14:23 miker if there are still things like parent scopes, from which the scope of the catalog directive could absorb parameters (rather than, say, directly from the route as it might in the public version) the it's probably doable?
14:24 miker (assuming routes still work in an analogous way to angularjs)
14:25 _bott_ JBoyer: nope, straight out of the box download and setup
14:27 kmlussier _bott_: Are index configurations out of the box too?
14:29 khuckins_ joined #evergreen
14:31 JBoyer rhamby, re: above_the_treeline_extract.pl: lines 145-147 have 4 params to put_file and so will be very confused. (doubled up commas in params)
14:38 rhamby Jboyer++ : good catch, don't know how that snuck in
15:05 _bott_ kmlussier: which indexes, specifically? It was a DB upgrade, so there were existing changes in legacy tables.
15:11 kmlussier _bott_: IIRC, it's important to ensure that your search fields are also enabled as display fields. You're right, that change should have been made to legacy tables in the upgrade script.
15:12 kmlussier The display fields also need to be used in the tt2 files, but, if you're using out-of-the box templates, that should already be there. Also, the reingest is required.
15:19 _bott_ kmlussier: yes, I caught the display_field updates, those are good to go. The logs show the cstore calls to search.highlight_display_fields, I'm trying to parse one of those out to test it directly, but it looks to be returning successfully.
15:20 kmlussier _bott_: OK, that's all I've got.
15:26 JBoyer _bott_, Nothing else is coming to me either, I just realized I kind of wandered off there. The only trouble I had with highlighting is deciding what color I'm going to change the default to for the production upgrade.
15:26 _bott_ DOH! metabib.display_entry table is empty!
15:27 _bott_ JBoyer: no worries. I sent a message and got tied up in a phone call, so it took me a bit to wander back
15:27 JBoyer Sounds like you just figured it out though, so huzzah.
15:32 idjit found an omission from the documentation. following instructions at http://evergreen-ils.org/documentati​on/install/OpenSRF/README_3_0_0.html. section 15 ("websockets installation instructions") final step (8: /etc/init.d/apache2-websockets start) fails on ubuntu 16.04 until you run `systemctl daemon-reload`.
15:36 miker idjit: well, systemd is involved, so failure is expected
15:38 kmlussier remingtron: Rather than starting a new bug for the confusing description on the Claims Returned OU, I was thinking we could tack it on to bug 1766262
15:38 pinesol_green Launchpad bug 1766262 in Evergreen "Remove org unit settings that are no longer valid in web client" [Wishlist,Confirmed] https://launchpad.net/bugs/1766262
15:39 idjit miker: indeed, :-) i figured someone meant to include that step, but i'm not sure how to update the docs myself for anyone else working through this in the future.
15:39 idjit systemd--
15:39 kmlussier It was originally created for removing settings, but I think it could apply to fixing any OU settings with xul-era logic.
15:42 remingtron kmlussier: that makes sense
15:43 remingtron I also realized that bug 1325704 is related, so I might include the setting fix with that branch.
15:43 pinesol_green Launchpad bug 1325704 in Evergreen "Correction to long overdue documentation" [Undecided,In progress] https://launchpad.net/bugs/1325704 - Assigned to Remington Steed (rjs7)
15:47 miker idjit: thanks for the report!
15:47 kmlussier remingtron++
16:17 khuckins joined #evergreen
17:04 Bmagic jeff++ # Forensic science
17:09 mmorgan left #evergreen
17:14 pinesol_green [evergreen|Remington Steed] Docs: Update Long-overdue docs for web client - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=e9b08bc>
17:54 Christineb joined #evergreen
18:32 beanjammin joined #evergreen
18:32 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
23:05 jeff_ joined #evergreen
23:12 jeff__ joined #evergreen

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