Evergreen ILS Website

IRC log for #evergreen, 2023-01-10

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

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

Time Nick Message
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/g​monti/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/Eve​rgreen.git;a=shortlog;h=refs/heads/user/gmon​ti/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/do​ku.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.p​hp?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/downl​oads/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=Se​arch&field.status%3Alist=NEW&field.status​%3Alist=CONFIRMED&field.status%3Alist=TRIAGED​&field.status%3Alist=INPROGRESS&field.sta​tus%3Alist=FIXCOMMITTED&field.status%3Alist=I​NCOMPLETE_WITH_RESPONSE&field.status%3Alist=I​NCOMPLETE_WITHOUT_RESPONSE&assignee_option=an​y&field.assignee=&field.bug_reporter=&amp​;field.bug_commenter=&field.subscribe
15:45 JBoyer r=&field.structural_subscriber=&field.tag=cat​-holdingseditor&field.tags_combinator=ANY&fie​ld.has_cve.used=&field.omit_dupes.used=&field​.omit_dupes=on&field.affects_me.used=&field.h​as_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_b​lueprints.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/evergr​een/2023/evergreen.2023-01-10-15.02.html
16:01 pinesol Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2023/evergreen.2023-01-10-15.02.txt
16:01 pinesol Log:            http://evergreen-ils.org/meetings/evergree​n/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.cal​l_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

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