| Time |
Nick |
Message |
| 05:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:22 |
|
rlefaive joined #evergreen |
| 07:35 |
|
mrpeters joined #evergreen |
| 07:36 |
|
jboyer-isl joined #evergreen |
| 07:55 |
|
rlefaive joined #evergreen |
| 08:09 |
|
rlefaive joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:39 |
|
collum joined #evergreen |
| 08:43 |
|
rlefaive joined #evergreen |
| 08:55 |
|
maryj joined #evergreen |
| 08:58 |
|
jwoodard joined #evergreen |
| 09:00 |
|
akilsdonk joined #evergreen |
| 09:01 |
|
yboston joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:29 |
|
sarabee joined #evergreen |
| 09:41 |
|
rjackson_isl joined #evergreen |
| 10:01 |
|
rlefaive joined #evergreen |
| 10:45 |
|
RoganH joined #evergreen |
| 10:50 |
|
krvmga joined #evergreen |
| 10:51 |
|
Christineb_away joined #evergreen |
| 10:59 |
Bmagic |
@coffee |
| 10:59 |
* pinesol_green |
brews and pours a cup of Guatemala Xeucalvitz, and sends it sliding down the bar to Bmagic |
| 10:59 |
* Bmagic |
says mmmmmmmmm |
| 10:59 |
mmorgan |
Good idea! |
| 10:59 |
mmorgan |
@coffee |
| 11:00 |
* pinesol_green |
brews and pours a cup of Sumatra Lake Tawar, and sends it sliding down the bar to mmorgan |
| 11:00 |
Bmagic |
cheers! |
| 11:00 |
mmorgan |
:) |
| 11:00 |
Bmagic |
Happy Tuesday |
| 11:00 |
Bmagic |
evergreen++ |
| 11:08 |
bshum |
mrpeters: Were you able to replicate Jesse's bug for addedcontent? I'm still processing an upgraded system to test things out, but I didn't see any changes to the source code in that area for quite some time. |
| 11:09 |
mrpeters |
i dont have a 2.8.3 system to test on to verify, but i saw something about a change to added content in release notes for 2.9 beta |
| 11:09 |
bshum |
If not, it might be premature to tell them to file a bug on a potentially serious, but unconfirmed issue |
| 11:09 |
bshum |
mrpeters: Yeah, that's for 2.9 / master, but it was not backported to rel_2_8 |
| 11:09 |
mrpeters |
interesting |
| 11:10 |
bshum |
There haven't been any changes in that area since late 2014 or so when fixes for ContentCafe went in |
| 11:10 |
mrpeters |
i did recently install a system using rel_2_8 from sometime about 2 weeks ago, so that has to be close to 2.8.3 |
| 11:10 |
mrpeters |
but they dont use Novelist |
| 11:10 |
Dyrcona |
mrpeters: Covers are working just fine for me with the beta also. |
| 11:11 |
mrpeters |
yeah, i was probably premature in telling him to file a bug -- should have asked to see his configuration |
| 11:11 |
bshum |
Likewise, covers for Syndetics are fine for me on beta too |
| 11:11 |
mrpeters |
likely is a syntax error there |
| 11:11 |
bshum |
I actually didn't know that Novelist did covers |
| 11:12 |
mrpeters |
line 67 is just simply $ac_handler->use; |
| 11:12 |
mrpeters |
my $ac_handler = $ac_data->{module}; |
| 11:12 |
bshum |
It's possible that maybe something else could be awry too. Maybe they messed up their templates for TPAC and it's pulling the wrong source (old ISBN-style instead of record ID way). |
| 11:12 |
Dyrcona |
Their content handler isn't properly set would be my guess. |
| 11:12 |
mrpeters |
which looks like it pulls from the opensrf xml files |
| 11:12 |
bshum |
Or maybe their opensrf is using the wrong memcache |
| 11:13 |
bshum |
And their stuff isn't being stored the right way |
| 11:13 |
bshum |
Or permission errors in retrieving it |
| 11:13 |
* berick |
notes there is no added content module for for Novelist |
| 11:13 |
* Dyrcona |
was about to note that also. |
| 11:13 |
bshum |
berick++ # good point too :P |
| 11:13 |
Dyrcona |
berick++ |
| 11:13 |
berick |
if $ac_date == Novelist, it will def. fail |
| 11:13 |
berick |
ac_data |
| 11:14 |
mrpeters |
i bet thats it then |
| 11:14 |
berick |
novelist stuff is template-only |
| 11:14 |
mrpeters |
berick++ |
| 11:15 |
mrpeters |
berick: mind correcting me on the list? he probalby doesn't need to post his config files after learning what you just told us |
| 11:17 |
berick |
mrpeters: yeah, i'll respond |
| 11:17 |
Dyrcona |
He may also be confused in thinking that Novelist provides content but doesn't. |
| 11:18 |
Dyrcona |
IOW: He may think Novelist is configured to do that, but it isn't. |
| 11:24 |
jeff |
ingest internals question, hopefully a simple one: |
| 11:25 |
tsbere |
Is "simple" combined with "ingest" possible? ;) |
| 11:25 |
jeff |
maybe. :-) |
| 11:25 |
bshum |
I would like to ingest another cookie. |
| 11:25 |
bshum |
The chocolate kind. |
| 11:26 |
bshum |
With M&Ms preferrably. |
| 11:26 |
jeff |
in (i think stock) config.metabib_field def 7 for personal author, a given bib has two entries in metabib.author_field_entry with field 7: one is the author name, the other is the author name with "creator" appended. |
| 11:26 |
berick |
ingest == sarlacc pit |
| 11:26 |
Dyrcona |
I was going to say, "There are simple questions. There are no simple answers." |
| 11:27 |
jeff |
this field def has browse_field and facet_field set to true, and has a facet_xpath and browse_xpath which seems to explain why "creator" is stripped: //*[local-name()='namePart'] |
| 11:28 |
jeff |
it is unfortunately the only field def with both browse_field and facet_field set, so i can't compare against much. |
| 11:28 |
tsbere |
jeff: The amount of "so you know where I am coming from" data before your question seems to have moved it out of "simple" already. :P |
| 11:28 |
RoganH |
@coffee |
| 11:28 |
* pinesol_green |
brews and pours a cup of El Salvador Pacamara Finca Los Alpes The Bank, and sends it sliding down the bar to RoganH |
| 11:30 |
|
abneiman joined #evergreen |
| 11:31 |
jeff |
tsbere: throw all that out then, i'll just skip to the question: "Why do I have two rows for field 7 in metabib.author_field_entry for many of my bibs, which differ only in that they lack a relator term? :-) |
| 11:31 |
jeff |
" |
| 11:32 |
bshum |
jeff: Do both entries show up when you reingest? |
| 11:32 |
bshum |
I'm just wondering if there were weird shortcuts or perhaps partial reingests at play |
| 11:32 |
* bshum |
hasn't checked his index setup to know whether double is normal or not |
| 11:33 |
jeff |
select count(*), count as entries from (select source, count(*) from metabib.author_field_entry where field = 7 group by source) foo group by count order by entries; |
| 11:33 |
jeff |
the large majority of our bibs have 2 entries for field 7. |
| 11:33 |
jboyer-isl |
Re Novelist and covers from way back, they do re-sell B&T's ContentCafe for cover images as part of their offering, but you may have to pester them to actually get the CC login info. |
| 11:34 |
jeff |
we have one bib with five entries for that field. |
| 11:34 |
jeff |
hah. |
| 11:34 |
jeff |
One Direction (Musical group) |
| 11:35 |
jeff |
One Direction (Musical group) creator |
| 11:35 |
jeff |
One Direction. |
| 11:35 |
jeff |
One Direction. creator |
| 11:35 |
jeff |
One Direction. creator One Direction (Musical group) creator |
| 11:35 |
bshum |
fwiw, 7 is "corporate author" in my DB and 8 is my "personal author" |
| 11:35 |
jeff |
bshum: oh, fun. |
| 11:35 |
bshum |
So I'll start with, hmm :) |
| 11:36 |
mrpeters |
berick++ thanks! |
| 11:37 |
bshum |
And fwiw, changing your query from 7 to 8 to account for the different IDs, I do get 3 count for 5 entries, 1 with 4, lots of with 3 and loads more with 2. |
| 11:37 |
bshum |
So, yes, it seems possible :) |
| 11:38 |
jboyer-isl |
bshum, jeff, I also had a situation where an author field was out-of-whack that I re-adjusted during an upgrade (other fields were going to be clobbered if not, I think). I wonder if there are subtle differences in pre-X and post-X databases where X is between Indiana, Michigan, and Connecticut's go live dates? |
| 11:38 |
bshum |
jboyer-isl: Probably in our base start versions of Evergreen meaning quirks with the seed data between major versions. |
| 11:39 |
bshum |
Us being 1.6 or so when we started out. |
| 11:39 |
bshum |
And you guys being 1.2 or 1.4? :P |
| 11:39 |
jboyer-isl |
I don't remember if we started at 1.2 or not. I think so. |
| 11:39 |
* jeff |
nods |
| 11:39 |
bshum |
So, it's not always guaranteed that the IDs will be exactly lined up. |
| 11:39 |
jeff |
ME was 1.2.0.4 when we went live. |
| 11:40 |
jboyer-isl |
The seed data id's shouldn't have been messed with though, even if it appears they were at some point. |
| 11:40 |
jboyer-isl |
It makes upgrades more "exciting" than they need to be. |
| 11:40 |
jeff |
jotting it down as "one more interesting quirk about our db that i think i already have on a similar list somewhere" |
| 11:41 |
bshum |
jboyer-isl: Well custom metabib entries were moved up past 100 awhile back |
| 11:41 |
bshum |
I think during one of the 2.0-2.1 or so eras |
| 11:41 |
bshum |
Or maybe 1.6-2.0 |
| 11:41 |
bshum |
But all the stock stuff stayed where it was |
| 11:41 |
bshum |
Or assumed to be where it was |
| 11:41 |
bshum |
Maybe jeff has local tinkering :) |
| 11:41 |
bshum |
Or ran an early version before things stabilized |
| 11:41 |
bshum |
Or me |
| 11:41 |
bshum |
I could have done something funky back in the day |
| 11:42 |
bshum |
In any case |
| 11:42 |
bshum |
Jeff, a cursory glance at our index, I can see what you describe |
| 11:42 |
bshum |
Some entries with name, and others with name + creator, etc. |
| 11:42 |
jboyer-isl |
bshum, I guess I can't rule out local funk at this level, but I really didn't think we were touching anything in there at that point. |
| 11:42 |
jboyer-isl |
Oh well. |
| 11:44 |
bshum |
I might expect that sort of result if the mods32 entry were looking for more than one kind of information |
| 11:44 |
jeff |
anyway, looking at biblio.extract_metabib_field_entry seems to explain what i'm seeing. |
| 11:46 |
bshum |
jboyer-isl: Out of curiousity, what is your config.metabib_field for IDs 7 and 8? :D |
| 11:46 |
* bshum |
wants to know if his database is the weird one |
| 11:46 |
jeff |
bshum: stock defines it as you have, not as i have. |
| 11:47 |
jboyer-isl |
bshum: 7 is corp, 8 is peronsal |
| 11:47 |
jboyer-isl |
Peronsal sounds very French. A nice typo. |
| 11:47 |
bshum |
Okay, just thought I'd check |
| 11:48 |
jboyer-isl |
I also nudged that at one point because another id was going to collide in an upgrade (15 I think?) so we likely matched Jeff until then. |
| 11:51 |
jeff |
so, so answer my question: for config.metabib_field definitions where browse_field is true and browse_xpath is not null, you will have multiple entries in the associated metabib.{CLASS}_field_entry table which likely will differ in value. |
| 11:52 |
jeff |
this appears to include personal, conference, and other author. |
| 12:02 |
|
ericar joined #evergreen |
| 12:02 |
Dyrcona |
Stompro++ # A belated thanks for ded781a5dc2933867fd3cd41a7702bec4632fa9d |
| 12:02 |
pinesol_green |
[evergreen|Josh Stompro] LP#1478123: fix leak of file descriptors by Apache workers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ded781a> |
| 12:02 |
Dyrcona |
We'll see if that helps with our staff side's "Case of the Tuesdays." |
| 12:05 |
|
buzzy joined #evergreen |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:08 |
|
kitteh_ joined #evergreen |
| 12:17 |
|
bmills joined #evergreen |
| 12:30 |
mmorgan |
Anybody have a 2.9 beta install handy that can test the 90 day Mark Lost action trigger? Barcode CONC4000047 is one to test, it's checked out to user id 5 in the seed data. |
| 12:31 |
mmorgan |
I'm testing lp 1331174 and can't get the 90 day Mark Lost action trigger to work at all, I'm assuming this works fine in beta, and it's either me or the code, but just want to make sure. |
| 12:31 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 12:37 |
Dyrcona |
I have conerto data and the beta still loaded. I can take a look. |
| 12:38 |
mmorgan |
Dyrcona: Thanks! |
| 12:44 |
Bmagic |
Does anyone find it strange that it's possible that the master_record for a metarecord can point to a bib that is not a member of the group (metabib.metarecord_source_map)? |
| 12:50 |
|
jlitrell joined #evergreen |
| 12:50 |
Dyrcona |
mmorgan: It still work in the beta. |
| 12:51 |
Dyrcona |
works, even. :) |
| 12:51 |
mmorgan |
Dyrcona++ |
| 12:52 |
Bmagic |
mmorgan: are you testing with 2.9 beta? |
| 12:52 |
mmorgan |
Thanks, makes me feel better that the problem is with the code or me. Not sure which of those is more likely ;-) |
| 12:54 |
Dyrcona |
mmorgan: Make sure the event is enabled. It is off by default. |
| 12:54 |
mmorgan |
Bmagic: No, kmlussier built a test server from the branch for the bug. |
| 12:56 |
mmorgan |
Dyrcona: I'll recheck that. Seems like I've had it enabled/disabled and changed the intervals several times. |
| 13:00 |
|
rlefaive joined #evergreen |
| 13:00 |
Dyrcona |
I just enabled the trigger, ran action_trigger_runner.pl --process-hooks --run-pending, and the circulation on the copy mmorgan mentioned went to lost. |
| 13:00 |
Dyrcona |
"Just" meaning all "I did was...." |
| 13:01 |
Dyrcona |
Grr. Fingers don't want to cooperate today. |
| 13:01 |
mmorgan |
Ok, thanks. I'll try exactly that on the test server. |
| 13:27 |
|
ericar joined #evergreen |
| 13:47 |
|
jihpringle_ joined #evergreen |
| 14:17 |
|
rlefaive joined #evergreen |
| 14:17 |
|
csharp_athens joined #evergreen |
| 14:18 |
csharp_athens |
hello from a training in Athens, GA about Evergreen Community involvement! |
| 14:19 |
* jeff |
waves |
| 14:19 |
jeff |
hello! |
| 14:19 |
berick |
howdy! |
| 14:19 |
* bshum |
waves from the north |
| 14:20 |
* tsbere |
waves between shaking his fist at Excel::Writer::XLSX |
| 14:20 |
* jeff |
pictures csharp talking to his audience... "now, don't listen to this jeff guy..." |
| 14:20 |
bshum |
Yeah, that jeff guy |
| 14:20 |
bshum |
You gotta watch out for him. |
| 14:20 |
* berick |
waves from a place in the South with North in its name |
| 14:20 |
|
terran joined #evergreen |
| 14:20 |
jboyer-isl |
We will NOT be displaying live logs during this training session. |
| 14:20 |
bshum |
jboyer-isl++ |
| 14:20 |
jeff |
hi, terran! |
| 14:21 |
terran |
Hi Jeff! Our audience is waving back. |
| 14:23 |
terran |
bye! |
| 15:31 |
Bmagic |
Does anyone find it strange that it's possible that the master_record for a metarecord can point to a bib that is not a member of the group (metabib.metarecord_source_map)? |
| 15:32 |
jeff |
it can also point to a bib that is deleted, last i checked. |
| 15:32 |
jeff |
in your experience, is it common for it to point to a non-member bib? |
| 15:32 |
Bmagic |
I find 170 instances |
| 15:33 |
Bmagic |
where the group contains non deleted bibs and the master_record is not any of them |
| 15:33 |
Bmagic |
incoming query |
| 15:33 |
Bmagic |
select * from metabib.metarecord a where master_record not in(select source from metabib.metarecord_source_map where metarecord=a.id) and id in (select metarecord from (select metarecord,count(*) from metabib.metarecord_source_map group by metarecord having count(*) > 1) as b ) |
| 15:41 |
jeff |
hrm. first metarecord i picked does not have any rows in metabib.metarecord_source_map. |
| 15:42 |
Bmagic |
weird |
| 15:43 |
jeff |
ah. inverted my sort. i think that was an ancient record. |
| 15:43 |
Bmagic |
having count(*) > 1 should do it |
| 15:46 |
jeff |
2,348 or so for me. |
| 15:46 |
jeff |
(different query) |
| 15:46 |
jeff |
hrm. only 162 for your query. |
| 15:47 |
jeff |
oh. master_record can be null. |
| 15:48 |
jeff |
1405 metarecords with null master_record |
| 15:50 |
Bmagic |
hmm |
| 15:50 |
Bmagic |
Does it seem wrong to you? |
| 15:50 |
Bmagic |
How can the master record not be a member of the metarecord? |
| 15:51 |
jeff |
regarding the metarecords with null master_record, the first example i looked at had a metarecord and two bibs in the metarecord_source_map, but both bibs were deleted. |
| 15:52 |
Bmagic |
right, I was noticing that a great deal of my search results were deleted bibs, however, I found at least one example where the master record was pointing to a bib that really didn't belong to the others |
| 15:53 |
jeff |
yeah. |
| 15:54 |
Bmagic |
master record: mig.missourievergreen.org/eg/opac/record/1363227 Member of the group: http://mig.missourievergreen.org/eg/opac/record/889739 |
| 15:55 |
Bmagic |
Same author but the titles dont line up at all. In fact the fingerprint on the master record is different than the fingerprints for the group |
| 16:04 |
jeff |
i have one bib that is master_record on ten different metarecords. :-) |
| 16:06 |
Bmagic |
yeah, weird right? |
| 16:06 |
Bmagic |
what gives? |
| 16:07 |
jeff |
only one of those ten metarecords has any entries in metabib.metarecord_source_map |
| 16:10 |
jeff |
migrated records from the olden days in the case of the bibs that are master on 10 and 7 metabibs. |
| 16:10 |
jeff |
er, s/metabibs/metarecords/ |
| 16:10 |
jeff |
:P |
| 16:10 |
jboyer-isl |
Potential overlay issues maybe? |
| 16:10 |
Bmagic |
after the bib is overlayed - shouldnt it get ingested? |
| 16:10 |
jboyer-isl |
(i.e. the master record is changed so that it shouldn't be a member, but the case where "this record is the master" isn't fully handled?) |
| 16:11 |
jboyer-isl |
(making this up as I go, so don't do anything without at least verifying SOMETHING. ;) ) |
| 16:11 |
Bmagic |
that could be, where the master is no longer a member of the group and the master record needs to be decided again |
| 16:11 |
jeff |
another bib that is master on six metarecords has a metarecord fingerprint that seems to show an edit history -- the bib was modified in a way that changed the fingerprint. |
| 16:14 |
jeff |
some of this will date back to open-ils.ingest (now dead and gone) and the days when spidermonkey javascript was generating bib fingerprints. |
| 16:15 |
jeff |
and aside from the usual bugs that you expect to find in all software, metarecords in general were quite hidden for many years (after jspac deprecation and before metarecord support in TPAC) |
| 16:18 |
Bmagic |
jboyer-isl: I tested this theory: Found a group of bibs where the master record is in the group. I updated the MARC of the master record to make the fingerprint be totally different. The master record remained in the group even with a different fingerprint! |
| 16:19 |
Bmagic |
jboyer-isl: I decided to reingest the group, and that took care of it, suddenly the metarecord had a new master bib. However, the differently fingerprinted bib stayed in the group??.... |
| 16:19 |
jboyer-isl |
Delightful. (so to speak...) I was poking around git.evergreen... to see if I could see a hole in the remap logic, that is... slower than actually testing things. |
| 16:19 |
jeff |
i've looked into this before, lightly. |
| 16:20 |
jeff |
(well, "lightly" as in little useful output actually came of my digging) |
| 16:20 |
Bmagic |
It looks like there is an issue with removing members of a group when the fingerprint becomes different than the group. |
| 16:20 |
jboyer-isl |
Bmagic: could be a trigger that needs to look at NEW and OLD and is only looking at NEW, etc. |
| 16:20 |
Bmagic |
Can holds get messed up too? |
| 16:22 |
jboyer-isl |
Depends on what MR holds are pointed at, I don't actually have much experience with MRs at all. (we've had them disabled in the opac for some time, I think they've only recently been re-enabled) |
| 16:22 |
jeff |
i don't think there is a well-defined / exposed / documented method for recalc/rematch of a set of bibs/metarecord set; there wasn't much exposure of 'this is this in another format' in the catalog until very recently; i think that a means of manually maintaining a metarecord set would be useful |
| 16:22 |
jeff |
and with that last bit, you open the issue of "how to regen metarecords while still preserving manual adjustments" :-) |
| 16:24 |
jeff |
anyway, i'd be interested in trying some theories on a fresh install AND on an existing dataset, to help determine which are current problems vs legacy mistakes possibly needing cleanup. both will probably become more important. |
| 16:24 |
Bmagic |
is there already a bug on this? |
| 16:25 |
jeff |
i think six or seven bugs have been discussed in the last half hour here. ;-) |
| 16:25 |
jboyer-isl |
jeff: I think a method to force a rebuild of a group would be good, but I don't know about letting people muck about by hand. Seems like a process that should be possible to define well enough to handle entirely automatically, it just needs some help. |
| 16:26 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/953439 ? |
| 16:26 |
pinesol_green |
Launchpad bug 953439 in Evergreen "metabib.remap_metarecord_for_bib has bad logic" (affected: 3, heat: 14) [Undecided,Triaged] |
| 16:27 |
jboyer-isl |
I was just about to post that. Sounds related, if not the actual cause. |
| 16:28 |
jeff |
found that one. it's probably related, but likely not the only issue here. |
| 16:28 |
jeff |
bonus points: the bug isn't so old that the function and file referenced within the bug both still exist! |
| 16:30 |
Stompro |
yboston++ thanks for the signoff |
| 16:31 |
jboyer-isl |
I may have to poke around at this a little tomorrow, it's interesting, but not so interesting I can stay late to look at it. :) |
| 16:31 |
jboyer-isl |
Bmagic: I'd say your example steps are good enough for a new bug even if it is related to an open one, there aren't any that are obvious dupes. |
| 16:43 |
Bmagic |
how do I link to this conversation? |
| 16:48 |
jeff |
i've updated bug 953439 (and marked it as Fix Released) |
| 16:48 |
pinesol_green |
Launchpad bug 953439 in Evergreen "metabib.remap_metarecord_for_bib has bad logic" (affected: 4, heat: 18) [Undecided,Fix released] https://launchpad.net/bugs/953439 |
| 16:49 |
jeff |
Bmagic: this is a link directly to the line where you ask how to link to this conversation. :-) http://irc.evergreen-ils.org/evergreen/2015-08-25#i_198689 |
| 16:49 |
jeff |
and this line links to itself: http://irc.evergreen-ils.org/evergreen/2015-08-25#i_198693 |
| 16:50 |
Bmagic |
jeff: that bug was fixed in 2014? |
| 16:51 |
jeff |
that particular logic issue was eliminated (because the relevant code was replaced as part of other work), yes. |
| 16:51 |
Bmagic |
I created a new bug for this discussion |
| 16:51 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1488655 |
| 16:51 |
pinesol_green |
Launchpad bug 1488655 in Evergreen "Metarecords are not being maintained properly" (affected: 1, heat: 6) [Undecided,New] |
| 17:00 |
Bmagic |
I have a question for everyone. Has anyone tackled a claim of "Disappearing Holds" ? In other words: holds that were showing on a patrons account one minute and gone the next? |
| 17:04 |
jeff |
probably. |
| 17:09 |
|
mmorgan left #evergreen |
| 17:16 |
Bmagic |
jeff: We are getting these reports frequently enough, it makes me think there really is a problem |
| 17:17 |
jeff |
do you have any other details? what have logs shown? can you reproduce? are you auditing action.hold_request? |
| 17:17 |
Bmagic |
jeff: I was able to compare all of the ID's from action.hold_request from a copy of our database 1.5 months old against production, and found that every ID was accounted for. |
| 17:17 |
Bmagic |
jeff: action.hold_request has an auditor table? Not for me |
| 17:18 |
jeff |
it is optional, you'd need to enable it. i don't remember if there's a handy helper or docs or if you'd just have to do it by hand. |
| 17:19 |
Bmagic |
I guess I need to get that setup, because it's becoming a real thing |
| 17:19 |
jeff |
showing on a patron and then gone oftentimes means cancelled or reset, if it's "showing as available then not available" |
| 17:19 |
Bmagic |
jeff: yeah, they claim that it's not showing up under canceled either |
| 17:20 |
jeff |
ah. |
| 17:21 |
Bmagic |
haha, here is a quote from you "an uncancelled hold shows no sign at the database layer that it was ever cancelled or uncancelled. you can consult logs or you can enable auditing on action.hold_request, but i think that's it." |
| 17:21 |
|
sandbergja joined #evergreen |
| 17:21 |
Bmagic |
Dug that out http://irc.evergreen-ils.org/evergreen/2013-12-04 |
| 17:23 |
jeff |
hah |
| 17:23 |
Bmagic |
so, I'm struggling to find documents on auditing action.hold_request |
| 17:27 |
Bmagic |
Looks like it existed in 1.6 |
| 17:32 |
Bmagic |
so this worked SELECT auditor.create_auditor ( 'action', 'hold_request' ); |
| 17:32 |
Bmagic |
at least it looks like it did on the surface |
| 17:37 |
jwoodard |
Drained of energy, a haiku I cannot write, See what I did there |
| 17:37 |
Bmagic |
ha |
| 18:04 |
Bmagic |
later everyone! |
| 18:04 |
Bmagic |
jeff++ jboyer-isl++ |
| 18:09 |
|
rlefaive joined #evergreen |
| 19:23 |
|
jlitrell joined #evergreen |
| 19:36 |
|
rlefaive joined #evergreen |
| 20:15 |
|
rlefaive joined #evergreen |
| 20:37 |
Bmagic |
mmorgan: Be sure that you have the event parameters set editor=1 |
| 20:37 |
Bmagic |
@later tell mmorgan Be sure that you have the event parameters set editor=1 |
| 20:37 |
pinesol_green |
Bmagic: The operation succeeded. |
| 20:57 |
|
RoganH joined #evergreen |
| 21:07 |
|
Bmagic joined #evergreen |
| 21:07 |
|
dluch joined #evergreen |
| 21:15 |
|
rlefaive joined #evergreen |
| 21:39 |
|
RoganH joined #evergreen |
| 23:07 |
|
rlefaive joined #evergreen |
