| Time |
Nick |
Message |
| 06:31 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
rjackson_isl joined #evergreen |
| 07:46 |
|
agoben joined #evergreen |
| 08:41 |
|
rlefaive joined #evergreen |
| 08:46 |
|
Dyrcona joined #evergreen |
| 09:02 |
|
rlefaive joined #evergreen |
| 09:10 |
|
rlefaive joined #evergreen |
| 09:11 |
|
kmlussier joined #evergreen |
| 09:15 |
|
rlefaive joined #evergreen |
| 09:26 |
|
rlefaive joined #evergreen |
| 09:27 |
|
yboston joined #evergreen |
| 09:35 |
|
rlefaive joined #evergreen |
| 09:57 |
|
littlet joined #evergreen |
| 10:10 |
|
terran joined #evergreen |
| 10:12 |
|
mmorgan joined #evergreen |
| 10:17 |
terran |
mmorgan++ and Dyrcona++ for attempting to help me with Novelist. Apparently they have customized our code to filter suggestions based on the value of locg in the URL and when locg isn't there, it breaks |
| 10:17 |
terran |
So that should hopefully be an easy fix on their end |
| 10:18 |
terran |
I notice that it works either way in NOBLE's catalog |
| 10:19 |
mmorgan |
Yay! terran's hair is saved! |
| 10:19 |
Dyrcona |
terran: Glad you were able to figure it out. |
| 10:19 |
terran |
Now on to Syndetics :D |
| 10:21 |
kmlussier |
terran: That's awesome! |
| 10:21 |
* kmlussier |
hopes for a quick Syndetics solution. That would truly be a good day for terran. |
| 10:23 |
terran |
Between berick++ fixing the bill payment receipt problem on Monday and then me figuring out Novelist yesterday, this week is shaping up nicely so far! |
| 10:23 |
terran |
* terran waits for the other shoe to drop... |
| 10:35 |
Bmagic |
I have something interesting. We have a library that has a policy which requires that Juvenile patrons to "reregister" when they become adults. Basically, sign the document, then the staff will remove the juvenile flag. |
| 10:36 |
Bmagic |
In order to prevent the flag from being removed automatically, we changed their library setting for juveniles to 1000 years |
| 10:36 |
Dyrcona |
It's a stupid policy. Tell them to change it. |
| 10:36 |
Bmagic |
Everything is fine, because they want to manually remove the flag. But now that we are using the Web based staff client, they cannot clear the juvenile flag! There is javascript on the page doing the date math |
| 10:37 |
berick |
Bmagic: it's not that interesting, it's just a bug ;) |
| 10:37 |
kmlussier |
Sounds like a bug that should be filed. |
| 10:37 |
kmlussier |
berick beat me to it. :) |
| 10:37 |
Bmagic |
really? It sounds like it's a feature |
| 10:38 |
Dyrcona |
Well, one person's bug is another's feature. |
| 10:38 |
berick |
Bmagic: it is a feature, but staff should be able to override |
| 10:38 |
Bmagic |
Someone had to write more code to make it do that |
| 10:38 |
Dyrcona |
It's still a stupid policy. |
| 10:38 |
berick |
the intent of the code IIRC is to set a default, not to force a value |
| 10:38 |
Bmagic |
Dyrcona: agreed |
| 10:39 |
kmlussier |
Well, I'm sure there are other instances where staff want to manually remove the juvenile flag, regardless of that particular policy. |
| 10:39 |
miker |
Bmagic: it is a feature if you use the "de-juvenile-ifier" ... except for emancipated minors. doh! |
| 10:39 |
miker |
(IMO, I should add) |
| 10:39 |
Dyrcona |
Yes, I agree the behavior of the staff client is a bug. |
| 10:39 |
Bmagic |
well, if we all agree that it's a bug, then I suppose that is the path forward. I was thinking we would use a stat cat for them |
| 10:57 |
Bmagic |
Debbie has a question about the conference. Who is facilitating the Hackfest at the conference? |
| 10:58 |
terran |
I'm not sure that anyone has volunteered yet |
| 11:02 |
Dyrcona |
Someone usually steps up that morning, typically gmcharlt. |
| 11:18 |
|
mdriscoll joined #evergreen |
| 11:33 |
gmcharlt |
I'm willing to volunteer |
| 11:36 |
terran |
gmcharlt++ |
| 11:39 |
|
rlefaive joined #evergreen |
| 11:47 |
berick |
gmcharlt++ |
| 11:49 |
|
mmorgan1 joined #evergreen |
| 11:51 |
|
khuckins joined #evergreen |
| 11:51 |
|
mmorgan2 joined #evergreen |
| 11:56 |
|
Christineb joined #evergreen |
| 12:02 |
|
rlefaive_ joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:12 |
|
jihpringle joined #evergreen |
| 12:18 |
|
rlefaive joined #evergreen |
| 12:20 |
pinesol_green |
[evergreen|Cesar Velez] LP#1739669 - add PaymentType and persistkey bill payment hist grid - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2a9d6c6> |
| 12:37 |
|
rlefaive joined #evergreen |
| 12:43 |
phasefx |
stock concerto data, Staff has the VIEW_BILLING_TYPE permission at depth 1. Would you expect for them to be able to create bills with the stock Misc billing type, owned by the Consortium? |
| 12:44 |
phasefx |
if nothing else, there's a difference in behavior here between webby (using pcrud) and xul (using open-ils.circ.billing_type.ranged.retrieve.all) |
| 12:44 |
* phasefx |
will bug it |
| 12:48 |
Dyrcona |
What's the difference? Staff can use Misc in XUL and not in webby? |
| 12:51 |
kmlussier |
phasefx: Yes, I would expect them to be able to use the stock Misc billing type. |
| 12:52 |
Dyrcona |
So, would I. |
| 12:53 |
|
rlefaive joined #evergreen |
| 12:53 |
* Dyrcona |
probably should have paid more attention to Lp 1167541. |
| 12:53 |
pinesol_green |
Launchpad bug 1167541 in Evergreen 2.11 "Pickup library defaults to Home OU of staff, instead of patron when placing holds" [Medium,Fix released] https://launchpad.net/bugs/1167541 |
| 12:57 |
kmlussier |
Dyrcona: Yeah, I feel the same way. For some reason, when it went in, I had been thinking it was using the staff workstation. |
| 12:58 |
Dyrcona |
My latest remarks not withstanding, I guess a setting is the only way out of it, now. Particularly in light of who signed off on the commit. :) |
| 12:59 |
Dyrcona |
A setting complicates things further. |
| 13:04 |
jeff |
Hrm. |
| 13:04 |
JBoyer |
I'll admit I came in complaining a little late in the game, but my reasoning is that the only thing worse than making a patron preference not apply at all is making it apply "sometimes." |
| 13:04 |
Dyrcona |
Well, I stated my thoughts on the new bug, so I won't repeat them here. |
| 13:05 |
JBoyer |
Explaining any of this to a patron who has complained that sometimes their items go here and sometimes there will at best result in a glassy eyed stare. |
| 13:05 |
|
mllewellyn joined #evergreen |
| 13:05 |
Dyrcona |
I'll add this: I think we sometimes put too much on the software. The human user should take some responsibility for what's going on. |
| 13:07 |
miker |
phasefx: yeah, looks like we should just use the existing API rather than pcrud |
| 13:08 |
Dyrcona |
miker: One person's bug is another's feature. :) |
| 13:08 |
Dyrcona |
And that's twice I've said that today. :) |
| 13:10 |
|
collum joined #evergreen |
| 13:10 |
mmorgan2 |
I think a change in behavior of the software brings a lot of things to light. If staff are used to it working one way, and it changes, they need to adjust their interaction with the patron. |
| 13:11 |
miker |
Dyrcona: re billing types? |
| 13:11 |
Dyrcona |
No, re hold pickup location for staff-mediated holds. |
| 13:12 |
kmlussier |
I also wonder if there is a difference in expectation in places that tend to have large county and multi-branch systems as opposed to consortia mostly made up of standalone libraries. |
| 13:13 |
Dyrcona |
That could be part of it. |
| 13:13 |
miker |
oh, sure. and I don't disagree with you about making it simpler and just using ws ou. that at least has the benefit of perfectly predictable defaults. but I agree a little more with JBoyer that honoring the user setting is everywhere is good... |
| 13:15 |
mmorgan |
If we're doing an ou setting, it should be flexibile enough to allow libraries that want to default to staff workstation over user setting for staff placed holds to do that. |
| 13:16 |
|
rlefaive joined #evergreen |
| 13:16 |
miker |
mmorgan: that's my proposal |
| 13:17 |
miker |
but not my preference ;) |
| 13:17 |
* Dyrcona |
now prefers not defaulting and making staff choose something. That forces them to ask the patron. |
| 13:18 |
Dyrcona |
But that'll go over like a lead zeppelin.... |
| 13:20 |
Dyrcona |
So, I imagine it does make sense in a county system with many branches. |
| 13:21 |
Dyrcona |
You call the main branch to place the hold, but you pick it up in the local branch. |
| 13:21 |
Dyrcona |
Here, where we don't have county systems, it makes much less sense to do it that way. |
| 13:22 |
Dyrcona |
I wouldn't call Andover Public Library to place a hold for me for pickup in Amesbury, for instance. |
| 13:23 |
miker |
the pines crowd could set the pref for all users that don't have it at upgrade time... |
| 13:23 |
miker |
pines-like |
| 13:24 |
Dyrcona |
I think I like use the patron setting, if set, otherwise using workstation ou, or nothing at all. |
| 13:25 |
kmlussier |
But do we know that this is just an issue for pines? I seem to recall that rhamby was also advocating for patron home library back in his SC LENDS days when the bug was first filed. |
| 13:25 |
rhamby |
kmlussier: scrolling up to read |
| 13:25 |
kmlussier |
Not that I'm trying to convince people to go back in that direction. :) |
| 13:26 |
Dyrcona |
So, maybe the setting should just be use workstation ou or patron home ou, and use the patron preference in either case. |
| 13:26 |
rhamby |
yes, I remember that bug well, and yes, it would be a welcome change for most larger resource sharing consortia I think |
| 13:27 |
kmlussier |
rhamby: The change has already come. The complaint is from all the libraries who didn't like the change. :) |
| 13:27 |
Dyrcona |
:) |
| 13:27 |
rhamby |
sorry, tenses are off (it's one of those days) ... is welcome |
| 13:28 |
rhamby |
kmlussier: you just want an excuse to add more org unit settings |
| 13:29 |
* abneiman |
noting that kmlussier DOES have that "YAOUS" mug ;-) |
| 13:29 |
kmlussier |
abneiman: I think I'm the only one. |
| 13:29 |
rhamby |
kmlussier: you are |
| 13:30 |
kmlussier |
But I do like software that is flexible for the varied libraries/consortia that uses it. |
| 13:30 |
rhamby |
that's kinda what I said |
| 13:30 |
kmlussier |
I also like the setting mmorgan recommended in the bug. |
| 13:31 |
* mmorgan |
just wants it to work for everyone :) |
| 13:31 |
* rhamby |
is getting warmed up giving kmlussier grief since the outreach meeting is in 30 minutes |
| 13:31 |
Dyrcona |
mmorgan: Good luck with that! ;) |
| 13:33 |
rhamby |
kmlussier: which comment is mmorgan's suggestion under, I don't see it skimming the page |
| 13:34 |
kmlussier |
rhamby: https://bugs.launchpad.net/evergreen/+bug/1699838/comments/11 |
| 13:34 |
pinesol_green |
Launchpad bug 1699838 in Evergreen "OU setting needed for default pickup location for staff placed holds" [Medium,Confirmed] |
| 13:35 |
rhamby |
ah, I see, I was looking at the old bug listing |
| 13:35 |
kmlussier |
Really, I think there are just three scenarios that are being suggested here. workstation all the time, patron default -> workstation, patron default -> patron home library. |
| 13:35 |
kmlussier |
Not too difficult to make everyone happy in this one instance. |
| 13:37 |
rhamby |
I'm fairly ambivalent. The original behavior was undesirable in my opinion back in 2013 but I think so many people have now adjusted to it that it's the new normal so now how they would have wanted it then is now undesirable. |
| 13:38 |
rhamby |
IOW, the desired behavior is whatever you're used to (for many) |
| 13:43 |
mmorgan |
Folks get accustomed to the way things work, they have to. When "the way things work" changes, and it doesn't work out for some, we get the opportunity to make it work better. |
| 13:44 |
Dyrcona |
Well, I suggested leaving the pickup ou unset, but if you blinked you missed it. |
| 13:48 |
|
sandbergja joined #evergreen |
| 13:51 |
|
mllewellyn left #evergreen |
| 14:00 |
phasefx |
a long time ago I was wondering how would treat a given setting that existed in multiple places (user, org, workstation, client), and how one might weight them, and I gave up and ran away |
| 14:10 |
Dyrcona |
phasefx: There aren't many of those are there? |
| 14:12 |
phasefx |
no, but I was imagining some generic infrastructure that would apply to everything |
| 14:12 |
phasefx |
we do have some warts |
| 14:13 |
phasefx |
let's make column settings stickly.. no let's make that read-only.. and/or let's serve the defaults from a remote URL |
| 14:13 |
phasefx |
IMO |
| 14:13 |
Dyrcona |
Yeah, I see what you're saying. |
| 14:14 |
phasefx |
stickly = sticky / sickly |
| 14:15 |
Dyrcona |
heh |
| 14:28 |
JBoyer |
We could try to follow CSS's lead, more specificity = more priority. Cons, org, workstation, user. Don't want to worry about a use case, make it a permission and don't give it to anyone. :) |
| 14:30 |
phasefx |
might have some objects that end up being peers, not sure what is more specific |
| 14:34 |
Dyrcona |
Well, in general, it should probably go user setting, org. setting, workstation, client, but there will be exceptions, I'm sure. |
| 14:34 |
phasefx |
but yeah, we could define just one order of precedence |
| 14:34 |
Dyrcona |
:) |
| 14:34 |
phasefx |
and someone somewhere would want to change it :) |
| 14:35 |
Dyrcona |
Of course. |
| 14:36 |
Dyrcona |
And, that's why one ends up with 9 git customization branches. :) |
| 14:43 |
Dyrcona |
I love how a rebase can run into issues with different commits in the branch being rebased. |
| 14:43 |
Dyrcona |
You wouldn't think it would have a problem with your own commits, but it can. |
| 14:45 |
Dyrcona |
Even in files that don't exist in the branch you're rebasing onto... or is it from? |
| 14:46 |
Dyrcona |
Oh, yuck. This is why I often just delete branches and remake them over again. |
| 14:48 |
JBoyer |
phasefx++ # bug 1747990 |
| 14:48 |
pinesol_green |
Launchpad bug 1747990 in Evergreen "list of billing types is gathered differently between XUL client and web client" [Undecided,New] https://launchpad.net/bugs/1747990 |
| 14:50 |
JBoyer |
Without climbing (too high) on my high horse, any call to pcrud.* should be a candidate to become a "real" API call. |
| 14:52 |
berick |
JBoyer: from my perspective, if a real API already exists that solves a problem (e.g. the billing types) then we should probably use it. I would not advicate for moving away from pcrud. it's part of what helps speed up the browser client. |
| 14:53 |
berick |
pcrud is our friend, except when it's not quite up to the job. |
| 14:54 |
JBoyer |
There's no reason any other type of call needs to be significantly slower, the fact that some are currently shouldn't be caused by what service they live in. |
| 14:55 |
berick |
if that were true, we would never have written anything in C :( |
| 14:56 |
gmcharlt |
yeah, there is an inherent cost to Perl code and subrequest hops, though to be fair, it's not everythign that requires sub-10-millisecond latency |
| 14:56 |
JBoyer |
I'm not doing a very good job getting out what I'm trying to say. |
| 14:57 |
phasefx |
I always thought of pcrud as a convenience for the developer; easier to throw some perms and a controller into the IDL than writing API |
| 14:57 |
miker |
phasefx: that's the intent, yes. when you just need an ORM, not biz logic, use pcrud |
| 14:57 |
JBoyer |
I don't see why calling one perl function in a perl service should be significantly slower than calling a different function in another perl service (except that I realize one may be a lot thinner/thicker than the other which can slow down instatiating new children, etc.) |
| 14:58 |
miker |
JBoyer: pcrud is C... |
| 14:58 |
miker |
to provide numbers: perl APIs have a latency of ~10-20ms/message on average, C APIs have 2-5ms latency |
| 14:58 |
JBoyer |
Oh, right. |
| 14:58 |
JBoyer |
I did forget about that. (I was thinking cstore was, forgot pcrud.) |
| 14:58 |
gmcharlt |
2 minute meeting warning |
| 14:59 |
berick |
i will also note not having a proliferation of apis to maintain (vs. autogenerated) is a bonus. |
| 15:00 |
JBoyer |
Oops, I got too high up on my horse. :) Anyone who wants to hear me grouse can do so some other time when it won't interfere with a meeting. |
| 15:00 |
berick |
JBoyer++ |
| 15:00 |
JBoyer |
berick, that's a separate thing I also have opinions about. I'll spare everyone. ;) |
| 15:01 |
gmcharlt |
:#startmeeting Evergreen Development Meeting, 7 February 2018 |
| 15:01 |
gmcharlt |
#startmeeting Evergreen Development Meeting, 7 February 2018 |
| 15:01 |
pinesol_green |
Meeting started Wed Feb 7 15:01:25 2018 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:01 |
pinesol_green |
The meeting name has been set to 'evergreen_development_meeting__7_february_2018' |
| 15:01 |
gmcharlt |
#link Agenda is (*cough*) https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2018-02-06 |
| 15:01 |
gmcharlt |
#topic Introductions |
| 15:01 |
gmcharlt |
#info gmcharlt = Galen Charlton, Equinox |
| 15:02 |
berick |
#info berick Bill Erickson, KCLS |
| 15:02 |
phasefx |
#info phasefx = Jason Etheridge, Equinox |
| 15:02 |
miker |
#info miker = Mike Rylander, EOLI |
| 15:02 |
phasefx |
had to be different ;) |
| 15:02 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:03 |
jeffdavis |
#info jeffdavis = Jeff Davis, BC Libraries Coop (Sitka) |
| 15:03 |
dbs |
#info dbs = Dan Scott, Laurentian University |
| 15:03 |
|
khuckins_ joined #evergreen |
| 15:03 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Equinox OLI |
| 15:03 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 15:03 |
rhamby |
#info rhamby = Rogan Hamby, EOLI |
| 15:05 |
gmcharlt |
#topic Action items |
| 15:05 |
JBoyer |
#info JBoyer = Jason Boyer, IN State Library |
| 15:05 |
gmcharlt |
a couple just carry over, again :/ |
| 15:05 |
gmcharlt |
#action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF |
| 15:06 |
gmcharlt |
#action gmcharlt will work on patches destined for a release of OpenSRF 3.0.1 in Feburary |
| 15:06 |
gmcharlt |
dbwells: did you have a chance to tweak the downloads page to make Hatch more visible? |
| 15:06 |
dbwells |
no, sorry :( |
| 15:07 |
gmcharlt |
#action dbwells will tweak the Evergreen downloads page to unbury the Hatch download link |
| 15:08 |
gmcharlt |
though speaking of Hatch, I've updated the downloads page just now to reflect 0.15 |
| 15:08 |
gmcharlt |
er, 0.1.5 |
| 15:08 |
berick |
thanks gmcharlt |
| 15:08 |
JBoyer |
gmcharlt++ |
| 15:08 |
gmcharlt |
so moving on in topics |
| 15:08 |
gmcharlt |
not much to say about OpenSRF |
| 15:08 |
gmcharlt |
so |
| 15:08 |
gmcharlt |
#topic Evergreen release update |
| 15:08 |
gmcharlt |
dbwells, you ahve the floor |
| 15:09 |
dbwells |
Well, the most important thing to note is the deadline this Friday for "feature slush". |
| 15:09 |
miker |
dbwells: does that mean "no more targeting of features"? |
| 15:09 |
dbwells |
Realistically, folks have until Monday if they wish to keep pushing on something. |
| 15:09 |
miker |
or "no more merging unless you're called dbwells" |
| 15:10 |
dbwells |
Closer to the first, definitely. |
| 15:10 |
miker |
kk |
| 15:11 |
dbwells |
to quote: "at this point, all significant features should either have been merged or at least have LP bugs and pullrequests" |
| 15:12 |
dbwells |
As part of my email from 1/25, I sent out a first go at trying to organize improvement to code comments. I really didn't (and still don't) know whether it is or will be helpful or not. |
| 15:12 |
dbwells |
Response has been, shall we say, underwhelming :) |
| 15:13 |
dbwells |
I'm hopeful still for movement before this release is in the books. |
| 15:14 |
jeffdavis |
dbwells: I wasn't sure whether to volunteer to review EbookAPI code since I wrote pretty much all of it? |
| 15:14 |
jeffdavis |
happy to do so if that isn't an issue though |
| 15:15 |
dbwells |
I'll be sending another update to the list with various notes in the next few days. |
| 15:15 |
dbwells |
jeffdavis: If it needs it (not looking), you are the perfect person for the job! |
| 15:15 |
jeffdavis |
ok will do |
| 15:16 |
dbwells |
I think that is all for now, unless there are questions. |
| 15:16 |
gmcharlt |
just noting that I'm tidying up a few follow-ups for bug 1676608 this afternoon |
| 15:16 |
pinesol_green |
Launchpad bug 1676608 in Evergreen "Copy Alert Persistence and Suppression Matrix" [Wishlist,New] https://launchpad.net/bugs/1676608 |
| 15:18 |
gmcharlt |
moving |
| 15:18 |
gmcharlt |
#topic Hatch update |
| 15:18 |
gmcharlt |
#info Hatch 0.1.5 released |
| 15:18 |
gmcharlt |
#info Version number bumps are requested to be included as a separate commit |
| 15:18 |
gmcharlt |
berick: JBoyer: anything else? |
| 15:19 |
JBoyer |
+1 to separate version bumps, |
| 15:19 |
berick |
nothing else from me. just thanks for all the fixes |
| 15:19 |
JBoyer |
Other than trying and completely failing to get FF to even see it I don't have anything else. |
| 15:20 |
gmcharlt |
OK, then moving on |
| 15:20 |
gmcharlt |
#topic Discussion on mixed use of voids / account adjustments |
| 15:20 |
gmcharlt |
#link https://bugs.launchpad.net/evergreen/+bug/1671856 |
| 15:20 |
pinesol_green |
Launchpad bug 1671856 in Evergreen "Mixed use of Account Adjustment payments creates inconsistency" [Undecided,New] |
| 15:23 |
gmcharlt |
so... any discussion? are we closer to a decision? |
| 15:23 |
JBoyer |
A thought since discussion isn't loud and immediate: What if anything that used to void billings continued to do so and if any balance goes negative as a result a new billing is added to offset and even out the transaction? |
| 15:24 |
kmlussier |
At this point, I'm in favor of berick's approach to help out the people who never want to use account adjustments. |
| 15:24 |
JBoyer |
(Forgive me if that's been shot down already, I know that's not happening in the 3.1 timeframe) |
| 15:25 |
kmlussier |
But I'm still highly interested in the proposed UI changes from dbwells. |
| 15:25 |
berick |
i'm also interestd in the UI changes |
| 15:27 |
gmcharlt |
then it sounds like we're basically continuing the discussion then... although not necessarily during this meeting? |
| 15:28 |
|
ngf42 joined #evergreen |
| 15:28 |
kmlussier |
Well, if the UI changes aren't forthcoming shortly, is there any reason we can't move forward with berick's patch? |
| 15:28 |
dbwells |
I've said a lot on the bug, and expect to have a branch to show for the Friday/Monday deadline. It seems best to have something to react to rather than just my attempts to explain things conceptually. |
| 15:29 |
kmlussier |
dbwells: Ooh! That's exciting. |
| 15:29 |
gmcharlt |
ok, then that sounds like it will turn into a binary decision, at least for the short-term purposes of 3.1 |
| 15:30 |
* JBoyer |
will try to contribute less noise if he doesn't have a firm grasp on the issue at hand.. |
| 15:30 |
gmcharlt |
i.e., go with berick's or dbwells' patches by the time feature freeze rolls around |
| 15:30 |
gmcharlt |
does that sound like a fair summary? |
| 15:30 |
kmlussier |
+1 |
| 15:31 |
gmcharlt |
so moving on |
| 15:31 |
gmcharlt |
#topic Discussion on iOS support for web client |
| 15:31 |
gmcharlt |
#link http://georgialibraries.markmail.org/thread/rijxfn7s2fjo4mf7%7D |
| 15:31 |
gmcharlt |
#link https://bugs.launchpad.net/evergreen/+bug/1746020 |
| 15:31 |
pinesol_green |
Launchpad bug 1746020 in Evergreen "Unable to log into web client on iOS" [Medium,Fix committed] |
| 15:32 |
gmcharlt |
er, rather |
| 15:32 |
gmcharlt |
#link http://georgialibraries.markmail.org/thread/rijxfn7s2fjo4mf7 |
| 15:32 |
gmcharlt |
so, of course, what is not explicitly blocked users will do anyway ;) |
| 15:33 |
gmcharlt |
but in the short term, folks have been loading the web client in iOS in the wild |
| 15:33 |
gmcharlt |
and although it's not officially supported, it worked well enough for folks to log on, broke, and is getting unbroken for 3.0.4 |
| 15:33 |
dbs |
I guess the least we can do is document things we know won't / can't work (offline support, whatever Hatch does, ...) |
| 15:34 |
gmcharlt |
yeah |
| 15:35 |
gmcharlt |
and going further, is there any appetite to take it a bit further to put in guards against access the stuff known not to work? and interest in cycles on the part of anybody to do testing against iOS/Safari? |
| 15:35 |
JBoyer |
I don't imagine that many iOS users are interested in printing receipts (Hatch's primary use case). The idea of taking whatever tablet you have on hand into the stacks to capture holds live and without printing anything is something that comes up on occasion when discussing the web client. |
| 15:35 |
kmlussier |
From our perspective, when we decided early on that Chrome and Firefox would be supported browsers, we didn't think it would preclude use on iOS devices since those browsers can be used there. |
| 15:36 |
kmlussier |
I could see a use case for using offline circ on an iPad, but I think if we make it clear that it won't work on iOS, that's a good start. |
| 15:37 |
gmcharlt |
yeah, at the moment anybody who badly wants offline circ on an ipad probably needs to consider writing a native app |
| 15:37 |
JBoyer |
I don't like telling anyone that they can't use a currently supported modern browser when the current breakage is small to unnoticeable. That said I don't know that I'd want to spend a lot of time getting Edge to work. |
| 15:37 |
kmlussier |
gmcharlt: I can't commit to testing against iOS/Safari, but I might be able to find people who can. |
| 15:38 |
gmcharlt |
yeah, blocking service-worker-based offline in iOS would be doable |
| 15:38 |
gmcharlt |
but one thing I'm wondering is what other uses, if any, we want to apply service workers to |
| 15:39 |
miker |
in the long run, they could streamline a lot of things. but it's not just service workers, it's broadcast channels between tabs on the same domain |
| 15:39 |
miker |
that's the actual current breakage, IIUC |
| 15:39 |
berick |
yeah |
| 15:39 |
JBoyer |
I don't personally see any point aside from offline circ in a staff client. You're not going to que up searches to do later when the connection comes back as you might prep emails to send while offline. |
| 15:40 |
dbs |
Normally they're a progressive enhancement (speed etc) but offline support is obviously a different matter :) |
| 15:40 |
miker |
JBoyer: but lots of folks want to have tabs sync on updates |
| 15:40 |
gmcharlt |
on the other hand, multi-tab might be less of a concern for mobile devices |
| 15:40 |
miker |
that's a very common request, and broadcast channels make that nearly trival |
| 15:40 |
gmcharlt |
(although not for Safari on the desktop) |
| 15:40 |
miker |
well, not in the way we use tabs today, really |
| 15:41 |
miker |
we open a new tab instead of using huge modals |
| 15:41 |
miker |
because there's just not enough screen space on even a huge modal for most complex UIs |
| 15:41 |
JBoyer |
I'm not against using broadcasts channels or SWs, I'm against requiring them outright. Having to if (exists...) before every call would be irritating, but putting those calls somewhere in the right service would allow progressive enhancement like dbs mentioned |
| 15:41 |
miker |
copy editor for instance |
| 15:42 |
gmcharlt |
hmm, MessageChannel /does/ have broader support, and it looks like there's at least one BroadcastChannel polyfill that could use it |
| 15:43 |
berick |
i'm less concerned about a specific technology than I am about having to include another browser (possibly on multiple platforms) throghout the dev cycle. not saying it can't be done, but there is a definite cost. |
| 15:43 |
miker |
edge and ie claim messagechannel support, per caniuse.com |
| 15:44 |
berick |
i'm all for documenting issues, moving in that direction, but outright saying we support it is.. a bit more. |
| 15:44 |
gmcharlt |
berick: yeah, I think it in part depends on identifying folks/institutions willing to commit to it |
| 15:44 |
jeffdavis |
fwiw the Co-op is not in a position to support iOS in dev/testing, much as I'd like iOS to be supported |
| 15:44 |
miker |
berick: I agree with best-effort, until/unless there's a maintainer |
| 15:45 |
* berick |
nods |
| 15:46 |
kmlussier |
I understand the toll it takes, but mobile use was one of the selling points to get our libraries excited about moving to the web client. |
| 15:46 |
miker |
if we restrict our broadcast use to simple messages (and don't start depending on them in workers) then... the polyfill looks like it might be usable |
| 15:46 |
kmlussier |
And it's difficult to say it can do mobile if it can't run on iOS. So many of our libraries are using iPads and are excited about using them with the web client. |
| 15:47 |
dbs |
It's too bad there was that misunderstanding, we could have cleared that up very quickly last year even |
| 15:49 |
jeffdavis |
it's not an unreasonable expectation though, and taking steps to minimize breakage seems like good dev policy |
| 15:50 |
JBoyer |
That wasn't only a selling point in Massachusetts. Anyone that noticed that Bootstrap and / or Angular allowed fairly dynamic resizing (it's not perfect, obviously) immediately made the jump to "I can use this on an ...!" |
| 15:51 |
kmlussier |
My recollection was that mobile use was one of the initial investigation areas when the first protype was created. |
| 15:52 |
gmcharlt |
yeah; of course, part of the problem is that it's very much a contigent technical decision on Apple's part not to let non-Safari browsers on iOS uses their own engines |
| 15:52 |
miker |
aside from letting all the tabs know that you've logged out, and being able to do offline (that's apple's fault for forcing the safari engine on ios chrome/ff), master works now on mobile, right? |
| 15:53 |
kmlussier |
Yeah, well, that is annoying. But, unfortunately, Apple has a large share of that market. |
| 15:53 |
miker |
heh. what gmcharlt said |
| 15:53 |
|
khuckins__ joined #evergreen |
| 15:53 |
Dyrcona |
Yeah, but the user don't care whose fault it is. They just want it to work. |
| 15:53 |
JBoyer |
I've used it here and there on my phone when a question has come up away from a computer, it works fine aside from trying to edit things (a bit small.) |
| 15:54 |
kmlussier |
miker: I've heard that people can log in now. And the only issues I've heard otherwise were responsive design issues, not iOS issues. |
| 15:54 |
miker |
right |
| 15:54 |
miker |
and using it on a phone is ... a questionable decision, IMO. but an ipad? sure, let's try to allow in situ circ! |
| 15:55 |
JBoyer |
I don't recommend it to people, just noting it works. :p |
| 15:55 |
gmcharlt |
so, since we've got five minutes left, I'd like to move to the final agenda item |
| 15:55 |
gmcharlt |
so... |
| 15:55 |
dbs |
I mean, berick did hold up his phone during a session last year saying he had done something with webby so... :) |
| 15:56 |
gmcharlt |
#topic Improvements for QA tester |
| 15:56 |
phasefx |
so, there's really a larger topic here than what I put on the wiki :-/ |
| 15:56 |
berick |
dbs: i also said lots of other things.. |
| 15:56 |
phasefx |
I was disappointed in us (myself included) for letting the qatester languish in a fail state for a long period a short while back; and I also noticed that we've had only one working buildslave for buildbot since 2016 |
| 15:57 |
phasefx |
I'm willing to improve/fix/wrangle the tech side of things, but I'm not sure about culture/process |
| 15:58 |
phasefx |
some suggestions.. positive reinforcement from the tools instead of just negative feedback (winning streaks, etc.) |
| 15:58 |
phasefx |
putting QA reports on the agenda for every dev meeting |
| 15:59 |
phasefx |
I don't know what else... what do you guys think? |
| 15:59 |
gmcharlt |
the last in particular sounds like a useful, quickly implemented step |
| 15:59 |
gmcharlt |
maybe combined with a copy easy-to-calculate metrics of work done since the previous meeting |
| 15:59 |
gmcharlt |
e.g., commits added |
| 15:59 |
phasefx |
tests added |
| 15:59 |
phasefx |
tests fixed, tests removed |
| 16:00 |
JBoyer |
Dev meeting reports are a good idea, especially if it can keep most of the stats going so you don't have to do a lot behind the scenes. And I agree with not wanting only negative feedback. |
| 16:01 |
phasefx |
and of course, I still want what I put on the agenda, tech/feature suggestions :) |
| 16:01 |
JBoyer |
That said, one common piece of negative feedback is "you broke the build!" notifications. I don't think we want to have a stoplight board like some projects I've seen (What did JBoyer do now?) But a gentle nudge to the author of a commit that broke things may be helpful. |
| 16:02 |
gmcharlt |
do I remember correctly that the the tests are run once or twice a day, not triggered when stuff is pushed to master? |
| 16:02 |
JBoyer |
IF it can / should run often enough to be able to pick that out. False positives in that case (1 + n commits go in, the break is attributed to the wrong one) would be frustrating. |
| 16:02 |
phasefx |
gmcharlt: right, twice a day |
| 16:03 |
phasefx |
buildbot may be different |
| 16:03 |
phasefx |
were it working for anything other than OpenSRF |
| 16:03 |
JBoyer |
If changing that would be a significant undertaking in resources it may not be worth it. |
| 16:04 |
phasefx |
it could maybe run more often if we go with berick's smaller dataset notion |
| 16:04 |
phasefx |
right now it's designed with the notion that side effects might not be well contained and/or reversible |
| 16:04 |
phasefx |
thus, complete vm wipes to a known state between runs |
| 16:05 |
phasefx |
we could also farm out the test machines with some infrastructure improvements, let it mimic (or run off of) buildbot in that regard |
| 16:06 |
phasefx |
and get more time of day coverage that way |
| 16:06 |
gmcharlt |
well, we're past the hour, but somethign that warrants further discussion on open-ils-dev (and tuits donations) |
| 16:07 |
gmcharlt |
any other (very quick) items or annoucements? |
| 16:08 |
gmcharlt |
ok, sounds like not |
| 16:08 |
gmcharlt |
thanks, folks! |
| 16:08 |
gmcharlt |
#endmeeting |
| 16:08 |
pinesol_green |
Meeting ended Wed Feb 7 16:08:30 2018 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:08 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2018/evergreen.2018-02-07-15.01.html |
| 16:08 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2018/evergreen.2018-02-07-15.01.txt |
| 16:08 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2018/evergreen.2018-02-07-15.01.log.html |
| 16:08 |
JBoyer |
gmcharlt++ |
| 16:08 |
phasefx |
gmcharlt++ |
| 16:08 |
dbs |
gmcharlt++ |
| 16:08 |
miker |
gmcharlt++ |
| 16:09 |
kmlussier |
gmcharlt++ |
| 16:09 |
dbwells |
gmcharlt++ |
| 16:11 |
berick |
gmcharlt++ |
| 16:15 |
berick |
to round out the mobile converstation some, the goal from day one was to use tech. that would make mobile friendly possible, not that it would be mobile friendly on day one. |
| 16:16 |
berick |
to a large extent it is by default, because of the tools we use, but no real effort has been put into that as far as I know. |
| 16:17 |
berick |
kmlussier: ^-- that's largely in response to your comment about the first prototype |
| 16:20 |
kmlussier |
berick: Sure, and I think a lot of work can still be done to make it mobile friendly no matter what device you're using. |
| 16:22 |
kmlussier |
But if we rely more and more on technologies that aren't supported by Safari, it brings it into another realm where it's not possible on iOS devices. And if you want to support mobile, iOS has to part of the equation because it's so ubiquitous. |
| 16:23 |
phasefx |
app development has superceded mobile web development, IMO, and that's where the resources (say, Apple's) tends to go. I expect for their browser to always languish, really |
| 16:24 |
phasefx |
they're a walled garden, and they like it that way. powerful browsers can take away their control |
| 16:26 |
phasefx |
Microsoft didn't catch on in time; Apple's paying attention I think |
| 16:26 |
berick |
my sincere hope is safari will catch up. it's not /that/ far behind. |
| 16:26 |
* phasefx |
is just still bitter that his Quicktime Pro got demoted into Quicktime after a MacOS upgrade |
| 16:27 |
* kmlussier |
is still bitter about the time her high school replaced all the TRS-80s with Macs and then stopped offering programming classes. |
| 16:27 |
Dyrcona |
:) |
| 16:28 |
kmlussier |
I know how to hold a grudge. |
| 16:28 |
* Dyrcona |
is bitter than since the fifth generation and the advent of ACPI, the INTEL platform is crap. |
| 16:29 |
Dyrcona |
Oops. Did I think that out loud? |
| 16:32 |
* Dyrcona |
has too many git branches..... |
| 16:35 |
|
beanjammin joined #evergreen |
| 16:52 |
|
khuckins joined #evergreen |
| 16:53 |
gmcharlt |
dbwells: berick: Bmagic: https://bugs.launchpad.net/evergreen/+bug/1676608 now has updates and is ready for (hopefully final) review and merger |
| 16:53 |
pinesol_green |
Launchpad bug 1676608 in Evergreen "Copy Alert Persistence and Suppression Matrix" [Wishlist,New] |
| 16:53 |
gmcharlt |
@later tell kmlussier https://bugs.launchpad.net/evergreen/+bug/1676608 now has updates and is ready for (hopefully final) review and merger |
| 16:53 |
pinesol_green |
gmcharlt: The operation succeeded. |
| 16:53 |
Bmagic |
gmcharlt++ |
| 16:53 |
Bmagic |
Will load it as soon as I can |
| 17:00 |
|
mmorgan left #evergreen |
| 17:05 |
beanjammin |
I'm working through the instructions here Open-ILS/web/js/ui/default/staff/README.install for getting node, grunt, and bower setup and am stuck at the `bower install` step. The error returned is "ENOENT No bower.json present". Any ideas on what to try? There is no bower.json file in Open-ILS/web/js/ui/default/staff though the README.install specifically says to run `bower install` in that directory. |
| 17:06 |
berick |
beanjammin: those docs are outdated. (removed in a pending branch). |
| 17:06 |
berick |
the main install docs are what you want |
| 17:06 |
beanjammin |
Ah...... Thanks! |
| 17:06 |
beanjammin |
Where are the main docs? |
| 17:07 |
berick |
https://evergreen-ils.org/documentation/install/README_3_0.html |
| 17:07 |
berick |
or more generally linked from the downloads page |
| 17:08 |
beanjammin |
berick: Thanks |
| 17:09 |
berick |
and as noted in the doc, if installing from a release build/tarball, the browser client dependencies are pre-built. |
| 17:13 |
|
sandbergja joined #evergreen |
| 17:26 |
|
_sandbergja joined #evergreen |
| 17:37 |
beanjammin |
I'm doing some minor CSS changes for the staff client, is there a best place for those to go? |
| 17:38 |
|
khuckins_ joined #evergreen |
| 17:59 |
|
kmlussier joined #evergreen |
| 18:22 |
|
yboston joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:59 |
|
sandbergja joined #evergreen |
| 19:28 |
|
sandbergja joined #evergreen |
