| Time |
Nick |
Message |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:19 |
|
graced joined #evergreen |
| 07:35 |
|
sarabee joined #evergreen |
| 07:50 |
|
mrpeters joined #evergreen |
| 08:00 |
|
Newziky joined #evergreen |
| 08:14 |
|
rjackson_isl joined #evergreen |
| 08:18 |
|
RoganH joined #evergreen |
| 08:19 |
|
jboyer-isl joined #evergreen |
| 08:25 |
|
mrpeters joined #evergreen |
| 08:28 |
mrpeters |
does auditor.actor_usr_history keep any record of which user "created" another user? would it just be the minimum id value in the audit log for a particular actor.usr.id, with the action of "U"? |
| 08:31 |
|
collum joined #evergreen |
| 08:32 |
|
Shae joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:49 |
|
ericar joined #evergreen |
| 09:01 |
csharp |
mrpeters: iirc, there's an 'audit user' or similar field that should be what you're after |
| 09:02 |
csharp |
yeah, audit_user |
| 09:02 |
mrpeters |
does it distinctly tell you the user was created? or does it just show as an "Update" or "U" |
| 09:02 |
csharp |
I think it should be 'C' for creation, but I've never dug deep |
| 09:03 |
csharp |
the requests we usually get are along the lines of "Who changed user X?" (removed note, updated address, etc.) |
| 09:03 |
jeff |
record creation is not audited. the state of the record as it was created will be recorded on first update. |
| 09:03 |
csharp |
jeff: good to know |
| 09:04 |
csharp |
mrpeters: so you'd probably have to go to the logs for who created it |
| 09:04 |
mrpeters |
jeff: yep -- thats what i thought |
| 09:04 |
jeff |
and actor.usr does not have a creator column or similar, so i think you're going to be looking at something that is only discernable from logs. |
| 09:05 |
jeff |
unless you find that there's a part of the standard process of creating a user that results in an immediate update. |
| 09:05 |
mrpeters |
they want a report on who created a particular user (obviously migrated data will not qualify) but i was thinking the minimum id in the auditor log for the user in question would get me that info |
| 09:05 |
mrpeters |
as it was the first "update" |
| 09:05 |
jeff |
but even in that case, you may find that the action isn't one of the actions that sets audit_user / audit_ws |
| 09:06 |
mrpeters |
true |
| 09:07 |
csharp |
it's possible the "work log" within the staff client might do what they're after |
| 09:08 |
csharp |
depends on whether they're after stats or are trying to track/resolve a staff problem |
| 09:08 |
mrpeters |
its a stats thing |
| 09:08 |
csharp |
k |
| 09:10 |
jeff |
interesting: looking at a user created yesterday, they have two entries in auditor.actor_usr_history with audit_time that matches their create_date (and last_update_time). both have audit_user and audit_ws, so it looks like my musing above was on-target. |
| 09:11 |
* jeff |
throws that on the pile of things to look into later |
| 09:12 |
jeff |
but just off the top of my head, you can probably rely on "auditor.actor_usr_history with audit_time matching actor.usr.create_date for the user will contain the audit_user/audit_ws that created the user" |
| 09:13 |
jeff |
test, of course. |
| 09:14 |
mrpeters |
that may be a good start, and enough for what they want |
| 09:15 |
csharp |
so... I'm investigating another see also from tracing issue with OPAC browse search: http://gapines.org/eg/opac/browse?blimit=20&qtype=author&bterm=poznanski%2C+ursula&locg=1 is the main heading and "Archer, Ursula" is listed as a see also, but there is no authority record for "Archer, Ursula" for it to link to |
| 09:16 |
csharp |
in that case, is there a way to have see also/from tracings work - that is, when there is no auth record for the reference? |
| 09:16 |
* csharp |
just doesn't know enough about authorities to really know |
| 09:19 |
|
Newziky1 joined #evergreen |
| 09:21 |
* collum |
just created a user in his test Evergreen and two identical update rows appeared in auditor.actor_usr_history. |
| 09:27 |
mrpeters |
thanks for the test collum |
| 09:28 |
csharp |
@blame authorities |
| 09:28 |
pinesol_green |
csharp: It's all authorities's fault! |
| 09:28 |
csharp |
@who has a problem with authority? |
| 09:28 |
pinesol_green |
paxed has a problem with authority. |
| 09:30 |
|
yboston joined #evergreen |
| 09:32 |
dbs |
csharp: so you have this auth record: http://id.loc.gov/authorities/names/no2012027363.html |
| 09:32 |
|
Newziky1 left #evergreen |
| 09:34 |
csharp |
dbs: yes, I do |
| 09:35 |
dbs |
but not http://id.loc.gov/authorities/names/no2012027363.html ? |
| 09:36 |
dbs |
argh |
| 09:36 |
dbs |
http://id.loc.gov/authorities/names/n2014061399.html |
| 09:36 |
dbs |
#$*@(*! chrome highlight-no-copy-to-clipboard |
| 09:36 |
csharp |
dbs: correct |
| 09:37 |
dbs |
so the first auth says "See also" and points to a deprecated authority record; maybe your cataloguers deleted the deprecated auth record or never had it |
| 09:38 |
dbs |
(well, it doesn't even really point to the deprecated auth record because it just uses string literals) |
| 09:40 |
dbs |
I assume the reason the valid record says "see also this deprecated form" is because LoC also assumes that there will be bib records out there that had been authorized against the deprecated form, thus a search for that might turn up results you wouldn't otherwise see for Poznanski |
| 09:40 |
dbs |
but I'm doing a lot of assuming. |
| 09:44 |
csharp |
looks like we never had the deprecated record |
| 09:45 |
csharp |
the n2014061399 number is in the 010 $z field (canceled or invalid number), but that may be where you saw it in the first place ;-) |
| 09:45 |
dbs |
hey wait, 400 is "see from" |
| 09:47 |
csharp |
so should a "see from" show up in the list (btw, I have been doing authority_authority_linker.pl on that record, but seeing no change) |
| 09:47 |
csharp |
now I'm trying to disentangle what that script does |
| 09:48 |
dbs |
I think only "See also"s (5xx) are supposed to show up in the auth browse |
| 09:49 |
csharp |
dbs: "auth browse" = "OPAC browse" or auth browse in the staff client? |
| 09:50 |
csharp |
(it isn't showing either place, btw, just wanting to clarify) |
| 09:50 |
dbs |
csharp: opac browse |
| 09:51 |
csharp |
ok - good - then this may be a case of unfulfilled expectations rather than an actual technical issue |
| 09:52 |
dbs |
yeah. perhaps the thought was that you don't want to lead people _to_ an unauthorized from, and all of your entries will of course have been updated to use the preferred, authorized form :) |
| 09:52 |
dbs |
Although I've certainly seen auth browses in OPACs that had 4xx entries that said something like: "Archer, Ursula _see Poznanski, Ursula_" |
| 09:53 |
csharp |
that is what's expected here |
| 09:54 |
csharp |
I think the originating issue was "user searched for Archer, Ursula in the OPAC author browse and didn't see an entry" |
| 09:57 |
csharp |
dbs++ # troubleshooting assistance |
| 09:59 |
bshum |
mceraso++ # Bibliomation is smoothly upgraded to 2.8. |
| 09:59 |
jeff |
bshum: congrats! |
| 09:59 |
jeff |
mceraso++ |
| 10:00 |
dbs |
http://docs.evergreen-ils.org/2.5/_opac_2.html#_bib_record_browser_with_linked_authorities was the feature note; http://docs.evergreen-ils.org/2.8/_authorities.html has the technical docs that don't really put the pieces together |
| 10:03 |
csharp |
dbs: thanks |
| 10:06 |
csharp |
"If the browse heading is linked to any authority records, and if any other authority records point to those with "See also" or other non-main entry headings, those alternative headings are displayed linked to a search results page showing related bib records related to the alternate heading." |
| 10:06 |
csharp |
hmmmm |
| 10:19 |
|
mllewellyn joined #evergreen |
| 10:29 |
pinesol_green |
[evergreen|Bill Erickson] LP#1380803 Include direct charges in PO esimated price - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=caa6a95> |
| 10:29 |
pinesol_green |
[evergreen|Bill Erickson] LP#1380803 Update PO summary amounts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a91a15d> |
| 10:36 |
|
mllewellyn joined #evergreen |
| 10:43 |
|
mllewellyn joined #evergreen |
| 10:46 |
|
krvmga joined #evergreen |
| 10:49 |
|
mllewellyn joined #evergreen |
| 10:51 |
|
sandbergja joined #evergreen |
| 11:02 |
dbs |
csharp: looks like find_authority_headings_and_notes() in OpenILS::WWW::EGCatLoader::Browse is where the magic happens |
| 11:03 |
csharp |
dbs: excellent - I'll take a look |
| 11:04 |
dbs |
it's still pretty convoluted in there |
| 11:04 |
dbs |
but there are some good comments reflecting the confusion of the author :) |
| 11:11 |
|
dreuther joined #evergreen |
| 11:27 |
krvmga |
is there a limit on the number of titles that can be included in a bucket? |
| 11:27 |
eeevil |
krvmga: nope |
| 11:27 |
krvmga |
eeevil: thanks :) |
| 11:29 |
bshum |
There isn't, but I feel like there are limits to the number of things retrievable in the XUL client from a bucket before it can blow up. |
| 11:29 |
* bshum |
remembers the library that scanned over 1000 things into a copy bucket and then tried to "retrieve it" |
| 11:32 |
bshum |
Huh....... so overdue reinstatement of old fines, plus newly generated fines up to today, appears to have added up to fines greater than the max fines for a given circulation. On multiple circs since we upgraded. |
| 11:32 |
* bshum |
wonders what's changed... and double checks all the surrounding details. |
| 11:32 |
tsbere |
bshum: How much over the max fines? |
| 11:32 |
bshum |
tsbere: Well, it's $6.00 is maxfines, and it's like $9.75 atm |
| 11:33 |
bshum |
What I might have normally expected to see is reinstated overdues, and then new fines generated up to the maxfines |
| 11:33 |
bshum |
It's a lost item that came back, and they checked it in today. |
| 11:33 |
bshum |
So the original overdues were voided |
| 11:33 |
bshum |
When the lost bill was added |
| 11:33 |
bshum |
And when the item was returned, the lost bill was voided, and overdues reinstated |
| 11:34 |
bshum |
But now new overdues added onto it, up to today due to not having returned it on time. |
| 11:34 |
bshum |
But it's definitely beyond the maxfine setting that should have applied to the circ based on the rule used and what was listed in the circulation entry |
| 11:34 |
bshum |
So it seems like something is super wrong. |
| 11:35 |
tsbere |
Is it all overdues, or did other billing types get thrown into the mix? |
| 11:35 |
* tsbere |
answers "why do they owe more than X?" or "why didn't it auto-void that fine?" with "because some staff member added a billing manually" way too often |
| 11:36 |
bshum |
It looks like just overdue billing type |
| 11:37 |
csharp |
bshum: does the max_fine match the max_fine_rule on each circ? |
| 11:39 |
bshum |
csharp: Yes, the circulation entry shows the right maxfine |
| 11:39 |
csharp |
k - just checking |
| 11:41 |
|
bbqben joined #evergreen |
| 11:42 |
bshum |
I just wonder if it's a consequence of commits pushed to master as part of https://bugs.launchpad.net/evergreen/+bug/1198465 |
| 11:42 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 16, heat: 74) [Wishlist,Confirmed] |
| 11:43 |
bshum |
Changes like 54cd1b8c38ffab5cd48572a68b3544c88e7cd3eb |
| 11:43 |
pinesol_green |
[evergreen|Dan Wells] LP#1198465 lost overdues generated in main xact - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=54cd1b8> |
| 11:43 |
|
mrpeters1 joined #evergreen |
| 11:44 |
tsbere |
If the new overdues are being generated outside of an xact, and the previously voided ones are unvoided in a different xact, the two combined could result in the issue in question |
| 11:45 |
tsbere |
Or, to clear up what I was saying, if the fine generator still sees the old ones as voided it will keep adding on to max fines, it looks like. Then when the un-voiding happens it goes beyond the max. |
| 11:46 |
* tsbere |
wonders if voided overdues should count towards the max in the first place or not... |
| 11:46 |
tsbere |
I can come up with arguments both ways. <_< |
| 11:46 |
bshum |
Well, it seems like this might be a bug then. |
| 11:47 |
bshum |
To me, I think maxfine ought to be respected, and if we're there already, don't add more fines |
| 11:47 |
|
mllewellyn joined #evergreen |
| 11:47 |
tsbere |
I suppose the alternate workflow is "we generated overdues, then un-voided old ones" |
| 11:48 |
Bmagic |
I am having issues finding subroutines in the perl code associated with editor. Any insight? AKA: $editor->search_action_circulation where is search_action_circulation defined? Somehow the subroutine is parsed in the CStoreEditor.pm ? |
| 11:48 |
tsbere |
Bmagic: Some of that is auto-generated functions based on the IDL |
| 11:48 |
dbwells |
bshum: I'd say there is a good chance this is a regression from those changes you linked to. |
| 11:49 |
bshum |
dbwells: Ugh |
| 11:49 |
Bmagic |
tsbere: ah |
| 11:49 |
* bshum |
wonders how hard it'll be to unroll those from his production system before it breaks more patrons... hmm |
| 11:50 |
Bmagic |
tsbere: so, somewhere in the code I should* find sub search_action_circulation{ ? |
| 11:50 |
bshum |
dbwells: At present, I see a batch of about 6 commits that were merged related to those areas. I'm checking further to see what else altered and how. |
| 11:52 |
tsbere |
Bmagic: I imagine there is a "loop over fieldmapper/the IDL and generate functions that have a cstore handler" routine somewhere that makes the sub dynamically. |
| 11:52 |
Bmagic |
tsbere: I see, thanks! |
| 11:53 |
dbwells |
bshum: It's probably something which works in the "complete" branch for that bug, and we just didn't get the lines drawn quite right when splitting it into bite-sized pieces. I will start looking now, too, to see where I went wrong. |
| 11:54 |
tsbere |
dbwells / bshum: I think I see what is going on |
| 11:56 |
tsbere |
checkin_handle_circ does the "handle lost or longoverdue" bit, which eventually unvoids fines. do_checkin calls that.....but before then it does a handle_fines call that may ignore stop_fines. |
| 11:58 |
tsbere |
The "generate fines on checkin" call itself needs to be moved to after checkin_handle_circ, basically...even if some of the things it looks up (ignore_stop_fines) happen before then? |
| 12:00 |
dbs |
csharp: if it makes you feel any better, yeah, http://www.loc.gov/marc/authority/adtracing.html 'TRACING FIELDS - SIMPLE CROSS REFERENCES' suggests that browse should have a "Archer, Ursula -- see under Poznanski, Ursula' entry |
| 12:02 |
* dbs |
is wondering if the linking_subfield = 0 where tag IN (410, 510) is perhaps the issue |
| 12:02 |
dbs |
SELECT * FROM authority.control_set_authority_field WHERE tag IN ('410', '510', '110'); |
| 12:03 |
csharp |
dbs: linking_subfield is 0 for 510, but not for 410 |
| 12:03 |
csharp |
and not for 400 either |
| 12:04 |
dbs |
that is, maybe the 500 should have a $0 that links to the id of the auth record that has the 100? Damn it would help if the docs actually had a MARC21-centric example to help that tiny subset of libraries that use MARC21 LoC authorities. |
| 12:05 |
dbwells |
tsbere: Here is an unpushed commit from the complete branch which I think addresses what you are saying: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=542054fce727c7bd09eeb4e1fe479b919aebf3a8 |
| 12:06 |
dbwells |
There might be a simpler way to do it, but I'm still trying to get all the pieces back in my mind. |
| 12:06 |
dbs |
stock seed data says UPDATE authority.control_set_authority_field SET linking_subfield = '0' WHERE tag LIKE ANY (ARRAY['5%','7%']); |
| 12:06 |
tsbere |
dbwells: That looks like it deals with some of it. Can't say if it is the best way as I would have to start digging in a lot more. |
| 12:07 |
dbs |
csharp: right, sorry, I meant WHERE tag IN (500, 510) |
| 12:07 |
dbs |
<-- unhelpful |
| 12:07 |
jeff |
Bmagic: The subs you seek are generated by OpenILS::Utils::CStoreEditor::init() |
| 12:07 |
csharp |
dbs: yeah - 500 has "0" too |
| 12:08 |
dbwells |
tsbere: are you planning to look into it more? It like to take a crack at it, but also don't want to duplicate any other efforts. |
| 12:08 |
jeff |
Bmagic: look around line 913 of OpenILS/Utils/CStoreEditor.pm |
| 12:10 |
dbs |
csharp: so given that http://id.loc.gov/authorities/names/no2012027363.marcxml.xml has a 400, maybe that blows that theory to hell |
| 12:10 |
dbs |
(and I'm pretty sure I've been looking at local examples that have 5xx without $0 that aren't resulting in entries either) |
| 12:10 |
dbs |
E_TOO_ABSTRACT |
| 12:11 |
|
buzzy joined #evergreen |
| 12:12 |
dbs |
I guess this needs some serious TPAC updating too: http://docs.evergreen-ils.org/2.8/_opac_searching_of_authorities.html |
| 12:12 |
yboston |
dbs: I was planning on just pullign that section out |
| 12:12 |
|
mrpeters joined #evergreen |
| 12:13 |
yboston |
dbs: since that particular feature is not found in TPAC |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:18 |
dbwells |
bshum: are you in a position to test a fix? If so, I can suggest one to try. |
| 12:19 |
bshum |
dbwells: I can give it a shot. |
| 12:19 |
bshum |
dbwells: I was putting together a revert branch to remove everything and put it back to the earlier way, if you guys weren't ready to suggest anything. |
| 12:20 |
bshum |
Fine bugs make me feel weird. |
| 12:20 |
dbwells |
bshum: The fix is cherry-picking in two commits, 76ed91eaf8e2b followed by 542054fce72 |
| 12:20 |
jeff |
Every Good Bug Does Fines |
| 12:21 |
bshum |
dbwells: I'll go give that a quick whirl on our test server. |
| 12:21 |
bshum |
Lucky for me I have lots of examples of broken circs from today to try with :\ |
| 12:22 |
jeff |
and perhaos Fines Always Cause Evil? |
| 12:22 |
dbs |
yboston: well, the functionality is there, it's just part of the regular catalogue UI now accessed by "Browse the catalog" instead of under "Advanced search" right? |
| 12:29 |
yboston |
dbs: no, that doc is for an older simpler feature that Berklee paid for that only worked on JSpac |
| 12:29 |
dbwells |
bshum: I have a lunch appt in a few minutes. I'll check back and also do some testing of my own when I get back. |
| 12:29 |
yboston |
dbs: it only grabbed data from authoritites; and for example the only title search it could do was on uniform titles |
| 12:30 |
bshum |
dbwells: Thanks man, I'll see what I can find out. |
| 12:32 |
bshum |
dbwells: Checked one circ so far, and it applied up to the right max fines this time 'round |
| 12:32 |
bshum |
Testing another circ that's lost to be absolutely sure. |
| 12:35 |
|
Dyrcona joined #evergreen |
| 12:39 |
bshum |
Well, it takes its sweet time calculating (retrieving, retrieving) but it does eventually give me the right amount of overdues stopped at the maxfine as expected. |
| 12:39 |
bshum |
dbwells++ |
| 12:39 |
bshum |
We'll test further but I think we should slate those fixes for merging to master and rel_2_8 |
| 12:40 |
dbwells |
bshum++ |
| 12:40 |
dbwells |
I'll also test further this afternoon. Don't want to take one step forward, two back. |
| 12:40 |
* dbwells |
steps away for a bit |
| 12:45 |
|
bbqben joined #evergreen |
| 13:04 |
|
bmills joined #evergreen |
| 13:30 |
|
collum joined #evergreen |
| 13:38 |
tsbere |
dbwells: Sorry, I got pulled away. I have stopped looking at things at this point. (and I see you stepped away too) |
| 13:45 |
jeffdavis |
Is anyone using Summon (the discovery layer) with EG? |
| 13:55 |
Dyrcona |
@summon Dire Weasel |
| 13:55 |
pinesol_green |
Dyrcona: The horror... The horror... |
| 14:00 |
dbs |
yboston: yeah, commit e710ecbee519 seems to have the core description of the TPAC version |
| 14:00 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Bib record browser with 'see also', etc from linked authority headings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e710ecb> |
| 14:01 |
dbs |
And bug 1177810 should have the full discussion |
| 14:01 |
pinesol_green |
Launchpad bug 1177810 in Evergreen "Bib record browser with 'see also', etc from linked authority headings" (affected: 4, heat: 26) [Wishlist,Fix released] https://launchpad.net/bugs/1177810 |
| 14:01 |
|
maryj joined #evergreen |
| 14:03 |
dbs |
csharp: https://bugs.launchpad.net/evergreen/+bug/1177810/comments/30 is the smoking gun for you. We should get a summary of that whole freaking bug into the docs. |
| 14:03 |
pinesol_green |
Launchpad bug 1177810 in Evergreen "Bib record browser with 'see also', etc from linked authority headings" (affected: 4, heat: 26) [Wishlist,Fix released] |
| 14:04 |
dbs |
So I guess if you have auth record # 123 with field 100 establishing an author's name, as well as a 500 establishing a "See from" heading, it's really unlikely that that 500 is going to have a $0 pointing to its own record ID |
| 14:05 |
dbs |
but if that 500 had $0 (OCLoC)123 or whatever, you'd be golden |
| 14:05 |
dbs |
See from: oooookay |
| 14:09 |
csharp |
dbs: reading now |
| 14:09 |
csharp |
and I'll test too |
| 14:16 |
* csharp |
highlights https://bugs.launchpad.net/evergreen/+bug/1438136/comments/12 on behalf of eeevil who is soliciting feedback from people with expertise with/opinions about the query parser's functionality |
| 14:16 |
pinesol_green |
Launchpad bug 1438136 in Evergreen "OPAC searching significantly slowed by adding format filters" (affected: 1, heat: 6) [Undecided,New] |
| 14:20 |
Dyrcona |
My comment this morning was intended to say, "Dunno. Sounds good to me. Give it a try." |
| 14:20 |
Dyrcona |
'Cause, I don't feel qualified to comment otherwise. |
| 15:05 |
ldw |
afk lunch |
| 15:06 |
ldw |
mt |
| 16:37 |
|
buzzy joined #evergreen |
| 16:51 |
|
buzzy joined #evergreen |
| 17:10 |
Bmagic |
jeff: Thanks, I figured it out. It's neat how that works. |
| 17:18 |
|
mmorgan left #evergreen |
| 18:13 |
dbwells |
bshum: Did a bunch of testing, and most things worked fine. The biggest issue was that it no longer generated new overdues on lost item return due to a thinko in one of those commits. I also found one other thinko which would clobber a MAX_FINES stop_fines_reason in some cases. Here is a paste of the diff: http://paste.evergreen-ils.org/49 |
| 18:17 |
dbwells |
(To clarify, the above lost item return issue only applies if that particular setting is turned on, which is not OOTB behavior.) |
| 18:45 |
* kmlussier |
notes that a lot of libs in these parts make use of that setting. |
| 19:51 |
jeffdavis |
question about bug 1074096 |
| 19:51 |
pinesol_green |
Launchpad bug 1074096 in Evergreen "Advanced Search by Bib Call Number Returns 0 Results" (affected: 3, heat: 18) [Low,Fix released] https://launchpad.net/bugs/1074096 |
| 19:52 |
jeffdavis |
we removed Bib Call Number as a search option in numeric search. However, it still appears as an option in the basic and advanced search interfaces. Was the intent to remove it completely? |
| 19:53 |
jeffdavis |
(If so, I think we need to remove the relevant line from qtype_selector.tt2.) |
| 20:24 |
kmlussier |
jeffdavis: Oops. Our sites had customized that option away so long ago, I didn't realize that it lived anywhere other than the numeric search. Total oversight on my part. |
| 20:26 |
* kmlussier |
can whip up a branch tomorrow unless somebody beats me to it. |
| 21:08 |
jeff |
21 seconds to sync offline patron auth for ezproxy while we're down for upgrade. |
| 21:46 |
|
buzzy joined #evergreen |
| 23:00 |
|
jeff_ joined #evergreen |
| 23:13 |
|
paxed joined #evergreen |
| 23:32 |
bshum |
dbwells: Thanks for investigating. I applied the paste you suggested to our systems too. We do make use of that setting in our environment. |
| 23:33 |
bshum |
I'll coordinate with you tomorrow on getting things into some sort of branch to get pushed along to fix things before the next cuts. |
| 23:33 |
bshum |
dbwells++ |
