| Time |
Nick |
Message |
| 07:13 |
|
kworstell-isl joined #evergreen |
| 07:38 |
|
collum joined #evergreen |
| 07:48 |
|
BDorsey joined #evergreen |
| 08:01 |
|
rfrasur joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:55 |
|
BDorsey joined #evergreen |
| 08:57 |
|
dguarrac joined #evergreen |
| 09:36 |
|
kworstell-isl joined #evergreen |
| 09:42 |
|
mantis1 joined #evergreen |
| 09:45 |
|
jvwoolf joined #evergreen |
| 10:02 |
|
Dyrcona joined #evergreen |
| 12:39 |
|
jihpringle joined #evergreen |
| 13:56 |
|
dmoore joined #evergreen |
| 14:01 |
mantis1 |
HI all. Pushed a working branch to the EG repo but can't find it/can't check the branch out in my test box |
| 14:01 |
mantis1 |
command was git push working lp1853630_carousel_shelving_location_desc:user/gmonti/lp1853630_carousel_shelving_location_desc |
| 14:02 |
mmorgan |
mantis1: it |
| 14:02 |
mmorgan |
's in the working repo: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmonti/lp1853630_carousel_shelving_location_desc |
| 14:02 |
mantis1 |
ah thank you |
| 14:02 |
mmorgan |
did you do a git fetch working? |
| 14:02 |
mantis1 |
I did sorry I was looking in the wrong repo |
| 14:02 |
mantis1 |
Thank you! |
| 14:03 |
mantis1 |
Do we add a sign off tag to the LP ticket? |
| 14:04 |
mantis1 |
or is that just after testing? |
| 14:05 |
Dyrcona |
mantis1: If you signoff the branch, all you have to do on the ticket is say that you pushed a signoff branch and where the branch is. |
| 14:05 |
Dyrcona |
It's probably best to wait until after you've tested it. I don't add my signoff if I can't get it to work. |
| 14:05 |
mmorgan |
mantis1: It needs a pullrequest tag, the signoff tag gets added by the tester |
| 14:05 |
Dyrcona |
Oh, yeah. You can add the signoff tag if you tested it. |
| 14:06 |
Dyrcona |
I may have misunderstood the situation. |
| 14:06 |
Dyrcona |
The original author doesn't add the signoff tag for their signoff. |
| 14:06 |
mantis1 |
mmorgan++ Dyrcona++ |
| 14:09 |
* Dyrcona |
should start working on the git presentation. |
| 14:16 |
Dyrcona |
mantis1++ |
| 14:17 |
Dyrcona |
We don't usually update po files like that. It's done as part of building a release, but it's a nice touch and shouldn't hurt. |
| 14:19 |
|
wszwagiel joined #evergreen |
| 14:20 |
|
wszwagiel72 joined #evergreen |
| 14:30 |
JBoyer |
Dev meeting in 30 |
| 14:39 |
mantis1 |
Dyrcona++ I'll keep in mind for next time |
| 14:45 |
|
Stompro joined #evergreen |
| 14:47 |
|
sleary joined #evergreen |
| 14:54 |
|
Guest19 joined #evergreen |
| 14:54 |
|
mdriscoll joined #evergreen |
| 14:55 |
|
terranm joined #evergreen |
| 14:56 |
|
shulabear joined #evergreen |
| 14:59 |
|
GavinKCLS joined #evergreen |
| 14:59 |
dmoore |
howdy all! happy chewsday |
| 14:59 |
|
lmworster joined #evergreen |
| 14:59 |
|
smorrison joined #evergreen |
| 15:00 |
* rfrasur |
likes a chewsday |
| 15:01 |
gmcharlt |
Evergreen puppies do as well |
| 15:01 |
berick |
zing |
| 15:01 |
rfrasur |
puppies++ |
| 15:01 |
|
sandbergja joined #evergreen |
| 15:02 |
|
tlittle joined #evergreen |
| 15:02 |
JBoyer |
OHAI. |
| 15:02 |
JBoyer |
#startmeeting 2023-01-10 - Developer Meeting |
| 15:02 |
pinesol |
Meeting started Tue Jan 10 15:02:43 2023 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:02 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:02 |
pinesol |
The meeting name has been set to '2023_01_10___developer_meeting' |
| 15:02 |
JBoyer |
#info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2023-01-10 |
| 15:02 |
JBoyer |
#topic Introductions |
| 15:03 |
JBoyer |
#info JBoyer = Jason Boyer, EOLI |
| 15:03 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CWMARS |
| 15:03 |
terranm |
#info terranm = Terran McCanna, PINES |
| 15:03 |
jeffdavis |
#info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka) |
| 15:03 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 15:03 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:03 |
collum |
#info collum = Garry Collum, KCPL |
| 15:03 |
jvwoolf |
#info jvwoolf= Jessica Woolford, Bibliomation |
| 15:03 |
miker |
#info miker = Mike Rylander, EOLI |
| 15:03 |
csharp_ |
#info csharp = Chris Sharp, GPLS |
| 15:03 |
shulabear |
#info shulabear = Shula Link, GCHRL in PINES |
| 15:03 |
berick |
#info berick Bill Erickson, KCLS |
| 15:03 |
rfrasur |
#info rfrasur = Ruth Frasur, Evergreen Indiana |
| 15:03 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Equinox |
| 15:03 |
sandbergja |
#info sandbergja = Jane Sandberg |
| 15:04 |
dmoore |
#info dmoore = Dan Moore, KCLS |
| 15:04 |
GavinKCLS |
#info GavinKCLS = Gavin Smith, KCLS |
| 15:04 |
sleary |
#info sleary = Stephanie Leary, EOLI |
| 15:05 |
gmcharlt |
#info gmcharlt = Galen Charlton, EOLI |
| 15:05 |
jeffdavis |
big turnout! hi everyone |
| 15:05 |
JBoyer |
Ok, anyone joining later feel free to #info up then. |
| 15:05 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:05 |
JBoyer |
#info jeffdavis will gather more specific examples of recurring QA problems to present for discussion at the next dev meeting |
| 15:05 |
JBoyer |
#link https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:common_qa_problems |
| 15:06 |
JBoyer |
And now the customary X minutes while we all go read that list, definitely not for the first time... |
| 15:06 |
JBoyer |
(more seriously, please go ahead jeffdavis if you'd like to add any color) |
| 15:06 |
sandbergja |
jihpringle++ |
| 15:06 |
jeffdavis |
the important parts are in bold :) |
| 15:06 |
sandbergja |
jeffdavis++ |
| 15:06 |
berick |
jeffdavis++ |
| 15:07 |
JBoyer |
jeffdavis++ jhpringle++ |
| 15:07 |
jeffdavis |
jihpringle and others here pulled together that very extensive list of common types of QA problems |
| 15:07 |
mmorgan |
jeffdavis++ jhpringle++ |
| 15:07 |
JBoyer |
jihpringle++ |
| 15:07 |
berick |
jihpringle++ |
| 15:07 |
shulabear |
jdavis++ jhpringle++ |
| 15:07 |
sandbergja |
jihpringle++ # oops typo |
| 15:07 |
rfrasur |
jeffdavis++ jihpringle++ |
| 15:07 |
shulabear |
jeffdavis++ jihpringle++ |
| 15:07 |
jeffdavis |
The hope is to use this as the basis for a developers/committers checklist to do a better job of catching these types of issues before code gets committed. |
| 15:08 |
Dyrcona |
jihpringle++ jeffdavis++ |
| 15:08 |
terranm |
jihpringle++ jeffdavis++ |
| 15:08 |
Dyrcona |
Some of those will slow things down. |
| 15:08 |
jeffdavis |
Testers could also use it during bug squashing weeks, people doing acceptance testing on paid development project, etc. |
| 15:09 |
sandbergja |
3 and 7 also seem difficult. We don't really have comprehensive information about how all our functionality/settings are supposed to work. |
| 15:09 |
sandbergja |
be it 100% test coverage or a super-detailed manual |
| 15:10 |
JBoyer |
I do like the idea of basing an interface comparison checklist on it. You don't necessarily need to know how to use all of an interface if you can tell that you can get to X on dojo but not Angular. (so long as it's not an intentional workflow change) |
| 15:10 |
sandbergja |
so I'd be interested in some conversation about how developers can get all that info before embarking on an angularization |
| 15:13 |
Dyrcona |
I wonder if the Angular version needs to have feature parity with the previous interfaces(s). What if we came up with better ways of doing things? |
| 15:13 |
jeff |
probably fall under JBoyer's "so long as it's not an intentional workflow change" |
| 15:14 |
rfrasur |
Who is "we?" |
| 15:14 |
mmorgan |
re: library settings - it seems like calls to get library settings in existing code shouldn't be too hard to identify. |
| 15:14 |
JBoyer |
That's what I was getting at yeah. If you can get the same outcome with a different UI that's fine, but being able to do something in the old and busted but not the new hotness isn't great. |
| 15:15 |
tlittle |
#info tlittle = Tiffany Little, PINES |
| 15:17 |
jeffdavis |
IMO the state of our tests/docs means that we'll never catch all of these problems. I think the idea with a checklist was to make sure we're consciously thinking about these types of things at some point during the contribution process. |
| 15:17 |
berick |
yeah, what jeffdavis said |
| 15:17 |
Dyrcona |
This is going to be unpopular, but maybe we need stricter standards than "works for me" and X number of signoffs. |
| 15:18 |
sandbergja |
Dyrcona: what did you have in mind? |
| 15:18 |
jeffdavis |
I also think that if multiple different roles are checking for this - code writers, committers, testers, etc - we're more likely to catch things than if we just put it all on the commit author. |
| 15:18 |
JBoyer |
And it seems like there isn't going to be a large amount of discussion at the moment, but I think either way something like this should be shared on the dev and newdev lists to either get more discussion going or expose it to more people. |
| 15:18 |
berick |
imo this is what we're already trying to do, it's nothing new |
| 15:18 |
JBoyer |
(and of course now things pick up. :) Please don't let me stop you!) |
| 15:18 |
berick |
it's just difficult sometimes |
| 15:19 |
berick |
so more emphasis is good |
| 15:19 |
berick |
and having a record of usual gotchas helps focus |
| 15:20 |
abneiman |
this is also where non-technical end users can be helpful - in terms of interface & workflow evalution |
| 15:20 |
Dyrcona |
sandbergja: I'm not really looking for more process, but I do think we need better automated tests, etc. I don't have much specific in mind at the moment. |
| 15:20 |
mmorgan |
abneiman++ |
| 15:21 |
Dyrcona |
Also, what abneiman said. We need more end users involved. |
| 15:21 |
tlittle |
abneiman++ |
| 15:22 |
mmorgan |
It's difficult for end users to get more involved, difficult for them to get their hands on the new development to test on. |
| 15:22 |
JBoyer |
Yeah, testers rarely need to be conversant in the technical bits, and sometimes the tech types don't know so much about how the end users do their thing. |
| 15:23 |
mmorgan |
Bugsquashing week is huge, but test systems are not real world. |
| 15:23 |
gmcharlt |
yeah - I think an additional factor is committer time, and more automation can help around the edges |
| 15:23 |
tlittle |
Numbers 6-7 are concrete things that fall squarely on the dev's shoulders, though, imo |
| 15:24 |
mmorgan |
tlittle++ |
| 15:25 |
JBoyer |
But to mmorgan's point, it's difficult to test on realistic data if you don't have the local staff to build and rebuild test systems. :-/ |
| 15:25 |
Dyrcona |
Well, hire someone. What we need is more resources. It's that simple. |
| 15:26 |
terranm |
Yeah, we find a lot of issues when we do our intensive pre-upgrade testing with a copy of real data. And then more issues when we go live. |
| 15:27 |
mmorgan |
Dyrcona: Agreed more resources, but imo it doesn't seem that simple to hire someone and bring them up the Evergreen learning curve. |
| 15:29 |
berick |
it may be helpful to consider that this phase of EG dev won't last forever. |
| 15:29 |
berick |
there's only so many non-Angular UI's |
| 15:29 |
dmoore |
berick++ |
| 15:29 |
Dyrcona |
And, when Google ends Angular? |
| 15:29 |
tlittle |
berick++ |
| 15:30 |
abneiman |
is there a role for TEP Board to fund more aggressive QA? also, berick's point is well-taken. |
| 15:30 |
* jeffdavis |
cracks knuckles, starts re-implementing all the Perl stuff in Haskell |
| 15:30 |
rfrasur |
abneiman++ |
| 15:30 |
Dyrcona |
I'm not trying to start a fight or be contrary for the sake of being contrary. Google have demonstrated that they can't be trusted. |
| 15:30 |
* Dyrcona |
would prefer Haskell at this point. |
| 15:30 |
dmoore |
what's the TEP Board? |
| 15:31 |
csharp_ |
dmoore: The Evergreen Project |
| 15:31 |
rfrasur |
The Evergreen Project oversight board |
| 15:31 |
dmoore |
oh duh, thanks |
| 15:31 |
sleary |
Even just focusing on the Angular UIs is a steep learning curve. I have had trouble with the lack of inline documentation on what various components do. (This topic is on the next new dev agenda, btw.) |
| 15:31 |
csharp_ |
dmoore: feel free to ask if there are other acronyms/jargon you don't understand |
| 15:32 |
sandbergja |
Dyrcona: for me, I think that goes back to better automated tests and docs -- hopefully when/if we migrate away from Angular, we'd have better safeguards against regressions |
| 15:32 |
mmorgan |
All part of the learning curve :) |
| 15:32 |
csharp_ |
part of the answer is new devs - both in general and the new devs group |
| 15:32 |
sandbergja |
also, here's hoping Angular stays healthy for quite some time yet. :-) |
| 15:32 |
csharp_ |
but we've had this conversation so many times over the years it's hard for me to get excited (or upset) about it :-/ |
| 15:33 |
mmorgan |
At least until all the interfaces get migrated? :) |
| 15:33 |
sandbergja |
:-D it was starting to sound kind of familiar hahaha |
| 15:33 |
abneiman |
what's kmlussier's old joke? "Have you finished Evergreen yet?" |
| 15:33 |
rfrasur |
hah |
| 15:34 |
mmorgan |
kmlussier++ |
| 15:34 |
gmcharlt |
oh, yeah, I did yesterday - should have told you all |
| 15:34 |
* gmcharlt |
runs |
| 15:34 |
csharp_ |
all of the above considered, the QA gotchas will be useful |
| 15:34 |
terranm |
kmlussier++ |
| 15:34 |
csharp_ |
jihpringle++ jeffdavis++ |
| 15:34 |
abneiman |
yes, jihpringle++ jeffdavis++ I have already bookmarked this |
| 15:34 |
terranm |
Same here |
| 15:34 |
sleary |
Very useful! And I would like to do more with automated testing as well. |
| 15:34 |
mmorgan |
Agreed QA gotchas will be useful, there will always be change, we just need to manage it well |
| 15:35 |
mmorgan |
*just* |
| 15:35 |
jvwoolf |
jihpringle++ jeffdavis++ |
| 15:35 |
JBoyer |
So, I do think it should go to the dev lists (perhaps quarterly or so, even) so that we can move on to the second action item from the last meeting. :) |
| 15:35 |
Dyrcona |
This list is a good outline of where we need to pay attention, and tests/standard can be built around it. |
| 15:35 |
JBoyer |
Which is |
| 15:35 |
JBoyer |
#info Bmagic to email the development list about a way to share common Evergreen tools with the community. |
| 15:36 |
JBoyer |
Though I don't think Bmagic is available at the moment and I don't recall seeing this on the lists. We'll kick that can down the road. |
| 15:36 |
JBoyer |
#action Bmagic to email the development list about a way to share common Evergreen tools with the community. |
| 15:36 |
JBoyer |
#info Dyrcona to review Lp 1901932 |
| 15:36 |
pinesol |
Launchpad bug 1901932 in Evergreen "Wish List - Enhanced Concerto dataset" [Wishlist,New] https://launchpad.net/bugs/1901932 |
| 15:37 |
JBoyer |
How is that looking Dyrcona ? |
| 15:37 |
Dyrcona |
Yeah, I didn't really look at it. |
| 15:37 |
berick |
oh nice, I missed that there was a pullreq for that |
| 15:37 |
JBoyer |
Not the ideal time of year, do you want to check it out for next time? |
| 15:38 |
Dyrcona |
I don't know. Things keep coming up. |
| 15:38 |
Dyrcona |
I guess go ahead and give it to me for next time and we'll see what happens. |
| 15:38 |
JBoyer |
Can do. |
| 15:38 |
JBoyer |
#action Dyrcona to review Lp 1901932 |
| 15:38 |
pinesol |
Launchpad bug 1901932 in Evergreen "Wish List - Enhanced Concerto dataset" [Wishlist,New] https://launchpad.net/bugs/1901932 |
| 15:39 |
JBoyer |
Note though, if anyone else has an interest in the expanded sample data set and opinions on integration and etc. feel free to poke around, |
| 15:40 |
JBoyer |
Ugh, look at me, forgetting to add something to the agenda myself, heh. |
| 15:40 |
JBoyer |
#topic Evergreen Release Updates |
| 15:40 |
JBoyer |
#info I've built a 3.8.2 release to end the 3.8 line now that 3.10 is out, if you can help test it's at https://evergreen-ils.org/downloads/Evergreen-ILS-3.8.2.tar.gz (Note, I'm going to have to make a docs change before it's final-final, but no code changes.) |
| 15:41 |
gmcharlt |
JBoyer++ |
| 15:41 |
shulabear |
Jboyer++ |
| 15:41 |
sandbergja |
JBoyer++ |
| 15:41 |
mmorgan |
JBoyer++ |
| 15:41 |
Dyrcona |
JBoyer++ |
| 15:41 |
JBoyer |
It is 1. wicked late, and 2. not too difficult to test. IF you have access to a 3.8.1 db especially and can help test it (I know the version upgrade is fine for concerto, but you know how that goes) |
| 15:41 |
terranm |
JBoyer++ |
| 15:41 |
tlittle |
JBoyer++ |
| 15:42 |
rfrasur |
JBoyer++ |
| 15:42 |
jvwoolf |
JBoyer++ |
| 15:42 |
JBoyer |
And while the md5 file is available beside it, take note: I'm going to modify the release notes before the final tarball is available. That's the final code though (unless it blows up on somebody) |
| 15:44 |
JBoyer |
Let me know directly or via the lists if everything looks good and I'll get a final release up and also finally retire 3.7. |
| 15:44 |
JBoyer |
And now for a big plate of copypasta |
| 15:44 |
berick |
JBoyer++ |
| 15:44 |
JBoyer |
#topic Launchpad Status |
| 15:44 |
JBoyer |
#info Snapshot |
| 15:44 |
JBoyer |
#info Open Bugs - 2881 |
| 15:44 |
JBoyer |
#info Pullrequests - 106 |
| 15:44 |
JBoyer |
#info Signedoff - 41 |
| 15:44 |
JBoyer |
#info Updates Since Last Meeting |
| 15:44 |
JBoyer |
v |
| 15:44 |
JBoyer |
#info Bugs Added - 41 |
| 15:44 |
JBoyer |
#info Pullrequest tag Added - 29 |
| 15:44 |
JBoyer |
#info Signedoff tag Added - 7 |
| 15:44 |
JBoyer |
#info Fix Committed - 11 |
| 15:45 |
JBoyer |
ok, |
| 15:45 |
JBoyer |
#topic New Business |
| 15:45 |
JBoyer |
#info Bugs tagged with cat-holdingseditor (mmorgan) |
| 15:45 |
JBoyer |
Let's see how this works |
| 15:45 |
JBoyer |
#link https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscribe |
| 15:45 |
JBoyer |
r=&field.structural_subscriber=&field.tag=cat-holdingseditor&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on |
| 15:45 |
JBoyer |
Ah, probably busted. Well, the proper link is in the agenda if you'd like to follow along. :) |
| 15:46 |
JBoyer |
mmorgan, anything to add? |
| 15:46 |
mmorgan |
I just wanted to call attention to bugs related to the Angular holdings editor. |
| 15:47 |
mmorgan |
We opted to delay upgrading because of these bugs. Hoping to get more eyes to get many of them resolved. |
| 15:47 |
mmorgan |
Also, This kind of dovetails with the QA discussion. A lot of these bugs fall into that category. |
| 15:47 |
mmorgan |
jvwoolf has been concentrating on them as well |
| 15:47 |
mmorgan |
jvwoolf++ |
| 15:48 |
JBoyer |
mmorgan++ jvwoolf++ |
| 15:48 |
jeffdavis |
Are these bugs mostly without branches/possible fixes so far? |
| 15:48 |
mmorgan |
jeffdavis: Yes, mostly without branches. A few have pullrequests |
| 15:49 |
jvwoolf |
mmorgan: I've push patches to all of the ones that were showstoppers for us so far |
| 15:49 |
terranm |
We're going ahead with upgrading because they're not show stoppers for us, but we know there will be some grumblings |
| 15:49 |
jvwoolf |
I'm likely done with my concentrated effort unless something comes up when we widen our testing to end users, or after we upgrade |
| 15:50 |
mmorgan |
Template issues, silent failure issues are big ones for us. |
| 15:51 |
mmorgan |
We're still sorting through and prioritizing |
| 15:51 |
|
smorrison joined #evergreen |
| 15:53 |
jvwoolf |
mmorgan: Since I've been poking around in that code a lot, let me know if you come across anything high priority you can use eyes on |
| 15:53 |
jvwoolf |
Or we can talk about it at a new dev meeting |
| 15:53 |
JBoyer |
I also think sending a note to the dev lists could be a good way to make sure the most people see that list. |
| 15:53 |
JBoyer |
And finally, I think I might know a couple people interested in helping with: |
| 15:53 |
JBoyer |
#info Thoughts on sharing work on 2000482 (berick) |
| 15:54 |
JBoyer |
#link https://bugs.launchpad.net/evergreen/+bug/2000482 |
| 15:54 |
pinesol |
Launchpad bug 2000482 in Evergreen "Angular 15 + Bootstrap 5 Upgrade" [Medium,In progress] - Assigned to Bill Erickson (berick) |
| 15:54 |
berick |
good news is angular 12 -> 15 is pretty smooth |
| 15:54 |
berick |
and number of npm package warnings dropped dramatically |
| 15:54 |
JBoyer |
Is 15 an LTS? I thought they were an even / odd release project? |
| 15:54 |
sandbergja |
berick++ |
| 15:55 |
shulabear |
berick++ |
| 15:55 |
berick |
bootstrap 5 is also not *too* bad, but will require some effort and a lot of poking around to find stuff that might need fixing |
| 15:55 |
sleary |
I can help with the Bootstrap 5 classes |
| 15:55 |
JBoyer |
Pfft, that's node. Never mind! |
| 15:55 |
berick |
i'm going to put together a short list of stuff that I know needs address and will send to dev list |
| 15:56 |
berick |
some classes just went away since they were essentially redundant |
| 15:56 |
berick |
e.g. form-group can be grouped with rows and cols, etc. |
| 15:56 |
sleary |
Bootstrap 5.2 handles text and background colors very differently; are we just going to 5.0 for now? |
| 15:57 |
collum |
Moving opac to bootstrap 5, as well? |
| 15:57 |
berick |
sleary: i think it's 5.0 that we can use at the moment. i can double check that, though |
| 15:57 |
berick |
collum: i'm focusing on the staff client |
| 15:58 |
berick |
boopac maintains its own deps, right? |
| 15:58 |
berick |
upgrading one does not require we update the other? |
| 15:59 |
JBoyer |
Yeah, they're separate. (the BPAC pulls in 3-5 node modules and that |
| 15:59 |
JBoyer |
s about it) |
| 15:59 |
* berick |
nods |
| 16:00 |
berick |
more on this soon, though, and then i'll probably request some additional hands |
| 16:00 |
berick |
thanks sleary, just saw your comment about helping |
| 16:00 |
berick |
that's it unless there are questions for me |
| 16:00 |
sleary |
berick++ |
| 16:00 |
JBoyer |
berick++ sleary++ |
| 16:01 |
csharp_ |
berick++ sleary++ |
| 16:01 |
shulabear |
berick++ sleary++ |
| 16:01 |
JBoyer |
#topic Announcements |
| 16:01 |
JBoyer |
#info Next Meeting is February 14th, 2023 |
| 16:01 |
JBoyer |
#endmeeting |
| 16:01 |
pinesol |
Meeting ended Tue Jan 10 16:01:54 2023 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:01 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2023/evergreen.2023-01-10-15.02.html |
| 16:01 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2023/evergreen.2023-01-10-15.02.txt |
| 16:01 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2023/evergreen.2023-01-10-15.02.log.html |
| 16:02 |
JBoyer |
Thanks everybody |
| 16:02 |
jvwoolf |
How romantic! |
| 16:02 |
rfrasur |
JBoyer++ |
| 16:02 |
collum |
JBoyer++ |
| 16:02 |
jvwoolf |
JBoyer++ |
| 16:02 |
mmorgan |
JBoyer++ |
| 16:02 |
shulabear |
JBoyer++ |
| 16:02 |
miker |
JBoyer++ |
| 16:02 |
sleary |
JBoyer++ |
| 16:02 |
berick |
JBoyer++ |
| 16:03 |
sandbergja |
JBoyer++ |
| 16:03 |
abneiman |
JBoyer++ |
| 16:03 |
terranm |
Before too many people run away, I was thinking about scheduling the next Bug Squashing Week in February - either 13-17 or 27-3 - any thoughts? |
| 16:03 |
Dyrcona |
JBoyer++ |
| 16:03 |
shulabear |
terranm: seems like a good idea. |
| 16:03 |
JBoyer |
terranm, 27 - 3 is better for me. |
| 16:04 |
abneiman |
terranm: personal preference for me is the latter |
| 16:04 |
sleary |
same |
| 16:04 |
abneiman |
terranm++ |
| 16:04 |
terranm |
Cool beans, thx |
| 16:04 |
shulabear |
terranm++ |
| 16:04 |
mmorgan |
terranm++ |
| 16:04 |
collum |
terranm++ |
| 16:05 |
sandbergja |
terranm++ |
| 16:08 |
terranm |
Has anybody here tried fleshing info in the biblio.record_entry.email.full action trigger? I'm trying to figure out how to add the system name and I'm confused. |
| 16:09 |
Dyrcona |
terranm: You need to flesh parent_ou on aou. Give me a minute and I can give the necessary line. |
| 16:10 |
|
lmworster left #evergreen |
| 16:10 |
terranm |
Dyrcona++ This one is built so differently from the other action triggers I've worked with |
| 16:14 |
|
jvwoolf left #evergreen |
| 16:17 |
dmoore |
At anyone's convenience, could I get a wiki account? Dtmoore kcls.org is my email |
| 16:19 |
Dyrcona |
terranm: You can add owner.parent_ou to the environment for your event id. That should flesh the parent of the owner org unit, and you can reference owner.parent_ou.name in the template. |
| 16:21 |
terranm |
Oooh, I was trying to get there from items |
| 16:23 |
Dyrcona |
Well, you have to flesh item.call_number, then call_number.owning_lib.parent_ou. You might need another alternate step in there. If your consortium shares bibs, then owner is like to have a null parent_ou. |
| 16:23 |
terranm |
That's giving me "Error previewing record: No record data returned from server " - isn't owner in this context the owner of the bucket and not the owner of the item? |
| 16:24 |
Dyrcona |
Y'know what. You're right. I was looking at biblio.record_entry. |
| 16:26 |
Dyrcona |
You can try 'owning_lib' and then 'owning_lib.parent_ou' |
| 16:26 |
Dyrcona |
Of course, owning_lib can be null..... |
| 16:28 |
terranm |
Since it is using cp.circ_lib already I was trying to build on that but it looks like that is being fleshed out in the "flesh_list" section at the top instead of in the Environment |
| 16:31 |
Dyrcona |
Yeah, that one is unusual. I didn't look that closely at the template. I'm going to see what sort_bucket_unapi_bre does. |
| 16:32 |
terranm |
Yeah, I've added system to a lot of our other action triggers the normal way, but this one is confusing |
| 16:35 |
Dyrcona |
You want the parent of cp.circ_lib? It looks like cp.circ_lib is just the name. Is that correct? |
| 16:35 |
terranm |
Oh, I was thinking it was the ID, but I guess it is the name |
| 16:36 |
Dyrcona |
Yeah. It's just the name according to line 485 of Reactor.pm. |
| 16:37 |
terranm |
Hrrm. |
| 16:37 |
Dyrcona |
The easiest way looks like it would require modifying Reactor.pm. |
| 16:38 |
terranm |
Ugh, which totally defeats the point of an action trigger. |
| 16:39 |
Dyrcona |
You could try going items.target_biblio_record_entry.call_numbers.copies.circ_lib.parent_ou, but then you'd need to match them up with the main entries somehow. |
| 16:39 |
terranm |
Rather, of the action trigger interface |
| 16:39 |
terranm |
Okay, well, you've helped me get a lot further than I was. I'll take this up again in the morning! |
| 16:39 |
terranm |
Thanks for your time! |
| 16:39 |
Dyrcona |
terannm++ |
| 16:40 |
Dyrcona |
You're more than welcome. I learned something that I didn't know. |
| 16:40 |
terranm |
Always happy to help ;) |
| 16:40 |
Dyrcona |
:) |
| 16:41 |
Dyrcona |
If you're happy with info for the call numbers owner, you could also stop there with call_numbers.owning_lib.parent_ou and skip the copies. |
| 16:42 |
terranm |
Oh, true! |
| 16:42 |
Dyrcona |
I'm not sure how well that will really work with this particular trigger. I'm also not really sure how the flesh_list is being used. I'd have to study that some more. |
| 16:46 |
Dyrcona |
OK. It is being used to flesh data for the unapi call, but adding to it would still likely require changes to Reactor.pm, or even changes to unapi possibly.... |
| 16:47 |
Dyrcona |
There's a lot going on there. |
| 16:47 |
terranm |
Yes. At which point I wonder if we really need the library system name... |
| 16:48 |
Dyrcona |
:) |
| 17:11 |
|
mmorgan left #evergreen |
