| 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/Evergreen.git;a=blob;f=Open-ILS/src/eg2/src/app/staff/sandbox/sandbox.component.html;h=b66343436db2cfa4dcd159896bd4875118d5718f;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=working/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/documentation/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 |
