| Time |
Nick |
Message |
| 00:07 |
|
artunit joined #evergreen |
| 00:44 |
|
artunit joined #evergreen |
| 01:03 |
|
artunit_ joined #evergreen |
| 03:56 |
|
b_bonner joined #evergreen |
| 03:56 |
|
mtcarlson_away joined #evergreen |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:33 |
|
Callender joined #evergreen |
| 07:23 |
|
artunit joined #evergreen |
| 07:44 |
|
akilsdonk joined #evergreen |
| 07:52 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
rjackson-isl joined #evergreen |
| 08:17 |
|
collum joined #evergreen |
| 08:25 |
|
mrpeters joined #evergreen |
| 08:26 |
* jeff |
yawns |
| 08:26 |
berick |
@coffee jeff |
| 08:26 |
* pinesol_green |
brews and pours a cup of Kenya Thiriku Top Auction Lot, and sends it sliding down the bar to jeff |
| 08:39 |
|
jwoodard joined #evergreen |
| 08:47 |
jeff |
berick++ |
| 08:48 |
jeff |
even if weekend headaches have me trying coffee-less weekdays (boo) |
| 08:50 |
berick |
wean your self with some... |
| 08:50 |
berick |
@tea jeff |
| 08:50 |
* pinesol_green |
brews and pours a pot of Nonpareil Taiwan Li Shan Oolong Tea, and sends it sliding down the bar to jeff (http://ratetea.com/tea/teavivre/nonpareil-taiwan-li-shan-oolong-tea/6832/) |
| 08:52 |
|
kbeswick joined #evergreen |
| 08:56 |
|
krvmga joined #evergreen |
| 08:56 |
krvmga |
has anyone run across the problem where the whole OPAC window (including the user account information) appears in the staff client search window? |
| 09:02 |
jeff |
yes. one common cause used to be when you had an idle TPAC tab that would log out the staff client's browser interfaces. |
| 09:03 |
jeff |
that bug was fixed, but it's possible the change isn't in your version, or the change was not ported to your templates. |
| 09:03 |
jeff |
(or of course, you could be running into another issue) |
| 09:05 |
jeff |
fixed in 2.3.12, 2.4.4, and 2.5.0 according to bug 1036318 |
| 09:05 |
pinesol_green |
Launchpad bug 1036318 in Evergreen 2.4 "OPAC timeout within the client" (affected: 13, heat: 68) [Medium,Fix released] https://launchpad.net/bugs/1036318 |
| 09:07 |
jeff |
one line fix is in this commit: http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fb9de907e5c114b8c72acb3aa4051d592bfe4361 |
| 09:07 |
pinesol_green |
[evergreen|Jeff Godin] Don't auto-logout TPAC in staff client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fb9de90> |
| 09:08 |
jeff |
and comment 17 on that bug has my (NOT one line) description of the issue, if you think you're running into this and would like to confirm: https://bugs.launchpad.net/evergreen/+bug/1036318/comments/17 |
| 09:08 |
pinesol_green |
Launchpad bug 1036318 in Evergreen 2.4 "OPAC timeout within the client" (affected: 13, heat: 68) [Medium,Fix released] |
| 09:10 |
|
yboston joined #evergreen |
| 09:10 |
jeff |
as well as description of a second scenario not addressed by that bug's fix. |
| 09:15 |
|
Dyrcona joined #evergreen |
| 09:44 |
krvmga |
jeff++ |
| 09:44 |
krvmga |
jeff: thanks very much :) |
| 09:50 |
|
RoganH joined #evergreen |
| 10:01 |
|
krvmga joined #evergreen |
| 10:03 |
jeff |
krvmga: was that the issue, or are you not sure yet? |
| 10:04 |
krvmga |
jeff: i'm not 100% sure yet.the report i have is that the staff are not getting a log in screen but it shows staff as already logged into the OPAC. |
| 10:05 |
|
akilsdonk joined #evergreen |
| 10:05 |
krvmga |
for instance, the OPAC login screen will display in the panel above the check out panel... |
| 10:06 |
krvmga |
would you like to see a screenshot |
| 10:06 |
krvmga |
? |
| 10:07 |
bshum |
That sounds like weird customization issues. Like your special alt patron summary? |
| 10:07 |
* bshum |
doesn't think checkout xul would ever have TPAC bits above it.... |
| 10:08 |
krvmga |
http://www.cwmars.org/content/opac-staff-client |
| 10:10 |
* bshum |
distances himself from that GUI |
| 10:10 |
* krvmga |
watches bshum moving into the distance. |
| 10:11 |
krvmga |
well, i have to say it's one of the oddest things i've seen. |
| 10:11 |
bshum |
krvgma: Not that I know enough about that GUI (other than I have numerous issues) but I suspect jeff's hypothesis is correct about session timeouts of some sort. |
| 10:12 |
* bshum |
refers krvmga to phasefx now. |
| 10:13 |
krvmga |
or phasefx2 as the case may be |
| 10:13 |
phasefx2 |
their patron summary is TT2 that lives in the TPAC area; if the session dies, you get the OPAC login page in the summary |
| 10:14 |
phasefx2 |
or if the session is evicted in memcached |
| 10:14 |
krvmga |
phasefx2: does that account for the strangeness in the screen shot? |
| 10:14 |
jeff |
(which is one of the scenarios mentioned but not addressed by the earlier referenced bug) |
| 10:15 |
phasefx2 |
krvmga: that's what I would expect to see if the session went away; but as to why the session went away (or was lost or expired), I don't know |
| 10:15 |
krvmga |
phasefx2: and is this covered in the bug fix for 2.5 (which we're upgrading to on Sunday) |
| 10:15 |
jeff |
krvmga: have you checked your template to see if it has the change introduced by commit fb9de90? |
| 10:15 |
pinesol_green |
[evergreen|Jeff Godin] Don't auto-logout TPAC in staff client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fb9de90> |
| 10:16 |
krvmga |
jeff: i have not and now, with the 2.5 upgrade in just a few days, i feel hesitant to tinker if it's going to be fixed anyway. |
| 10:16 |
* phasefx2 |
doesn't have his head in this space at that the moment, so doesn't know any real answers :) |
| 10:25 |
jeff |
krvmga: looking now could help you determine if you're running into the known (and fixed) issue, or if you are running into something else. If you're already on 2.5, you should have the fix for that bug. |
| 10:25 |
jeff |
krvmga: (but of course things can be missed when porting changes to custom templates) |
| 10:26 |
krvmga |
jeff: i'm gonna take a lot right now. |
| 10:26 |
* krvmga |
speeds off in the vague direction of the servers. |
| 10:27 |
dbs |
@who is kind of not looking forward to upgrading from 2.4 to 2.6? |
| 10:27 |
pinesol_green |
ningalls is kind of not looking forward to upgrading from 2.4 to 2.6. |
| 10:27 |
* ningalls |
doesn't have to upgrade evergreen :) |
| 10:28 |
bshum |
ningalls++ |
| 10:28 |
bshum |
:D |
| 10:29 |
|
RoganH joined #evergreen |
| 10:39 |
Dyrcona |
debuggers++ |
| 10:45 |
|
dluch joined #evergreen |
| 10:47 |
|
jwoodard joined #evergreen |
| 10:57 |
|
mrpeters left #evergreen |
| 11:32 |
|
kmlussier joined #evergreen |
| 11:37 |
Dyrcona |
jeff: On the duplicate book bag entries that we were talking about yesterday. |
| 11:37 |
Dyrcona |
jeff: The results are really strange. |
| 11:38 |
Dyrcona |
There's like one or two entries per book bag, often with ridiculous numbers like 20, or 200+, and the rest of the entries, even from within seconds of the other entries only appear once. |
| 12:12 |
|
ericar joined #evergreen |
| 12:39 |
jeff |
for the duplicate entries, are they all within seconds/minutes of each other? |
| 12:49 |
Dyrcona |
jeff, in the case of the duped records on my list, both sets of 20 were created within 5 seconds. |
| 12:49 |
Dyrcona |
each set was created about 20 seconds apart. |
| 12:52 |
jeff |
Dyrcona: i've seen "user has two holds on a bunch of items" when a user placed a hold on a list, then timed out and re-tried. this doesn't sound that similar, though. |
| 12:52 |
Dyrcona |
Nope. I don't think I would have tried adding something 20 times before giving up. |
| 12:53 |
jeff |
right. :-) |
| 13:18 |
bshum |
Reminder to fill out -- http://doodle.com/bqwp3e334zpa33f8 |
| 13:18 |
bshum |
Looks like June 12 is winning though |
| 13:30 |
Dyrcona |
That's a bit short of notice if it is tomorrow, or even Friday. |
| 13:30 |
Dyrcona |
If it is next week, I probably won't be able to make it though. |
| 13:31 |
bshum |
Yeah, I'm almost sure we need to have it on Thursday now. Though kmlussier didn't call it before she left for today. |
| 13:33 |
dbwells |
bshum: I'd say you can just make the call. Thursday or bust. |
| 13:34 |
bshum |
Alright, executive decision, Thursday 2 pm EST. |
| 13:34 |
dbwells |
bshum++ |
| 13:34 |
bshum |
Be there, or we volunteer you for EVERYTHING. |
| 14:04 |
|
geoffsams joined #evergreen |
| 14:05 |
|
bmills joined #evergreen |
| 14:12 |
bshum |
eeevil: Around? I have an MVF (maybe) question |
| 14:12 |
bshum |
So in the past, it looks like our catalogers added an "oclc" definition in config.record_attr_definition |
| 14:12 |
bshum |
And applied it to a single tag 001 |
| 14:12 |
bshum |
With the advent of MVF/CRA, I wonder if this custom definition is basically broken |
| 14:13 |
bshum |
I can't seem to find any bibs in our DB with the definition anymore, so I'm guessing it's related to the changes to record_attr, but am just looking for more leads / suggestions |
| 14:14 |
bshum |
The catalogers are understandably unhappy about having their key matchpoint for loading new records missing :\ |
| 14:14 |
eeevil |
bshum: you're sure it wasn't an identifier-class metabib field def? |
| 14:14 |
bshum |
eeevil: You mean like a metabib.field_class entry? (it was not) |
| 14:15 |
bshum |
Err, config.metabib_field_class rather |
| 14:15 |
bshum |
Sorry, jumbling my tables :\ |
| 14:17 |
pastebot |
"bshum" at 64.57.241.14 pasted "custom oclc record def pre-MVF/CRA" (5 lines) at http://paste.evergreen-ils.org/61 |
| 14:20 |
bshum |
eeevil: Assuming that's no longer a valid definition (or maybe this is some weird bug?), do you have any suggestions for us to get a new record attr into play again based on the tag? |
| 14:23 |
|
Callender_ joined #evergreen |
| 14:39 |
Bmagic |
which directory on the app server is used to compare to the staff client version to ensure compatibility? /openils/var/web/xul/server ? What file does the staff client look at in order to determine the version that the app server is running? |
| 14:41 |
bshum |
Bmagic: I've found the staff client will happily connect to a server as long as there's a version folder that'll match it in /openils/var/web/xul/ |
| 14:42 |
bshum |
So I tend to move our older installed versions out of the way |
| 14:42 |
bshum |
Like I'll put retired_* in front of it when renaming the folder out of the way |
| 14:42 |
Bmagic |
bshum: I see, even though the link is pointed to the newer version, the older staff client will connect |
| 14:42 |
bshum |
Bmagic: That's what I saw the last time I upgraded our systems anyways. |
| 14:43 |
Bmagic |
bshum: thanks I will try that |
| 14:43 |
Bmagic |
bshum: I was like, wait a minute, I know my server is 2.6 and this staff client is 2.4.1 .... ummm.. it's connecting? |
| 14:43 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Bmagick: See here" (5 lines) at http://paste.evergreen-ils.org/62 |
| 14:43 |
Dyrcona |
The client will look for a folder with its stamp version. |
| 14:43 |
jeff |
i suspect that a transfer of a hold from one title to another will result in that hold being retargeted, regardless if that hold was ready for pickup or not. |
| 14:44 |
jeff |
suspect because that's what these log entries seem to indicate. |
| 14:51 |
eeevil |
bshum: so, where are they trying to use the oclc number? |
| 14:52 |
bshum |
eeevil: I believe their intent was to use it as a matchpoint for matching up bibs during loading |
| 14:52 |
jeff |
code confirms. we should probably have more of a safety on that. |
| 14:52 |
bshum |
Or at least, that's how it used to work previously |
| 14:53 |
jeff |
I wonder if transferring a copy will break the already-captured hold. |
| 14:53 |
eeevil |
should still be possible. I mean, the data's still being extracted |
| 14:56 |
bshum |
Hmm |
| 14:59 |
bshum |
eeevil: If it was still being extracted per the definition, wouldn't I find some trace of it with something like SELECT * FROM metabib.record_attr_flat WHERE attr = 'oclc'; ? |
| 15:00 |
jboyer-isl |
jeff: Maybe I should have been more descriptive in bug 1312824, it breaks things whether the hold is on the shelf or in transit. Good times. |
| 15:00 |
pinesol_green |
Launchpad bug 1312824 in Evergreen "open-ils.circ.hold.change_title(.specific_holds) APIs cause havoc when used" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1312824 |
| 15:00 |
bshum |
Or am I not understanding the link between record_attr_definition? |
| 15:00 |
jboyer-isl |
More descriptive in the title, that is. |
| 15:01 |
eeevil |
bshum: nope ... it wouldn't be there. it's in the uncontrolled values table ... there's another view that includes that, akin to record_attr_flat. perhaps vandelay needs to look there instead |
| 15:01 |
bshum |
eeevil: Hmm, the uncontrolled table has nothing in there either |
| 15:02 |
bshum |
metabib.uncontrolled_record_attr_value |
| 15:02 |
bshum |
Assuming that's the one you mean |
| 15:03 |
jeff |
jboyer-isl: i was about to ask you something starting with "in your testing", but then i saw your comment. :-) |
| 15:03 |
bshum |
eeevil: Hmm, might it be that because "multi" is still set to TRUE for that definition, that's a potential issue? |
| 15:05 |
jeff |
jboyer-isl: i like your approach of "don't let these API calls transfer captured holds at all" |
| 15:05 |
jeff |
jboyer-isl: it gets around the issue of inconsistent ahcm when opting not to retarget (but still transferring) the captured holds |
| 15:06 |
eeevil |
bshum: shouldn't be ... it's that it's uncontrolled, I believe |
| 15:06 |
jeff |
jboyer-isl: i do wonder if the captured holds break when their copies have been moved to another bib (in the case where copies were transferred to a new bib and then the holds transferred there) |
| 15:06 |
jboyer-isl |
jeff: Definitely. There's no coordination between libraries Re: transferring title holds, so we would have libs saying "why are the items on our holds shelf trying to fill the wrong holds?" |
| 15:06 |
eeevil |
but, mutli should probably be false for that anyway |
| 15:06 |
eeevil |
(there'll only be on 001) |
| 15:07 |
jeff |
I don't recall what is done with holds in the case of a bib merge. |
| 15:07 |
* jeff |
looks |
| 15:07 |
bshum |
eeevil: I think it's only set TRUE because it's default TRUE in the table definition. |
| 15:07 |
bshum |
eeevil: As for the metabib.uncontrolled_record_attr_value, I only have 2710 rows in there, and none of them are attr 'oclc' |
| 15:07 |
eeevil |
bshum: of course, if you have EG controlling your 001/003 ... |
| 15:07 |
jboyer-isl |
jeff: Yeah, I haven't looked into that case either. I suspect the targeted copy does get dropped. |
| 15:07 |
bshum |
eeevil: Yeah, I know :) |
| 15:08 |
bshum |
Wasn't up to me, that's how the catalogers wanted it |
| 15:09 |
eeevil |
bshum: honestly, without looking directly, I can't help much more ATM ... sorry. you might want to switch from tag to xpath |
| 15:10 |
jeff |
Hrm. Looks like in the case of merges title holds are untouched. |
| 15:13 |
|
hbrennan joined #evergreen |
| 15:13 |
bshum |
eeevil: Alrighty, well I can give that a try, though I don't see any xpath examples in the stock data, so I'll have to do some digging to figure out how that gets defined. |
| 15:13 |
|
kbeswick joined #evergreen |
| 15:14 |
bshum |
That said, I'm nervous now about folks who are upgrading to 2.6 and who might have their own record_attr definitions that weren't accounted for. |
| 15:15 |
bshum |
(not sure how common or not that might be, but it makes me queasy when something like this slips) |
| 15:17 |
* jeff |
eyes OpenILS::Application::Cat::Merge::merge_records as potentially dead code |
| 15:18 |
jeff |
jboyer-isl: what methods have you used to clean up after this -- as you described it -- "havoc"? :-) |
| 15:20 |
jboyer-isl |
Since we don't know about it until after it's happened, usually the staff have already either checked the item out to someone or placed a new hold. We haven't yet gone to great lengths to correct anything. I think it was only reported a couple of times between our figuring out what was going on and my applying that basic patch. |
| 15:24 |
jeff |
neither old-school merge nor in-db merge seem to have paid any attention to title holds (though i didn't go digging too far back to confirm on the old-school method) |
| 15:30 |
jeff |
jboyer-isl: and the staff client appears to be the only thing calling open-ils.circ.hold.change_title[.specific_holds], and i don't see any references to OpenILS::Application::Circ::Holds::change_hold_title[_for_specific_holds] so i think that answering the question of "what's the impact when these holds are left on the old bib but their copies are moved" and "add a join to skip copies with in-transit holds also" followed by some testing should help bring |
| 15:38 |
|
rjackson-isl joined #evergreen |
| 15:38 |
|
jboyer-isl joined #evergreen |
| 15:39 |
jeff |
I can see two scenarios where Transfer Title Holds can be used. In one, there are no planned changes to copies or bibs, we're just moving the hold or holds. In the other, we've transferred (possibly as part of a merge) or are about to transfer copies to another bib. |
| 15:40 |
bshum |
Doh, array_to_string(array_agg()) crept in again over string_agg() |
| 15:40 |
bshum |
Just saw it part of function metabib.reingest_record_attributes() |
| 15:42 |
jeff |
In the second, I don't know that we care if the already-captured holds stay behind on the old title record unless a) it will break fulfillment / transit completion -> available -> fulfillment or b) the hold gets out of its captured status for some reason, in which case it'll likely end up being an unfillable hold |
| 15:49 |
jboyer-isl |
jeff: In the second scenario, would it not be sufficient to change the target id of a hold to the new record as the merge is performed, and not change any other fields? (Volume holds may present an issue, and copy holds are "immune" to this issue) |
| 15:52 |
|
RoganH joined #evergreen |
| 15:54 |
jeff |
jboyer-isl: possibly. there might still be potential for unexpected behavior if its target is changed but it isn't reset. perhaps we need a way to "soft-reset" a hold -- leave current_copy alone, but zero out the ahcm. |
| 15:55 |
|
akilsdonk joined #evergreen |
| 15:55 |
jeff |
jboyer-isl: there's also the potential odd scenario where you have a hold targeting Book about Trees but has a copy of "Book about Cars" captured. I don't know if it's worth doing a "if this hold's current_copy is present on the transfer destination, transfer the hold -- if not, don't" |
| 15:56 |
jeff |
tricky to anticipate expected behavior and to avoid violating least surprise? yup. :-) |
| 15:58 |
jboyer-isl |
jeff: That may be a concern for the "transfer specific holds" version of the API, but if you're transferring every hold from a car book to a tree book, you've just made a lot of people grumpy. I can't see a valid use for the "all holds" transfer outside of merge prep, in which case that should just be a part of the merge process, not a separate step. |
| 15:58 |
|
kmlussier joined #evergreen |
| 15:59 |
jboyer-isl |
This is the kind of thing that would be much easier to hash out at a hackaway. :/ |
| 15:59 |
kmlussier |
bshum++ #Follow-through on dev meeting |
| 16:00 |
jeff |
jboyer-isl: not enough end users at a hackaway for some things. :-) |
| 16:00 |
kmlussier |
bshum, eeevil: I think we may have at least one site using the 001 field as a matchpoint as bshum described. |
| 16:00 |
jboyer-isl |
jeff: That's true. |
| 16:00 |
kmlussier |
And I'm fairly sure one of the other development partners for our Vandelay project was doing the same. So if that doesn't work anymore, I think it's going to disrupt things for a lot of sites when they upgrade. |
| 16:01 |
jeff |
arguably title hold transfer could/should be part of record merge, but i can also see benefit for it being available as an explicit option outside of record merging. |
| 16:01 |
* RoganH |
suddenly remembers he had meant to send out an email last week about the hack-a-way |
| 16:02 |
bshum |
RoganH: I wasn't going to pry but I'm super curious :D |
| 16:02 |
* kmlussier |
is curious too. |
| 16:03 |
RoganH |
bshum: I'm going to send out a poll to get feedback from potential attendees just as I always have. Right now the options are (maybe) British Columbia, (maybe) Atlanta area and Rock Hill, SC. |
| 16:03 |
RoganH |
With some still up in the air I'll have to count a vote for ATL as a vote for SC if ATL falls through for some reason. |
| 16:04 |
RoganH |
On the plus side if we end up having to do SC I'll supply really good BBQ. |
| 16:06 |
jeff |
jboyer-isl: right now i think it's between "don't even try to transfer" and "transfer but do not reset captured holds" -- i think whichever doesn't break [transit->]holdshelf->checkout will work. If both don't break, then I'm leaning toward "transfer but do not reset", possibly with "add a hold note stating that the transfer took place" (maybe only for captured holds?) |
| 16:06 |
jeff |
not sure on the note, though. :P |
| 16:06 |
bshum |
RoganH: "Really good BBQ" seems like a slam dunk to me. But very cool! |
| 16:06 |
jeff |
anyway, jboyer-isl++ |
| 16:06 |
bshum |
RoganH++ # looking forward to seeing more details |
| 16:11 |
|
Callender joined #evergreen |
| 16:12 |
eeevil |
kmlussier / bshum: vandelay can match against random tag data without record attrs being involved (see: isbn), so ISTM there should be a way without involving the existing attr defs |
| 16:13 |
RoganH |
bshum: short email sent to dev list. We'll see where the discussion goes. :) |
| 16:13 |
kmlussier |
eeevil: The record attrs was what was recommended to me by an ESI developer back when we were testing the Vandelay development because the standard Vandelay matchpoints required that a subfield be used. |
| 16:15 |
eeevil |
kmlussier: gotcha. this is a solvable issue, probably very simply |
| 16:17 |
eeevil |
bshum: looking at the code, record_attr_flat /does/ include uncontrolled values |
| 16:17 |
eeevil |
so, I was wrong up there -^ |
| 16:18 |
eeevil |
and it's simply a matter of getting the 001 into the uncontrolled values table. my main suggestion remains using xpath instead of tag at this point |
| 16:18 |
bshum |
eeevil: I'm still adding raise notice to metabib.reingest_record_attribute, but I can't find where it decides to insert a tag defined SVF into the table yet. |
| 16:18 |
bshum |
Just learning how it works |
| 16:19 |
bshum |
I can definitely see it parse and find the tag defined SVF, but it never seems to add it to the uncontrolled table anywhere |
| 16:21 |
eeevil |
bshum: next to this comment: tag+sf attrs only support SVF |
| 16:21 |
eeevil |
oh, nm |
| 16:23 |
eeevil |
bshum: see: Create unknown uncontrolled values and find the IDs of the values |
| 16:23 |
eeevil |
bshum: you need to set filter=true on the def |
| 16:24 |
bshum |
eeevil: That'll do it. |
| 16:25 |
eeevil |
bshum: as a side effect, that'll give you a "oclc(0123912340924)" filter syntax for searching. so ... you're welcome? ;) |
| 16:33 |
|
gsams joined #evergreen |
| 16:39 |
|
geoffsams joined #evergreen |
| 16:44 |
bshum |
eeevil: Yep, so running reingest I can see now that it's going to the uncontrolled table, and in turn getting picked up now with record_attr, etc. |
| 16:44 |
bshum |
Presumably, something like SELECT metabib.reingest_record_attributes(id, '{oclc}'::text[], marc, FALSE) FROM biblio.record_entry WHERE deleted = FALSE; ought to go forth and reingest to get that one record attr going right? |
| 16:52 |
eeevil |
bshum: yes, but you might want to generate a script using the IDs directly, instead of one huge transaction |
| 16:53 |
bshum |
eeevil: Yep, that's what I'm doing now actually :) |
| 16:53 |
bshum |
eeevil++ # thanks for the eyes on this |
| 16:53 |
eeevil |
np |
| 16:54 |
eeevil |
I'm glad when it's all configuration. it's not free, but it's not code, either ;) |
| 16:56 |
|
DPearl joined #evergreen |
| 17:03 |
|
jeffdavis joined #evergreen |
| 17:11 |
|
StomproJ joined #evergreen |
| 17:47 |
jeff |
phew. resolved mess from Transfer Title Holds being used on Ready for Pickup holds |
| 17:48 |
jeff |
everything back where it belongs. some patrons get another set of notification(s) and more time to pick up their holds. nobody goes home unhappy. |
| 17:51 |
jeff |
and bug 1312824 exists to perhaps disable that foot cannon. :-) |
| 17:51 |
pinesol_green |
Launchpad bug 1312824 in Evergreen "open-ils.circ.hold.change_title(.specific_holds) APIs cause havoc when used" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1312824 - Assigned to Jeff Godin (jgodin) |
| 19:56 |
|
jeff joined #evergreen |
| 19:56 |
|
jeff joined #evergreen |
| 20:47 |
hbrennan_away |
Helllooo ....elooo....eloo..ello... |
| 20:47 |
hbrennan |
just doing a sound check |
| 20:47 |
dcook |
hehe |
| 20:48 |
hbrennan |
If anyone is here though, is there an easy or quick way to verify that we are not missing overdue reports? |
| 20:48 |
hbrennan |
Haven't had any produced for two days |
| 20:48 |
hbrennan |
and that's odd |
| 20:49 |
hbrennan |
I don't mean overdue reports, so much as I mean NOTICES.. the pdfs that we print and mail |
| 20:50 |
* dcook |
goes back to lurking as he doesn't actually use egils |
| 20:50 |
hbrennan |
hehe, thanks for the explanation, since your snicker gave you away as being here |
| 20:51 |
hbrennan |
Just a fan? |
| 21:02 |
dcook |
Koha dev. Figure it doesn't hurt to hear what you folk are up to :) |
| 21:03 |
dcook |
I'm originally from Canada as well, so curious about developments that can affect folk back home |
| 21:24 |
hbrennan |
Ah, of course. :) |
| 22:38 |
|
ktomita joined #evergreen |
| 23:42 |
|
hbrennan joined #evergreen |
| 23:43 |
hbrennan |
To answer my own question above, the notices are sitting in openils/var/data/overdue .... and the missing days are there, just with no overdue data.... Success! |
