| Time |
Nick |
Message |
| 01:10 |
|
sarabee joined #evergreen |
| 05:58 |
|
sarabee joined #evergreen |
| 07:35 |
|
ericar joined #evergreen |
| 07:49 |
|
jboyer-isl joined #evergreen |
| 07:53 |
|
rjackson_isl joined #evergreen |
| 07:56 |
|
mrpeters joined #evergreen |
| 08:27 |
|
remingtron joined #evergreen |
| 08:35 |
kmlussier |
Good morning #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:40 |
|
collum joined #evergreen |
| 08:40 |
mmorgan |
Good Morning! |
| 08:44 |
|
akilsdonk joined #evergreen |
| 08:49 |
|
Dyrcona joined #evergreen |
| 09:00 |
|
jwoodard joined #evergreen |
| 09:03 |
|
TaraC_ joined #evergreen |
| 09:03 |
|
Shae joined #evergreen |
| 09:14 |
csharp |
okay! pop quiz time! When creating an acq brief record, the entries in acq.lineitem_marc_attr_definition are a) integral to its function or b) completely unrelated |
| 09:14 |
csharp |
...and... GO! |
| 09:15 |
* csharp |
tries to add excitement to his otherwise frustrating-as-hell code diving ;-) |
| 09:17 |
Dyrcona |
Heh. "It was hard to write. It should be hard to understand." |
| 09:17 |
Dyrcona |
BBIAB. |
| 09:19 |
|
Dyrcona joined #evergreen |
| 09:19 |
* csharp |
wishes he had a better handle on the basic mechanisms after 7 years of constant study |
| 09:20 |
Dyrcona |
Well, acq has changed a lot in that time, hasn't it? |
| 09:20 |
csharp |
yep |
| 09:20 |
csharp |
and I'm just recently focusing on acq stuff |
| 09:22 |
csharp |
hmm - also puzzling, there are fields in the Line Item MARC Attribute Editor interface (Open-ILS/src/templates/conify/global/acq/lineitem_marc_attr_def.tt2) that don't exist in the acq.lineitem_marc_attr_definition table |
| 09:23 |
csharp |
and, those fields aren't defined in the acqlimad class in fm_IDL.xml |
| 09:23 |
csharp |
so I have no idea where they live either |
| 09:23 |
Dyrcona |
They likely are not used. |
| 09:23 |
csharp |
(specifically looking for 'tag' and 'subfield' |
| 09:23 |
csharp |
) |
| 09:24 |
csharp |
well, they have to be stored somewhere, because they are visible in the interface and have values |
| 09:24 |
Dyrcona |
They may have been used once and are no longer needed, or someone thought they would be needed and then were never actually used, or I could be wrong. |
| 09:25 |
tsbere |
csharp: Could they be pulled from the rest of the system's MARC defs instead of ACQ specific ones? |
| 09:26 |
Dyrcona |
I wouldn't be surprised if it the tag and subfield to get the price from, but that is actually done with XPATH. |
| 09:27 |
Dyrcona |
But, I'm just guessing without looking. |
| 09:28 |
tsbere |
csharp: Ok, I now looked at the file in question. "attrGridGetTag" and "attrGridGetSubfield" appear to exist in the js file for that interface |
| 09:28 |
csharp |
Dyrcona: that makes sense here, actually |
| 09:28 |
csharp |
tsbere: ah - yeah, now I see those |
| 09:29 |
Dyrcona |
My vote, if it counts, is to change the code to use the tag and subfield and use that to have the system build the XPATH. |
| 09:29 |
csharp |
Dyrcona++ # totally agree |
| 09:29 |
Dyrcona |
One of our most common issues with acq processing is someone making a typo in the XPATH. |
| 09:29 |
csharp |
yep - same here |
| 09:31 |
csharp |
Dyrcona: you're right - they are pulled from the xpath |
| 09:32 |
|
maryj joined #evergreen |
| 09:33 |
csharp |
and, if those defs are even relevant to acq brief records, that appears to result in invalid MARC in the brief record. See '<marc:datafield tag="001" ind1=" " ind2=" "><marc:subfield code="undefined">' in https://launchpadlibrarian.net/212932795/PINES_acq_brief_record_example.txt |
| 09:35 |
csharp |
btw, for the logs, I'm trying to address bug 1413352 |
| 09:35 |
pinesol_green |
Launchpad bug 1413352 in Evergreen "New Brief Record estimated price does not populate" (affected: 1, heat: 8) [High,Confirmed] https://launchpad.net/bugs/1413352 |
| 09:36 |
|
yboston joined #evergreen |
| 09:46 |
jeff |
Dyrcona: thanks for confirming that the DVDs-as-Laserdiscs is common. I'd be interested in your approach, when you have a moment to share. |
| 09:47 |
csharp |
Dyrcona++ # sharing his extremely useful tools |
| 09:47 |
csharp |
jeff: I used those to solve that issue too |
| 09:50 |
jeff |
csharp: "those" being the script/scripts Dyrcona mentioned last night? |
| 09:50 |
csharp |
jeff: correct |
| 09:51 |
jeff |
I feel that I have a better understanding of composite record attributes now. |
| 09:51 |
jeff |
Also metabib.record_attr_vector_list |
| 09:53 |
jeff |
I do see a lot of vendor brief on-order bibs as Laserdisc |
| 09:56 |
jeff |
of course, the 007/04 is not the worst thing about these bibs. |
| 09:56 |
jeff |
245$a ending in (Rental) |
| 09:56 |
jeff |
etc. |
| 09:57 |
|
RoganH joined #evergreen |
| 09:58 |
jeff |
a non-trivial number of OCLC records also. |
| 10:00 |
jeff |
007/04 of 'g' has been Laserdisc since 2001, when 'v' was defined for DVD |
| 10:05 |
Dyrcona |
jeff: Do you want to see that script that I mentioned yesterday? |
| 10:06 |
jeff |
Yes, please. |
| 10:08 |
bshum |
I feel like we just added laserdisc to the definition for DVD in our record attributes stuff |
| 10:08 |
bshum |
And then reingested that way. |
| 10:08 |
bshum |
Something like that anyways, during our 2.6 upgrade or so |
| 10:13 |
jeff |
if we actually have any leftover Laserdisc bibs (for our actual, now weeded Laserdisc collection), I'd imagine that they were not coded as Laserdisc in the old ILS anyway. |
| 10:14 |
bshum |
Bleh, it's the little things in life. Like one missing comma that busts some perl functions. |
| 10:36 |
jeff |
heh. the metabib.record_attr view can return attributes that seem to conflict, because it has no way of knowing when different CRA attributes don't make sense together. |
| 10:38 |
jeff |
i.e., a record with icon_format values of blu-ray and dvd, vr_format values of v and s, mra.attrs gets the blu-ray icon_format and the s vr_format |
| 10:38 |
jeff |
i don't know enough yet to know if that's any actual problem. i know there's metabib.record_attr_flat which does return both values for each of those two attrs, for example. |
| 10:38 |
Dyrcona |
jeff: https://gist.github.com/Dyrcona/b5c1df5ed41ebef50e8e |
| 10:39 |
Dyrcona |
jeff: DVD and Blu-ray makes sense for a two-disc set where one is Blu-ray and one DVD, such as a combo pack. |
| 10:40 |
Dyrcona |
Some libraries might just circulate them both together. |
| 10:42 |
jeff |
Dyrcona: right -- nothing wrong with the record having both, or having two values for vr_format and icon_format... but since metabib.record_attr can only return a single value for each attribute, it reports things like: "icon_format"=>"blu-ray", "search_format"=>"dvd", "mr_hold_format"=>"blu-ray" |
| 10:43 |
Dyrcona |
Right, I got that after reading what you said again. |
| 10:43 |
jeff |
heh. |
| 10:43 |
Dyrcona |
I was busy adding comments to the script above. :) |
| 10:44 |
jeff |
Also, I'm going to go do a quick check, but I suspect some of these blu-ray and combo records don't reflect shelf truth. |
| 10:44 |
miker |
luckily, metabib.record_attr is just a report compat view these days |
| 10:45 |
jeff |
miker: i was going to look/ask |
| 10:53 |
jeff |
are duplicate vr_format entries in config.coded_value_map a problem / known issue? Launchpad isn't turning up anything. |
| 10:55 |
jeff |
looks like we have exact duplicates for everything other than Blu-ray disc and Unspecified, and a close match with CED and CED videodisc. |
| 10:55 |
miker |
jeff: not a known issue, no. there was an upgrade script that added a few, but IIRC it protected against duplication. Dyrcona, IIRC, you were involved with that? |
| 10:56 |
miker |
jeff: do they have different ctype values? |
| 10:57 |
Dyrcona |
I might have been. I don't keep track of much history in my head any more. I usually have to ask git. |
| 10:57 |
miker |
there are def duplicate on cod/value/label, but they're differentiated by ctype |
| 10:59 |
jeff |
miker: I have 18 rows for this query, all with ctype vr_format: SELECT COUNT(*), ctype, code FROM config.coded_value_map GROUP BY ctype, code HAVING COUNT(*) > 1; |
| 11:00 |
jeff |
I don't have reason to believe that it is causing major issues at present, and it could very well be a relic of our database's storied history. |
| 11:12 |
jeff |
I think I'd be more worried about removing them at this point, outside of a planned window that included reingesting the affected records. |
| 11:13 |
jwoodard |
ok dumb question time |
| 11:14 |
jwoodard |
I just got asked about an online patron registration module. Does such a thing exist in Evergreen? |
| 11:14 |
csharp |
jwoodard: yep |
| 11:15 |
csharp |
jwoodard: live example: https://gapines.org/eg/opac/register |
| 11:15 |
|
sandbergja joined #evergreen |
| 11:15 |
jwoodard |
O_O Is it something that has to be set up or is it a default module in Evergreen? |
| 11:15 |
jeff |
another example: https://www.tadl.org/newuser/ |
| 11:16 |
jwoodard |
I just found it on our page. We do not have a link to it so I never knew about it. |
| 11:16 |
jeff |
jwoodard: It's now a supported stock feature -- you can and likely will want to edit the templates as has been done in csharp's example. |
| 11:17 |
jeff |
jwoodard: the tadl example I linked pre-dates it being built into Evergreen, so it operates a little differently. |
| 11:17 |
jwoodard |
So if a patron registers with this interface where would I find them in Evergreen to complete the process? |
| 11:18 |
jwoodard |
More how rather than where. |
| 11:18 |
jeff |
Circulation -> Pending Patrons |
| 11:18 |
jeff |
(iirc) |
| 11:19 |
csharp |
jwoodard: yep, jeff's correct - they end up in a queue for the home library they select when registering |
| 11:20 |
mmorgan |
jwoodard: There's also a library setting: "Allow Patron Self-Registration" which (iirc) enables the link in the opac. |
| 11:20 |
csharp |
GPLS is actually working up specs to add some functionality to that process (more details available soon) |
| 11:20 |
csharp |
mmorgan: that's correct |
| 11:23 |
jwoodard |
Well this is awesome. What else about Evergreen do I not know. lol |
| 11:23 |
jwoodard |
csharp++ jeff++ |
| 11:23 |
* mmorgan |
still asks that same question almost daily ;-) |
| 11:24 |
|
buzzy joined #evergreen |
| 11:25 |
kmlussier |
Sounds like a good conference presentation. Things that nobody knows about in Evergreen. |
| 11:32 |
bshum |
Hehe |
| 11:32 |
bshum |
I would attend that session. |
| 11:33 |
mmorgan |
@who would present that session? |
| 11:33 |
pinesol_green |
TaraC_ would present that session. |
| 11:59 |
|
bmills joined #evergreen |
| 12:06 |
gsams |
bshum++ #got yaz taken care of once I got the time to. |
| 12:07 |
gsams |
jwoodard: Turns out it was nevery turned on afterall because I was afraid it would get used without everyone knowing about it |
| 12:09 |
gsams |
kmlussier: I read the new features docs everytime a release is done and I still miss/forget features exist |
| 12:12 |
kmlussier |
gsams: One of the reasons I like working on the release notes so much is because it keeps me aware of all the new things we're getting. :) |
| 12:13 |
jwoodard |
gsams I turned it on for our library to test it out upon learning that it existed. It is a neat feature that I plan on implementing. |
| 12:13 |
kmlussier |
phasefx: I have no opinion on bug 1478299. I'm fine with your solution if you want to merge it. |
| 12:13 |
pinesol_green |
Launchpad bug 1478299 in Evergreen "Fix hold permit test" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1478299 |
| 12:14 |
jwoodard |
Our library services a large area so a feature like this is very helpful. |
| 12:14 |
kmlussier |
phasefx: Or do you need a signoff for it? |
| 12:16 |
gsams |
jwoodard: I'm going to flip the switch for the whole group |
| 12:16 |
kmlussier |
I had something very important I was going to work on after hitting Send on the email I just sent. I wish I could remember what it was. |
| 12:17 |
jcamins |
kmlussier: tell me what very important thing I was going to do after my morning meetings and before lunch? |
| 12:18 |
kmlussier |
jcamins: Yeah, that must have been it. |
| 12:22 |
jcamins |
And? |
| 12:22 |
kmlussier |
jcamins: Go do that thing that you need to do. You know the one! |
| 12:40 |
|
jihpringle joined #evergreen |
| 12:41 |
gsams |
jwoodard: I turned your link on for the registration |
| 12:58 |
jwoodard |
gsams: Thank you! I shot you an email about adding stuff to the page. |
| 12:59 |
bshum |
kmlussier: phasefx: I'm leaning towards his solution being generally more predictable too. I wasn't sure how the copy was chosen, since the IDs are generated somewhat randomly? |
| 13:02 |
kmlussier |
bshum: OK, well, like I said, I'm fine with it if somebody wants to merge it so that our tests can be happy again. |
| 13:14 |
|
akilsdonk_ joined #evergreen |
| 13:30 |
bshum |
~search_path |
| 13:30 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 13:46 |
Dyrcona |
@dunno |
| 13:46 |
pinesol_green |
Dyrcona: Evergreen Command Center http://apod.nasa.gov/apod/image/1204/EndeavourFlightDeck_cooper_1050.jpg |
| 13:54 |
|
ericar_ joined #evergreen |
| 14:31 |
bshum |
@hate collections |
| 14:31 |
pinesol_green |
bshum: The operation succeeded. bshum hates collections. |
| 14:31 |
bshum |
Or maybe more accurately.. |
| 14:32 |
bshum |
@hate Collections.pm |
| 14:32 |
pinesol_green |
bshum: The operation succeeded. bshum hates Collections.pm. |
| 14:32 |
bshum |
@dontcare collections |
| 14:32 |
pinesol_green |
bshum: The operation succeeded. bshum no longer hates collections. |
| 14:34 |
bshum |
mrpeters: For fun, I just uncovered https://bugs.launchpad.net/evergreen/+bug/990066 |
| 14:34 |
pinesol_green |
Launchpad bug 990066 in Evergreen "Collections call to users_of_interest fails for users where actor.usr.card is null" (affected: 1, heat: 6) [Undecided,Triaged] |
| 14:34 |
bshum |
Where _bott_ solved the null card problem a different way by having that method skip over any deleted users. |
| 14:34 |
bshum |
I think we should incorporate both fixes for a complete solution. |
| 14:34 |
bshum |
I'll try and mix-match everything into one LP with a proper pullrequest branch in a few moments. |
| 14:38 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1478299: fix location for asset used in test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=001bb57> |
| 14:45 |
bshum |
_bott_++ |
| 15:04 |
|
ericar_ joined #evergreen |
| 15:08 |
|
jlitrell joined #evergreen |
| 15:41 |
|
mrpeters joined #evergreen |
| 15:42 |
jeff |
<controlfield tag="008">880817s1988ÿÿÿÿenkÿÿÿÿ ÿÿÿÿÿÿÿÿÿ ÿÿengÿ </controlfield> |
| 15:42 |
* jeff |
weeps |
| 15:46 |
|
mrpeters joined #evergreen |
| 15:56 |
csharp |
@bartender jeff |
| 15:56 |
* pinesol_green |
fills a pint glass with Boddington's Pub Ale, and sends it sliding down the bar to jeff (http://beeradvocate.com/beer/profile/655/1798/) |
| 15:56 |
csharp |
ooh - I used to love Boddingtons |
| 15:58 |
jeff |
I found a note to myself: ``There are a number of records from [system] migration where the year value in the 008 tag is "101" for "2001", instead of "01".'' |
| 15:58 |
jeff |
In running some of the diagnostic queries I had from that discovery, I found some new things. |
| 15:59 |
|
mrpeters joined #evergreen |
| 16:02 |
jeff |
like the ÿs above, but also: this system apparently had behavior of "if date1 is empty, the 008 is a bit... short" |
| 16:15 |
kmlussier |
@weather 02771 |
| 16:15 |
pinesol_green |
kmlussier: The current temperature in Seekonk River, Providence, Rhode Island is 80.8°F (4:14 PM EDT on July 28, 2015). Conditions: Mostly Cloudy. Humidity: 74%. Dew Point: 71.6°F. Pressure: 29.92 in 1013 hPa (Falling). |
| 16:15 |
kmlussier |
Wrong |
| 16:25 |
bshum |
kmlussier: Are you ready to dance? |
| 16:26 |
jboyer-isl |
:Q |
| 16:27 |
|
mrpeters joined #evergreen |
| 16:27 |
bshum |
Calling 0921 |
| 16:34 |
pinesol_green |
Showing latest 5 of 18 commits to Evergreen... |
| 16:34 |
pinesol_green |
[evergreen|Remington Steed] LP 1198465: Initial tests for conditional negative balances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=336f8a6> |
| 16:34 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Make conditional negative balances test sql re-runnable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=14836cc> |
| 16:34 |
pinesol_green |
[evergreen|Remington Steed] LP 1198465: More tests for conditional negative balances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cde1573> |
| 16:35 |
pinesol_green |
[evergreen|Kathy Lussier] LP 1198465: Adapt some language in the negative balance branch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5ee86b> |
| 16:35 |
pinesol_green |
[evergreen|Ben Shum] LP#1198465: Stamping upgrade script for conditional negative balance - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ea55537> |
| 16:36 |
kmlussier |
I never thought I would see the day... |
| 16:36 |
mmorgan |
Woo-hoo!!! |
| 16:37 |
* dbwells |
feels a disturbance in the Force |
| 16:37 |
kmlussier |
Dyrcona++ dbwells++ remingtron++ bshum++ |
| 16:37 |
kmlussier |
I hope I didn't miss anyone. |
| 16:37 |
Dyrcona |
kmlussier++ |
| 16:37 |
Dyrcona |
You missed yourself. :) |
| 16:38 |
kmlussier |
Dyrcona: Well, I obviously am not going to give karma to myself! :) |
| 16:38 |
mmorgan |
dbwells: ...as if millions of negative balances suddently cried out in terror and were suddenly silenced. ;-) |
| 16:39 |
dbwells |
mmorgan: that's right :) |
| 16:40 |
kmlussier |
Also, mmorgan++ for doing a fair share of the testing. |
| 16:41 |
kmlussier |
Should I file a follow-up LP bug on the manual adjustments we discussed last week? |
| 16:42 |
dbwells |
remingtron++ # he deserves a little extra, those pesky tests ended up being 1700+ lines of code (repetitive, yes, but still!) |
| 16:42 |
kmlussier |
bshum++ for writing my release note entries for me. |
| 16:43 |
kmlussier |
Looks like it's a karma party day. :) |
| 16:43 |
bshum |
remingtron++ dbwells++ Dyrcona++ kmlussier++ |
| 16:44 |
dbwells |
kmlussier++ Dyrcona++ bshum++ # karma party! |
| 16:44 |
pinesol_green |
[evergreen|Kathy Lussier] lp1466201 Disable Google Analytics in the staff client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8a10391> |
| 16:45 |
pinesol_green |
[evergreen|Ben Shum] LP#1466201: Release note for disabling Google Analytics in staff interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6f332ba> |
| 16:45 |
kmlussier |
The only thing that makes me sad is that it was merged before we hit 100 comments. |
| 16:46 |
dbwells |
kmlussier: yes, I'd like to see a follow-up bug. #1198465 will hold a special place in my heart, but I would very much like to never see it again. |
| 16:46 |
pinesol_green |
[evergreen|Bill Erickson] LP1476370 Selfcheck logout warning, checkout resets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=04c67f0> |
| 16:47 |
pinesol_green |
[evergreen|Bill Erickson] LP#1476370 Selfcheck inactivity warning release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6773705> |
| 16:47 |
* kmlussier |
thinks bug 1198465 may still make appearances in her dreams. |
| 16:47 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Fix committed] https://launchpad.net/bugs/1198465 |
| 16:48 |
kmlussier |
s/dreams/nightmares |
| 16:52 |
bshum |
Hmm, miker, I'm reading over https://bugs.launchpad.net/evergreen/+bug/1465385 and I think maybe we should tag that as a bug fix for all currently supported releases; since make_release is in use by all RMs. |
| 16:52 |
pinesol_green |
Launchpad bug 1465385 in Evergreen "make_release shell syntax is wonky" (affected: 1, heat: 6) [Undecided,New] |
| 16:52 |
bshum |
I'll make some adjustments to the bug tracking appropriately. |
| 16:53 |
pinesol_green |
[evergreen|Terran McCanna] LP1454879: Add Account Expiration Date to OPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=86f6a4b> |
| 16:53 |
pinesol_green |
[evergreen|Ben Shum] LP#1454879: Release notes for Account Expiration Date in OPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c6a5404> |
| 16:53 |
bshum |
And also, probably backport. |
| 16:53 |
bshum |
Cause it looks ready to go |
| 16:57 |
pinesol_green |
[evergreen|Mike Rylander] LP#1465385: Fix some syntax issues with make_release - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c05aeb2> |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:02 |
kmlussier |
hmmm |
| 17:04 |
|
edoceo joined #evergreen |
| 17:04 |
kmlussier |
Looks like it's unrelated to new copy locations this time around. |
| 17:05 |
bshum |
Yeah, web client build failure it looks like |
| 17:06 |
bshum |
404 on the phantomjs archive or some such |
| 17:06 |
dbwells |
bshum: any chance at getting review of bug #1422379? You'd be my hero. |
| 17:07 |
pinesol_green |
Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1422379 |
| 17:07 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1347807: Add example "No Image" configuration - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5ff1828> |
| 17:07 |
pinesol_green |
[evergreen|Ben Shum] LP#1347807: Release note for "No Image" configuration examples - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8cd6c48> |
| 17:07 |
bshum |
dbwells: I aspire to be heroic. |
| 17:08 |
dbwells |
bshum: I know it isn't cut-and-dried, so any review, even if it doesn't get pushed, would be appreciated. |
| 17:09 |
bshum |
dbwells: Well it conflicts with master now. |
| 17:09 |
bshum |
So I'd probably start there. |
| 17:09 |
|
mmorgan left #evergreen |
| 17:09 |
dbwells |
bshum: darn. I'll go see how bad. |
| 17:10 |
bshum |
dbwells: It's not too crazy looking, but I haven't the same nuanced understanding of all the stuff in CircCommon.pm. |
| 17:10 |
bshum |
I'm going to go read over the SQL bits while you take a lookover |
| 17:11 |
bshum |
Oh that upgrade SQL is going to be..... FUN. |
| 17:12 |
bshum |
By fun I mean I'll probably get to go find a drink or something while I wait for it to operate. |
| 17:12 |
bshum |
I'm definitely +1 to the concept. |
| 17:12 |
bshum |
Billing timestamps have been a pain forever. |
| 17:13 |
dbwells |
bshum: cool. The rebase looks simple, just an extra 'use' in CircCommon throwing things off. One moment... |
| 17:13 |
bshum |
I can give it a proper whirl on our production dataset later this week dbwells. |
| 17:13 |
bshum |
We could definitely get some motion on it before 2.9-beta cutoff next month anyways. |
| 17:13 |
* kmlussier |
wonders how much work will need to be done to get bug 1249398 up to date with the latest code. |
| 17:13 |
pinesol_green |
Launchpad bug 1249398 in Evergreen "Clear negative balance billing option" (affected: 2, heat: 12) [Wishlist,Confirmed] https://launchpad.net/bugs/1249398 |
| 17:14 |
kmlussier |
Anyway, I guess it's time to feed the children. Have a nice night everyone! |
| 17:14 |
dbwells |
kmlussier: whoa, I forgot all about that! |
| 17:15 |
dbwells |
Very glad to see it fits with what we were talking about a few days ago. |
| 17:15 |
bshum |
"seems close to happening" |
| 17:15 |
bshum |
LOL |
| 17:15 |
kmlussier |
Yeah, I got a chuckle out of that too. |
| 17:15 |
bshum |
Only 1.5 years later anyways. |
| 17:15 |
dbwells |
Maybe the extra interface bits are almost done already (figers crossed). |
| 17:16 |
jeff |
i have a strong desire to set a few thousand marc records on fire. |
| 17:16 |
kmlussier |
dbwells: I was thinking it was a bit different, since that feature was intended to work with bills that carried a negative balance and the solution we talked about is getting rid of a positive balance bill. But maybe the underlying code works with both scenarios? |
| 17:16 |
bshum |
Evergreen 2.9 -- the release where billing was changed. FOREVER. |
| 17:17 |
dbwells |
can't type with the figers crossed, apparently. |
| 17:17 |
bshum |
And some OPAC stuff. |
| 17:17 |
kmlussier |
dbwells: That's very impressive. |
| 17:17 |
jeff |
how do others fight terrible record syndrome? i feel that it's likely a constant battle, but i also feel like we should be able to keep a better handle on it than we are currently. |
| 17:17 |
kmlussier |
Oh, I thought you said you were successful in typing with crossed fingers. |
| 17:17 |
dbwells |
:) |
| 17:18 |
* kmlussier |
really does disappear now. |
| 17:18 |
dbwells |
kmlussier: You're right, it is a different angle. We'll work it out. |
| 17:20 |
bshum |
jeff: I like to remember that it was someone else's fault. Probably. |
| 17:26 |
jeff |
we recently had a conversation where it was proposed that that was no longer a valid excuse. :-) |
| 17:26 |
jeff |
phraphrasing, "everybody in this room has been here long enough that bad records are no longer something that was broken before we got here" |
| 17:26 |
bshum |
Hahaha |
| 17:28 |
dbwells |
bshum: heading out, but force-pushed over the old "rebase" branch for bug #1422379 |
| 17:28 |
pinesol_green |
Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1422379 |
| 17:29 |
bshum |
dbwells: Okay, I'll check it out soon-ish. |
| 17:29 |
bshum |
Maybe not today, at the rate I'm going. |
| 17:30 |
dbwells |
bshum: no problem, just throwing it out there. Thanks in any case. |
| 18:08 |
|
tsbere_ joined #evergreen |
| 18:44 |
jwoodard |
Children are abound, The hot sun still shining bright, August approaches |
| 20:22 |
|
jihpringle_ joined #evergreen |
| 22:04 |
|
akilsdonk joined #evergreen |
