| Time |
Nick |
Message |
| 00:07 |
|
dbwells_ joined #evergreen |
| 00:07 |
|
lsach1 joined #evergreen |
| 02:30 |
|
gsams joined #evergreen |
| 06:49 |
|
agoben joined #evergreen |
| 07:51 |
|
Dyrcona joined #evergreen |
| 08:15 |
|
JBoyer joined #evergreen |
| 08:31 |
pinesol |
[evergreen|Jason Boyer] LP1796988: Fix Saving Last Copy Template - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f709f27> |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:34 |
Dyrcona |
JBoyer++ # timing |
| 08:35 |
JBoyer |
Dyrcona++ # testing |
| 08:35 |
Dyrcona |
Well, Janet Schrader did the actual testing, I just installed it. |
| 08:36 |
JBoyer |
So long as it gets in, ++'s all around. |
| 08:36 |
Dyrcona |
:) |
| 08:37 |
Dyrcona |
We're backporting it to production, 3.0.13. |
| 08:37 |
JBoyer |
And I can confirm it works on 3.1 because we've been running it on production since the day I posted it. |
| 08:38 |
Dyrcona |
Cool. I figured it would since it is such a small change and it works in 3.0 and 3.2. |
| 08:43 |
|
bos20k joined #evergreen |
| 08:56 |
|
kmlussier joined #evergreen |
| 09:19 |
|
jvwoolf joined #evergreen |
| 09:35 |
|
yboston joined #evergreen |
| 09:57 |
berick |
oops, accidentally deleted the hackaway event from the EG dev calendar. |
| 09:57 |
berick |
guess we have to cancel |
| 09:57 |
* berick |
undid the delete |
| 10:01 |
|
mmorgan1 joined #evergreen |
| 10:16 |
Dyrcona |
heh |
| 10:23 |
Dyrcona |
I know this has been mentioned, but this is a pain when doing development: modified: Open-ILS/src/eg2/package-lock.json |
| 10:29 |
Dyrcona |
ERROR in ../ngx-cookie/ngx-cookie.ts(10,23): Error during template compile of 'CookieBackendService' |
| 10:29 |
Dyrcona |
Could not resolve @nguniversal/express-engine/tokens relative to /home/opensrf/Evergreen/Open-ILS/src/eg2/node_modules/ngx-cookie/ngx-cookie.d.ts.. |
| 10:32 |
Dyrcona |
Nothing from DuckDuckGo. |
| 10:33 |
Dyrcona |
rm -rf node_modules/* ; npm install ; ng build --prod # Did NOT help. I assume it's another Node problem that will fix itself, eventually.... |
| 10:33 |
Dyrcona |
node.js-- |
| 10:41 |
Dyrcona |
Sadly, I think I'm starting to actually get this. Looks like ngx-cookie has a new dependency on @nguniversal/express-engine. npm install @nguniversal/express-engine resolves my issue. |
| 10:41 |
Dyrcona |
Will bug and branch it later. |
| 10:53 |
berick |
ironically enough, this is the kind of thing package-lock.json is supposed to help us avoid. |
| 10:58 |
|
jvwoolf joined #evergreen |
| 11:05 |
Dyrcona |
:) |
| 11:25 |
|
sandbergja joined #evergreen |
| 11:27 |
|
mmorgan joined #evergreen |
| 12:03 |
|
bos20k joined #evergreen |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:26 |
Bmagic |
Anyone know about editing more than one (the new style) copy alerts in the web client? It seems creating a new copy alert for all of the copies that are checked does not stick for any of the copies except the last one. Did I miss the bug report? |
| 12:31 |
JBoyer |
Bmagic, haven't tried it here yet and that issue isn't ringing an LP bell. |
| 12:33 |
Bmagic |
thanks, might need to make one about it thenm |
| 12:35 |
Bmagic |
I found another bug while messing with this one: Adding the same item from pending pending copies to bucket, can result in duplicate copies in the bucket but it only shows a single version of it in the bucket view. Funny though, the parenthetic count in the "Bucket View (2)" shows the total number |
| 12:35 |
Bmagic |
I decided to remove the copy from the bucket (that I knew had a duplicate) and after it was removed, it's duplicate took it's place. |
| 12:37 |
jihpringle |
Bmagic: that sounds like this one - https://bugs.launchpad.net/evergreen/+bug/1792632 |
| 12:37 |
pinesol |
Launchpad bug 1792632 in Evergreen "Web client: Duplicated items do not display in copy buckets" [Undecided,New] |
| 12:37 |
Bmagic |
yeah, that's it |
| 12:37 |
Bmagic |
jihpringle++ |
| 12:37 |
Bmagic |
little bit quirky |
| 12:37 |
jihpringle |
the duplicate taking the original's place once removed sounds like a new discovery |
| 12:38 |
Bmagic |
it was fun to see it get it's duplicate into the view :) |
| 12:38 |
Bmagic |
"it's there I knew it!" |
| 12:38 |
jihpringle |
:) |
| 12:41 |
Dyrcona |
So, I'm setting up SIPServer on a vm and I'm getting this: Can't locate Sip.pm in @INC (you may need to install the Sip module) |
| 12:41 |
Dyrcona |
I have another VM where SIPServer works just fine. |
| 12:41 |
Bmagic |
Dyrcona: that sounds like an acid trip |
| 12:46 |
Dyrcona |
Adding /home/opensrf/SIPServer to PERL5LIB does the trick. I don't have that set on the other VM, so I think this is another change with Perl 5.26 on Ubuntu 18. |
| 12:49 |
JBoyer |
I'm off of here for the day, I hope to see twenty-odd of you next week! |
| 13:00 |
|
plux joined #evergreen |
| 13:16 |
plux |
trying to split out 1094.reingest.multiple_language_search.sql to speed up the reingest e.g. SELECT metabib.reingest_record_attributes (1114423, '{item_lang}'::TEXT[]) |
| 13:17 |
plux |
can’t see why that shouldn’t work but it doesn’t seem to be making any change unless I’m looking in the wrong places for results |
| 13:20 |
Dyrcona |
plux: Just drop all of the ingests from the upgrades and run pingest.pl after. |
| 13:20 |
plux |
I wasn’t sure if pingest would cover that one |
| 13:21 |
plux |
I leave it off for the others….k, that would be great |
| 13:21 |
Dyrcona |
I'm pretty sure it does all record attributes and no way to specify individual ones. |
| 13:22 |
plux |
didn’t know if pingest would deal with '{item_lang}'::TEXT[]) so that’s why I thought it had to run….if not that’s great |
| 13:25 |
Dyrcona |
pingest.pl will reingest all record attributes. It calls metabib.reingest_record_attributes with just the id and prmarc arguments. |
| 13:26 |
plux |
great…I must say I’m really appreciating that script |
| 13:26 |
Dyrcona |
Are you upgrading to 3.2? |
| 13:27 |
plux |
third run at it….upgrading on a test system with an eye to going production |
| 13:27 |
plux |
mostly all well but hit some issues so redoing the db updates on a fresh db dump |
| 13:30 |
Dyrcona |
Took me a few tries to get our db upgrade just right, too. I've upgraded training. We anticipate going to 3.2 in the spring. |
| 13:32 |
plux |
overall, it looked pretty good but the few issues I did have had to fixed. I’d like to start with a fresh schema. This one is upgraded many times - |
| 13:35 |
Dyrcona |
Everyone's schema has been upgraded a few times. |
| 13:45 |
plux |
the only place I’m really noticing it is config.metabib_field and that small bug with the 1100 update. That seems to be where I’m having issues after reingest. |
| 13:46 |
plux |
I may have it this time. It will take a while for the reingest to run so we’ll see. |
| 13:50 |
Dyrcona |
plux: What's the default value for format on your config.metabib_field table? It should be mods33. |
| 13:51 |
plux |
it is now…..that was the issue first run through….then I shifted all my older entries to mods 33 and that broke some displays. Now I’m redoing with the new fields as mods33 and leaving the older entries. - set the default for new to mods 33 |
| 13:52 |
Dyrcona |
Right. That's all you want to do. You don't want to change existing entries. |
| 13:53 |
Dyrcona |
They break if the format doesn't match the xpath fields. |
| 14:00 |
|
jvwoolf left #evergreen |
| 14:17 |
* kmlussier |
should probably go through the bugs assigned to her and either unassign herself or get working on them. |
| 14:23 |
* rhamby |
vows that kmlussier will do all the things |
| 14:23 |
kmlussier |
rhamby: Yes, I'll finish Evergreen before I leave. There's really no reason for all of you to get together next week. :) |
| 14:24 |
rhamby |
kmlussier: we'll just have to drink beer, eat bbq and give you karma in irc periodically then |
| 14:25 |
Dyrcona |
:) |
| 14:28 |
|
yboston joined #evergreen |
| 14:36 |
miker |
berick: I'm working on some angular interfaces, and getting what looks like a lot of spurious updates to Open-ILS/src/eg2/package-lock.json and Open-ILS/src/eg2/package.json (and, actually, Open-ILS/web/js/ui/default/staff/package.json) from npm actions ... should I just ignore those? |
| 14:40 |
Dyrcona |
miker: Are you sure that these upates are spurious? I had fun this morning with a missing dependency on ngx-cookie. |
| 14:40 |
miker |
Dyrcona: that's where my trek started, too :) |
| 14:40 |
miker |
but there's a lot of version info that may be tied to my particular installation |
| 14:41 |
miker |
and, I noted that there was at least one variable that said, essentially, "I was expecting macos, what is this linux junk?" |
| 14:42 |
berick |
so far I've been ignoring package-lock.json |
| 14:42 |
miker |
berick: .gitignore'ing? or just committing whatever gets shoved in there? |
| 14:42 |
berick |
package.json changes usually mean a dependency change though |
| 14:43 |
berick |
miker: committing or checking out the master version before committing |
| 14:43 |
* berick |
needs to figure out the package-lock.json stuff |
| 14:44 |
berick |
i thought it would magically do stuff, but so far it's just in the way |
| 14:44 |
miker |
heh |
| 14:46 |
Dyrcona |
I've not been committing from a built Evergreen, so it only bothers me when I try to rebase on one of my test vms to pick up the latest code. |
| 14:47 |
|
hbrennan joined #evergreen |
| 14:49 |
miker |
I was having problems that were solved by adding ngx-device-detector, so I think that's the only actual addition to package.json. the rest was just version stuff |
| 15:04 |
pinesol |
[evergreen|Remington Steed] Docs: Update old command osrf_ctl.sh to osrf_control - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9bb271b> |
| 15:13 |
hbrennan |
Happy Friday! Here's a fun buggy thing ..... We've discovered a specific copy status (In Process) is no longer OPAC visible. BUT WAIT! That's not really it. On further sleuthing, I've found that I can pull up an item using the item's barcode in the Numeric Search, but items can't be found using traditional/useful title/author/keyword searches. |
| 15:13 |
hbrennan |
EVEN MORE FUN, if I change an item's copy status from In Process to another status and then back to In Process, the item can be searched for normally. |
| 15:14 |
hbrennan |
In Process copy status is still, and always has been, checked for OPAC Visible |
| 15:14 |
hbrennan |
We're on 3.0.5. |
| 15:14 |
hbrennan |
Anyone aware of a bug for this? I can't find anything |
| 15:20 |
mmorgan |
hbrennan: I have not seen that issue, we're on 3.0.9. Does it happen all In Process items? |
| 15:21 |
hbrennan |
Was just handed 3 random and they all are |
| 15:23 |
berick |
hbrennan: the copies that you changed and changed again, did they acquire values for copy "active_date" |
| 15:23 |
berick |
not sure it matters, but sounds like a possible path to follo |
| 15:23 |
berick |
w |
| 15:23 |
hbrennan |
berick: checking... |
| 15:27 |
hbrennan |
The one that is now visible has a Date Active. The ones that haven't moved from In Process and back again have no Date Active |
| 15:29 |
berick |
hbrennan: you could set the active date to NULL on the one that started working and see if it stops working again |
| 15:30 |
berick |
I don't recall if active_date is supposed to hide copies from the catalog -- I didn't think so |
| 15:30 |
berick |
but if it is in this case, could be a new bug |
| 15:31 |
mmorgan |
Our copies without an active date do display in the opac FWIW. |
| 15:31 |
hbrennan |
This would need to be done at db, not possible in client, yes? |
| 15:32 |
berick |
hbrennan: probably, not sure |
| 15:33 |
hbrennan |
I figured it was |
| 15:34 |
hbrennan |
that brought me to Use Active Date for Age Protection info... interesting lead |
| 15:35 |
hbrennan |
eh, but we have no active rules there |
| 15:37 |
mmorgan |
hbrennan: Have these items had any copy location changes? |
| 15:40 |
kmlussier |
When did the bib visibility changes go in? 3.0? I wonder if it's one of those old bib / copy visibility bugs that got fixed in later 3.0 point releases |
| 15:40 |
kmlussier |
I can't remember which releases those were fixed in. |
| 15:42 |
kmlussier |
It looks like they went in for 3.0.8. hbrennan: I would expect you to have a lot of visibility issues in the release you're on. I don't specifically remember "In Process" statuses being one of them, but there was a lot of search weirdness back then. |
| 15:44 |
kmlussier |
No, actually, maybe I'm wrong. The big changes were in 3.0.3. There was just one in 3.0.8 that addressed copy locations. Hmmmm |
| 15:45 |
hbrennan |
kmlussier: Sorry, also working the circ desk now! And it's a no-school day |
| 15:45 |
kmlussier |
hbrennan: That's okay. I was delivering fake news anyway. Pretend I didn't say anything. :) |
| 15:46 |
hbrennan |
kmlussier: Ha! |
| 15:46 |
hbrennan |
But it was exciting! |
| 15:47 |
kmlussier |
Sadly, fake news often is more exciting than real news. |
| 15:47 |
sandbergja |
So, when should we move over from the old edi_pusher.pl script to the new (as of 3.0) edi_order_pusher.pl script? |
| 15:47 |
* mmorgan |
is still wondering if there were any changes in hbrennan's copy locations |
| 15:48 |
sandbergja |
(I ask because we just discovered that all of our EDI orders have actually been failing, and we are still using the old edi_pusher.pl in 3.1.2) |
| 15:49 |
hbrennan |
mmorgan: Some that I'm holding are to be put in New Books, some into YA |
| 15:49 |
mmorgan |
And no changes recently with any copy location attributes? |
| 15:50 |
* mmorgan |
could be just grasping at straws. |
| 15:50 |
hbrennan |
I'm usually the one to do that, but since I've been gone I'm checking now... |
| 15:51 |
jihpringle |
sandbergja: we're still running the old edi pusher on 3.1.4 and not likely to switch until we upgrade to 3.3 |
| 15:51 |
hbrennan |
Thinking out loud that Copy Locations needs a frozen header line in web client... |
| 15:52 |
sandbergja |
jihpringle: thanks, that's good to know. |
| 15:53 |
hbrennan |
mmorgan: All looks good in Copy Locations |
| 15:53 |
dbwells |
hbrennan: Something else you might try in the DB would be: UPDATE biblio.record_entry SET vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(id) WHERE id = <record id here>; That could help pinpoint whether it is the fault of a missing calculation. |
| 15:55 |
hbrennan |
dbwells: ok thanks |
| 16:18 |
mmorgan |
Our new user welcome messages are happily generating, but I have a follow up action trigger filter question from yesterday. |
| 16:19 |
mmorgan |
I want to filter out patron records that do not have an email address, no point in creating a send email event for those. Any advice? |
| 16:35 |
Bmagic |
That conversation was timely, I was just troubleshooting an electronic visiiblity issue and the update statement fixed it |
| 16:36 |
Dyrcona |
mmorgan: Are you using a validator that checks for an email address on the actor.usr? |
| 16:38 |
Dyrcona |
None of the "standard" filters do what you're asking, they rely on the validator. |
| 16:38 |
mmorgan |
Dyrcona: I am not currently using a validator |
| 16:38 |
* mmorgan |
looks |
| 16:40 |
csharp |
mmorgan: it can be done in the action_trigger_filter.json - I'll share ours in a sec |
| 16:40 |
Bmagic |
is there a visibility recalculating script somewhere that just walks over the bibs slowly, one at a time, that I can use while system is in production? |
| 16:40 |
Dyrcona |
No, I think I'm wrong about it being the validator. |
| 16:40 |
mmorgan |
csharp: Yes, that's what I'm trying to do, I already have a custom filter. |
| 16:41 |
* mmorgan |
did not see a validator for patron having an email address. |
| 16:41 |
csharp |
well, if you use the filter to do it, it won't even create the events for them in the first place |
| 16:42 |
mmorgan |
charp: That's my goal :) |
| 16:42 |
csharp |
https://pastebin.com/ZNjCrThP - ours |
| 16:42 |
csharp |
credit goes to berick for that, mostly :-) |
| 16:43 |
mmorgan |
csharp: Exactly what I'm looking for! Thanks! |
| 16:43 |
mmorgan |
csharp++ |
| 16:43 |
mmorgan |
berick++ |
| 16:43 |
mmorgan |
Dyrcona++ |
| 16:44 |
csharp |
so the "checkout.due.email_notify" filter corresponds to the "hook" in the trigger event definition (in case that's not obvious, which it wasn't to me initially) |
| 16:44 |
Dyrcona |
I wasn't sure that a != or not would work with null like that. |
| 16:45 |
csharp |
so you'd need to create that hook in the UI/database too |
| 16:46 |
csharp |
Hook Key = checkout.due.email_notify, Core Type = circ, (add a descripion), Passive = True |
| 16:47 |
mmorgan |
Ok, gotcha. I'm actually looking at the au.created hook, but should apply this same logic to all the other email notices |
| 16:48 |
Dyrcona |
mmorgan: You can use the same hook with different filters as long as they are in different files an used with different a/t runner commands. |
| 16:48 |
Dyrcona |
We use checkout.due in all of our custom filters for overdue notices. |
| 16:48 |
mmorgan |
Dyrcona: Yes, I already have a custom filter set up for this. This is the last tweak :) |
| 16:49 |
Dyrcona |
Yeahp. |
| 16:51 |
Dyrcona |
I just wanted to clarify for the logs because csharp's examples implies you need a different hook for emails. You don't, but it can help organize things. |
| 16:52 |
csharp |
Bmagic: select 'update biblio.record_entry set vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(' || id || ');' from biblio.record entry where <blah>; |
| 16:52 |
csharp |
save that to a script and run the script |
| 16:53 |
csharp |
oh wait - might need a tweak, but you get the idea :-) |
| 16:53 |
Bmagic |
Will that run one record at a time? |
| 16:53 |
csharp |
yeah |
| 16:53 |
Dyrcona |
Or ditch the select and where and concatenation and just run it in the database. |
| 16:54 |
Bmagic |
oh, I see it now, a select to generate selects |
| 16:54 |
csharp |
Bmagic: my idea is create a script where every updated record is one line each |
| 16:54 |
csharp |
yeah |
| 16:54 |
Dyrcona |
Code to write code. I'm a fan of that, usually. :) |
| 16:54 |
csharp |
had to do that kind of thing serveral times over the years ;-) |
| 16:54 |
Bmagic |
:) - I have some of those around like the auditor cleaner |
| 16:57 |
Dyrcona |
Depending on how many you have to update, you could probably get away with doing them all at once. |
| 17:00 |
Bmagic |
well, I found an issue with some* of the electronic bibs... so I guess I could target those whose vis_attr_vector ='{}' ? |
| 17:01 |
Dyrcona |
You want to make them disappear? |
| 17:01 |
Bmagic |
they should not show up at a consortium search |
| 17:02 |
Bmagic |
wait, I figured that the function "biblio.calculate_bib_visibility_attribute_set" was (at some point) supposed to be run on all bibs? |
| 17:02 |
Dyrcona |
These records have located URIs? |
| 17:03 |
Bmagic |
I was working on the assumption that some subset of records hadn't had it done. Yes, they have located URI's |
| 17:03 |
Dyrcona |
Bmagic: It is run under a few conditions, IIRC. |
| 17:03 |
Bmagic |
oh sheesh. The function doesn't apply logic that would allow electronic resources to be consortial visible under the standard conditions? |
| 17:03 |
Dyrcona |
It could be settings that you're using that make them show up in consortium search. I forget all of the settings that affect that. |
| 17:03 |
Bmagic |
transcendence/856$9CONS |
| 17:06 |
Bmagic |
it looks like during the course of a production machine, the database will run the function when call numbers are updated "ELSIF OLD.call_number <> NEW.call_number THEN" |
| 17:07 |
|
mmorgan left #evergreen |
| 17:07 |
Dyrcona |
Well, I'm not exactly sure what it does with located uris.... It does *something*. The underlying function calculates a magic value, so I'd need to understand search better to know what the magic values mean. |
| 17:09 |
Bmagic |
It's not a good idea to run that just as a matter of course? I figured it's like running asset.copy_vis_attr_cache sometimes to fix visibility issues.... |
| 17:09 |
Bmagic |
asset.copy_vis_attr_cache can* perform the biblio.calculate_bib_visibility_attribute_set in-turn |
| 17:09 |
Dyrcona |
If you have to run those functions often, then you have some other problem, I would think. |
| 17:11 |
Bmagic |
I haven't run into it before. Just during the upgrade which was recent. I suppose it's possible some bibs need it still? I just figured I would hit all bibs to cover all basis (since I found at least two examples) - I could narrow it to electronic resources with vis_attr_vector='{}' |
| 17:12 |
Bmagic |
basis/bases |
| 17:14 |
Dyrcona |
Well, it looks like the function ORs the first argument with 0 when it is doing located URIs. |
| 17:15 |
Bmagic |
so is it a bad thing to run that function on everything? |
| 17:15 |
Dyrcona |
Which would produce whatever the first value is, probably the org unit. |
| 17:16 |
Dyrcona |
No, IIRC I ran it on everything during or after that upgrade. |
| 17:16 |
Dyrcona |
Haven't needed to run it since, unless I do and just don't know it. :) |
| 17:17 |
Bmagic |
ok groovy, I'll just run it on everything lest I miss one with a crazy where clause for electronic only. Maybe a good criteria is '{}' ? |
| 17:21 |
Dyrcona |
Yeah, looks like I ran it on all not-deleted bibs at the end of the 2.12 to 3.0 upgrade and after disabling some triggers. |
| 17:21 |
Bmagic |
yeah, me too |
| 17:22 |
Dyrcona |
That and not deleted, I would think. |
| 17:22 |
Bmagic |
but it wasn't the biblio.calculate_bib_visibility_attribute_set function. It was the asset.copy_vis_attr_cache |
| 17:22 |
Dyrcona |
I ran this: UPDATE biblio.record_entry SET vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(id) WHERE NOT DELETED; |
| 17:23 |
Bmagic |
oh really? Was that recommended or in an upgrade script that I missed? |
| 17:23 |
Bmagic |
oops, nevermind, found it |
| 17:25 |
Bmagic |
select count(*) from biblio.record_entry where not deleted and vis_attr_vector='{}'; 1623 |
| 17:26 |
Dyrcona |
It will probably blast through that in not time. |
| 17:26 |
Dyrcona |
No time, even... :) |
| 17:26 |
* Dyrcona |
tries to imagine "not time" and gets something like the center of a black hole. |
| 17:27 |
Bmagic |
yeah, probably. Weird though. All created post upgrade |
| 17:28 |
Dyrcona |
You may have another problem, like a missing trigger. I would look to see what these records have in common, first. |
| 17:29 |
Bmagic |
I have 1500 bibs created post upgrade that do have vis |
| 17:29 |
Dyrcona |
I might look into this next week if time permits. |
| 17:29 |
Dyrcona |
See if I can find any such records in our database. |
| 17:30 |
Bmagic |
I was about to ask |
| 17:30 |
Dyrcona |
You've gotten reports from library staff about records not showing up? |
| 17:30 |
Bmagic |
That they ARE showing up when they shouldn't be |
| 17:31 |
Dyrcona |
I see. I lost that point in all of our back and forth. |
| 17:31 |
Bmagic |
vis_attr_vector = '{}' apparently results in global visibility |
| 17:34 |
Bmagic |
nothing about these records jump out at me as having anything in common (other than having been created after the upgrade). I have Book and CD Audiobook, etc. |
| 17:35 |
Dyrcona |
Are these all supposed to have located URIs only? Do they have copies? |
| 17:36 |
Bmagic |
All the ones I checked have copies |
| 17:37 |
Bmagic |
Sounds like I need to append to my where clause |
| 17:37 |
Dyrcona |
Things with copies should visible everywhere, no? |
| 17:37 |
Bmagic |
yeah, I think that's correct |
| 17:38 |
Bmagic |
that took it down to 19 |
| 17:39 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "The query I'm using" (22 lines) at http://paste.evergreen-ils.org/14275 |
| 17:42 |
Bmagic |
Maybe bibs do not get this function run upon them until a copy is added? |
| 17:49 |
Dyrcona |
It should happen on update or insert of a bib record, call number, peer bib copy map, copy, or serial unit. |
| 17:50 |
Bmagic |
There must a be some sort of circumstance where that's not true |
| 17:51 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Bmagic: Check these triggers in your db" (7 lines) at http://paste.evergreen-ils.org/14276 |
| 17:53 |
Dyrcona |
The above is copied and pasted from the 1076 upgrade script that was part of the upgrade from 2.12 to 3.0. |
| 17:55 |
Bmagic |
yep, I'm seeing that. The trigger executes asset.cache_copy_visibility(). Which says "NEW.vis_attr_vector := biblio.calculate_bib_visibility_attribute_set(NEW.id, NEW.source, TRUE);" what happens with source is null and it's electronic? |
| 17:58 |
Bmagic |
does acn get it's rows inserted before this is calculated (when biblio.record_entry gets INSERT) ? Maybe a race condition where acn hasn't had it's ##URI##'s yet and the vis function is fired? |
| 18:00 |
Dyrcona |
If source is null, then it only calculates visibility based on the call number entries. |
| 18:01 |
Dyrcona |
If source is not null, it will add visibility as calculated from the bib source. |
| 18:01 |
Bmagic |
and if the ##URI##'s aren't there yet... I suppose this would fire again when the ##URI##'s are added, then the different portion of the function would cause the bib vis to fire anyway |
| 18:03 |
Bmagic |
Dyrcona: I've kept you late enough. Thanks for looking at this with me :) |
| 18:03 |
Dyrcona |
No problem. I'm actually lounging on my couch waiting for the family to get home from school and errands. |
| 18:04 |
* Dyrcona |
works from home on Fridays. |
| 18:04 |
Bmagic |
Good ol' Firday Evergreening from da couch |
| 18:05 |
Bmagic |
To be continued.... There has* to be some way these are getting into the database without the vis firing or* it's firing and deciding that it's global |
| 18:06 |
Dyrcona |
You can always try running the functions on a few records to see the output. |
| 18:06 |
Dyrcona |
I'd make sure that all of the triggers from that paste are present, too. |
| 18:06 |
Dyrcona |
And that the old ones, beginning a_* are gone. |
| 18:44 |
dbwells |
Bmagic: You might be hitting this bug / design limit: https://bugs.launchpad.net/evergreen/+bug/1798910 |
| 18:44 |
pinesol |
Launchpad bug 1798910 in Evergreen "Visibility attributes not updated when ingest.reingest.force_on_same_marc flag is enabled" [Undecided,Confirmed] |
| 19:54 |
|
yar joined #evergreen |
| 20:06 |
|
genpaku joined #evergreen |
| 20:31 |
Bmagic |
dbwells: ah, I'll take a look and see if I can reproduce it |
