| Time |
Nick |
Message |
| 00:29 |
|
dbs joined #evergreen |
| 00:44 |
|
gmcharlt joined #evergreen |
| 00:56 |
|
mmorgan1 joined #evergreen |
| 07:34 |
|
rjackson-isl joined #evergreen |
| 08:10 |
|
akilsdonk joined #evergreen |
| 08:14 |
|
collum joined #evergreen |
| 08:22 |
|
ericar joined #evergreen |
| 08:30 |
|
mrpeters joined #evergreen |
| 08:31 |
|
collum joined #evergreen |
| 08:37 |
|
Shae joined #evergreen |
| 08:42 |
|
mmorgan1 left #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:46 |
|
Dyrcona joined #evergreen |
| 08:50 |
|
abowling joined #evergreen |
| 09:09 |
bshum |
csharp++ # governance list archive restored |
| 09:31 |
|
jboyer-isl joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:56 |
|
ericar_ joined #evergreen |
| 09:57 |
|
RoganH joined #evergreen |
| 10:00 |
|
jwoodard joined #evergreen |
| 10:20 |
Dyrcona |
So, I have a question. |
| 10:20 |
Dyrcona |
In looking into cstoreeditor and "hanging" transactions, I see a lot of code in booking that follows a similar pattern. |
| 10:21 |
Dyrcona |
Create the cstoreeditor with xact=>1. |
| 10:21 |
Dyrcona |
Do a search or retrieve or a json query or two. |
| 10:21 |
Dyrcona |
call cstoreditor->disconnect. |
| 10:21 |
Dyrcona |
The problem is that disconnect does not rollback the transaction. |
| 10:22 |
Dyrcona |
I see two possible ways to fix this. |
| 10:22 |
Dyrcona |
1. change the booking code to do cstoreeditor->rollback, which does the rollback and calls disconnect. |
| 10:22 |
pinesol_green |
[evergreen|Dan Wells] LP#1408803 Add 'persist' login type to auth_proxy sample config - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7267934> |
| 10:23 |
Dyrcona |
2. change cstoreeditor::disconnect to check for an open transaction and do a rollback if it finds one. |
| 10:23 |
Dyrcona |
Advantage of 1 is it doesn't change cstoreeditor. Disadvantage of 1 is we have more places to change the code. |
| 10:24 |
Dyrcona |
Advantage of 2 is we change code in one place and have less overall code to change. |
| 10:24 |
Dyrcona |
Disadvantage of 2 is we change cstoreeditor which gets used in a lot of places. |
| 10:25 |
dbs |
#2 is generally how database connections are expected to work; if you don't explicitly commit an open transaction, then you should expect it to be rolled back at disconnect time. Normally. |
| 10:25 |
Dyrcona |
However, it looks like the transaction is actually useless to cstoreeditor after the disconnect, so it seems logical that disconnect should clean up any transactions. |
| 10:25 |
Dyrcona |
dbs++ |
| 10:25 |
Dyrcona |
or should I say "jinx?" |
| 10:25 |
dbs |
It's weird that disconnect doesn't actually force the rollback anyway, I guess it doesn't really disconnect at the db level? |
| 10:26 |
Dyrcona |
dbs: y'know I should look more closely. maybe it does in the c code that cstoreditor eventually calls, but it isn't evident from the perl. |
| 10:28 |
Dyrcona |
cstoreeditor also has finish, which commits any open transactions, and calls reset. reset calls disconnect. |
| 10:28 |
Dyrcona |
but commit, calls xact_commit and then disconnect. |
| 10:28 |
* Dyrcona |
thinks cstoreeditor could use some attention. |
| 10:29 |
* tsbere |
hasn't found an obvious "when opensrf disconnects tell cstore to close down transactions" but, then again, finds the opensrf C code to be convoluted enough that it may not be possible to find something like that at a quick glance |
| 10:31 |
Dyrcona |
well, disconnect and connect are related to session which appears to only be concerned with OpenSRF sessions and not database sessions. |
| 10:32 |
jeff |
Unless there are reasons that we're missing as to why you'd ever want the ability to ->disconnect without implicit ->rollback, it sounds like the proposed change to cstoreeditor is the way to go. Nothing preventing a belt-and-suspenders approach of doing 1 also -- almost like taking time to close your file handles rather than leaving it up to the interpreter. |
| 10:34 |
eeevil |
Dyrcona: that rings a bell... there may be a fix for that already? in any case, +1 to rollback-on-disconnect |
| 10:34 |
|
sandbergja joined #evergreen |
| 10:37 |
Dyrcona |
Thanks for the feedback. I will see if I can find an existing branch via Launchpad. |
| 10:40 |
eeevil |
Dyrcona: oh, I was thinking of this: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1379824_fix_pcrud_disconnects |
| 10:43 |
Dyrcona |
Ah, OK. |
| 10:43 |
Dyrcona |
I'll make a new branch and bug then. |
| 10:44 |
eeevil |
but, I suspect something similar is going on in cstore, because we call void userDataFree( void* blob ) on opesrf-level disconnect, and that does issue a rollback |
| 10:44 |
dbs |
Dyrcona++ |
| 10:45 |
tsbere |
eeevil: Aha, I somehow missed that one. >_> |
| 10:54 |
Dyrcona |
Something is definitely going on with cstore, 'cause we go from 200 drones down to 30 in an hour. |
| 11:00 |
Dyrcona |
Something is definitely going on with ESI's internet connection. |
| 11:02 |
phasefx_ |
well, with Quasselcore, not our internet |
| 11:02 |
|
eeevil joined #evergreen |
| 11:06 |
|
mtate joined #evergreen |
| 11:06 |
|
eeevil joined #evergreen |
| 11:06 |
|
phasefx joined #evergreen |
| 11:06 |
|
BigRig joined #evergreen |
| 11:06 |
|
Callender joined #evergreen |
| 11:08 |
|
ericar_ joined #evergreen |
| 11:15 |
|
nhilton joined #evergreen |
| 11:17 |
Dyrcona |
@later tell eeevil I see where a drone exit will roll back, but I'm not seeing where a disconnect of a cstore session will call userDataFree(). Could you point out what I'm missing, please? |
| 11:17 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 11:24 |
Dyrcona |
Ah! |
| 11:24 |
Dyrcona |
@later tell eeevil Never mind, with tsbere's help, I think I found how that gets set up. |
| 11:24 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 11:25 |
Dyrcona |
For the curious, it looks like initSessionCache in oils_sql.c sets the callback to free the data at disconnect time. |
| 11:26 |
Dyrcona |
So, I should probably focus on cstoreeditors that create transactions and don't disconnect. |
| 11:27 |
Dyrcona |
However, since I don't like magical code, I'll still add the rollback in cstoreeditor disconnect. |
| 11:28 |
|
goood joined #evergreen |
| 11:29 |
goood |
Dyrcona: logs suggest this didn't come through ... http://paste.evergreen-ils.org/26 |
| 11:30 |
|
kbutler joined #evergreen |
| 11:37 |
berick |
to be clear, if either $e->rollback or $e->disconnect are called (in a timely fashion), the cstore drone is free and is no longer contributing to the drone pileup. |
| 11:38 |
berick |
adding a rollback inside of disconnect won't have any effect on it. |
| 11:41 |
berick |
if you go that route, though, beware $e->rollback == $e->xact_rollback + $e->disconnect. IOW, watch out for a disconnect loop. |
| 11:42 |
berick |
$e->xact_[rollback|commit] are the non-magical versions |
| 11:43 |
Dyrcona |
berick: I'm aware of that. I was going to do $self->xact_rollback if ($self->{xact}); |
| 11:43 |
berick |
in the end, though, i doubt the cstore explosions have anything to do with cstoreeditor and everything to do with calling code failing to disconnect/rolllback in a timely fashion. |
| 11:44 |
Dyrcona |
berick: I think it does, and I think specifically it is relates to lines like return new_editor(xact=>1)->search .... in Trigger.pm. |
| 11:44 |
berick |
Dyrcona: oh, yeah, that's bad |
| 11:44 |
Dyrcona |
Although, I agree it isn't cstoreditor per se, just some misuse of it. |
| 11:45 |
berick |
exactly |
| 11:45 |
Dyrcona |
I'll bet we have the problem 'cause we run triggers on our production server and most others run them on a utility server. |
| 11:46 |
berick |
that could def. affect it |
| 11:46 |
berick |
and just to reiterate, nothing you do to CStoreEditor will fix new_editor(xact=>1)->search... That has to be fixed in Trigger.pm. |
| 11:49 |
jeff |
is the underlying intent of something (bad, misguided, whatever) like new_editor(xact=>1)->search to effect an "authoritative" search in a pgpool-type environment? |
| 11:49 |
berick |
jeff: yeah |
| 11:49 |
jeff |
k. |
| 11:51 |
jeff |
related, and not currently relevant to me, but istr newer pgpool versions changing behavior such that BEGIN doesn't automatically mean you get the master db -- did we do something to work around that, or is that just a "be sure to configure newer pgpool versions to disable that new 'optimization'"? |
| 11:51 |
* jeff |
looks |
| 11:52 |
|
RoganH joined #evergreen |
| 11:53 |
jeff |
http://list.georgialibraries.org/pipermail/open-ils-dev/2011-August/007472.html is the last reference i was able to find (and the first one, actually) |
| 11:56 |
Dyrcona |
berick: Yep. I'm well aware of that. I think I'll hold off messing with cstoreeditor and focus on Trigger.pm. |
| 11:57 |
Dyrcona |
It just seems that for the sake of clarity and symmetry, cstoreeditor disconnect ought to explicity roll back, kind of like how commit and rollback explicitly disconnect. |
| 11:57 |
Dyrcona |
Relying on behavior in the c code seems a bit magical to me. |
| 11:59 |
berick |
Dyrcona: i'm not opposed to a $e->xact_rollback inside $e->disconnect. just didn't want you spinning your wheels on something that probably won't help your situation |
| 11:59 |
jeff |
and /*NO LOAD BALANCE*/ seems to be the magic SQL comment to work around that pgpool-II >= 3.0 behavior |
| 12:00 |
Dyrcona |
berick: Cool. |
| 12:01 |
* Dyrcona |
feels like he had a minor epiphany today, which is kind of scary in one respect. |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:14 |
Dyrcona |
mmmm... Chili. |
| 12:16 |
Dyrcona |
Ah ha! |
| 12:17 |
Dyrcona |
How's about adding a DESTROY to CstoreEditor, that checks for a xact and a session and does a rollback and disconnect? |
| 12:17 |
Dyrcona |
If you're managing transactions and objects properly, it should cause no problems. |
| 12:18 |
Dyrcona |
If you're not, it should clean up your mess. |
| 12:18 |
Dyrcona |
Then, you can go right on writing sloppy code. |
| 12:18 |
berick |
Dyrcona: it already has one |
| 12:19 |
Dyrcona |
It just calls reset. |
| 12:19 |
berick |
which calls disconnect, which frees the cstore drone |
| 12:19 |
Dyrcona |
which calls disconnect. |
| 12:19 |
Dyrcona |
Well, crap. |
| 12:19 |
Dyrcona |
Then we shouldn't be having this problem, should we? |
| 12:20 |
berick |
in the case of new_editor(xact=>1)->search, it's not obvious to me when DESTROY would actually get called. |
| 12:21 |
berick |
but in other cases, where we retain a reference to $e in a long-running function w/o disconnecting, DESTROY won't get called until the $e is out of scope, which could be well after the problem exists |
| 12:23 |
Dyrcona |
berick in the first case it *should* be called immediately after the return, but Perl's garbage collector might be lazy. |
| 12:23 |
Dyrcona |
berick most of the long running cases that I've looked at handle the transactions correctly. |
| 12:24 |
Dyrcona |
Granted, I've not looked at every instance of cstoreeditor use so far. |
| 12:24 |
berick |
yeah, the lazy garbage collector is my concern there, too |
| 12:27 |
Dyrcona |
and, relying on garbage collection is relying on magical code that you don't normally control. |
| 12:37 |
Dyrcona |
In some cases, particularly in booking, the transactions appear to be used to get authoritative data. |
| 12:37 |
Dyrcona |
It seems it might be a good idea to remove the transactions and have authoritative methods created. |
| 12:38 |
Dyrcona |
Anyway, that's just a thought for later. |
| 12:40 |
|
Callender joined #evergreen |
| 12:41 |
|
eeevil joined #evergreen |
| 12:43 |
jeff |
Dyrcona: the "might be a good idea to remove the transactions and have authoritative methods created" thought for later almost ties back into the pgpool thread from years ago :-) |
| 12:45 |
* eeevil |
reads up from goood's web session |
| 12:49 |
eeevil |
fwiw, DESTROY is called when an object goes out of scope. GC is orthogonal ... |
| 12:49 |
eeevil |
ah ha! |
| 12:50 |
eeevil |
$xact_ed_cache |
| 12:53 |
eeevil |
that holds a ref to transaction-y sessions. it's called from the authoritative wrapper in Application.pm, and nowhere else |
| 12:53 |
eeevil |
and blocks DESTROY |
| 12:56 |
jeff |
said authoritative wrapper seems to call OpenILS::Utils::CStoreEditor->flush_forced_xacts(); |
| 12:56 |
jeff |
but maybe that doesn't do enough to prevent DESTROY from being blocked? |
| 12:56 |
eeevil |
maybe not. always_xact is only set from auth_wrap, and that has to be set to cause the xact_ed_cache ref |
| 12:57 |
eeevil |
jeff: yeah... it /shouldn't/ prevent the ref. may not be ... could be a circular ref in the data structure (there are plenty) |
| 12:57 |
jeff |
right -- if always_xact wasn't set, the editors don't end up in $xact_ed_cache to begin with... |
| 12:59 |
|
nhilton_ joined #evergreen |
| 13:00 |
eeevil |
Dyrcona: are you only getting a pileup of "idle in transaction" backends? |
| 13:01 |
Dyrcona |
eeevil: Not only, but yeah we get a number of those. And a number of the disconnected after waiting for 6 seconds in osrfsys.log. |
| 13:02 |
bshum |
gmcharlt: Are we skipping this web team meeting today? |
| 13:02 |
gmcharlt |
bshum: yep; I'll send a note rescheudled for next week |
| 13:03 |
eeevil |
a/t, sip, authproxy, circ/holds.pm, actor ... all use new_editor()->search_..., but only 10 instances according to grep |
| 13:03 |
bshum |
gmcharlt: Okie dokey, thanks |
| 13:04 |
eeevil |
Dyrcona: if you're not already tackling all of that, I'd be happy to help squash some. just let me know what you've grabbed |
| 13:04 |
Dyrcona |
OK. I've not actually started editing any code, yet. |
| 13:06 |
Dyrcona |
If you want to collaborate, I'll start a collab branch. |
| 13:09 |
eeevil |
cool |
| 13:12 |
|
maryj joined #evergreen |
| 13:18 |
|
mtate joined #evergreen |
| 13:21 |
Dyrcona |
I'll start with a/t. |
| 13:23 |
eeevil |
Dyrcona: you see one in Trigger.pm and one in Reactor.pm, yes? |
| 13:24 |
|
mtate joined #evergreen |
| 13:24 |
eeevil |
(and sip was a red herring ...) |
| 13:24 |
eeevil |
and Vaidator |
| 13:24 |
eeevil |
(not a red herring) |
| 13:25 |
Dyrcona |
Well there are potentially more than that, but yeah, I see those. |
| 13:26 |
jeff |
hrm. an ack-grep that runs code through some normalization... |
| 13:26 |
jeff |
</tangent> |
| 13:28 |
eeevil |
ah, well, there are lots of "not disconnecting editors" beyond new_editor()->search... I see |
| 13:28 |
Dyrcona |
I did this: grep -P -R -A 1 "new_editor *\( *\"?'?xact\"?'? *=\> *1 *\)" ~/Src/Evergreen/Open-ILS/src/perlmods/lib/OpenILS |
| 13:28 |
Dyrcona |
Just to find where new_editor was called with xact set. |
| 13:29 |
Dyrcona |
I started looking through those files yesterday and could rule some out. |
| 13:32 |
Dyrcona |
Well, originally, I did something more like this: grep -P -R -A 1 "\"?'?xact\"?'? *=\> *1" ~/Src/Evergreen/Open-ILS/src/perlmods/lib/OpenILS |
| 13:40 |
Dyrcona |
Guess I'll file a launchpad bug.... |
| 13:53 |
|
julialima_ joined #evergreen |
| 13:55 |
|
kateb joined #evergreen |
| 13:57 |
dbs |
I order you to cut down the tallest tree in the forest with... a (red) herring! |
| 13:57 |
|
graced joined #evergreen |
| 14:03 |
Dyrcona |
eeevil: lp 1413336 |
| 14:03 |
pinesol_green |
Launchpad bug 1413336 in Evergreen "Making Better Use of CStoreEditor" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1413336 |
| 14:03 |
RoganH |
http://files.sharenator.com/monty_python_holy_grail_019_knight_NI_shrubberies_for_dawn_O-s592x320-322154-580.jpg |
| 14:06 |
csharp |
@who is one of the Knights who until recently said NI? |
| 14:06 |
pinesol_green |
Dyrcona is one of the Knights who until recently said NI. |
| 14:07 |
* Dyrcona |
now says, "Ecky-ecky-k'tang-zip-boing-warble." |
| 14:07 |
csharp |
Dyrcona++ |
| 14:07 |
berick |
@who says NI to [someone] |
| 14:07 |
pinesol_green |
Sato says NI to RoganH. |
| 14:08 |
RoganH |
Dyrcona++ |
| 14:12 |
|
nhilton joined #evergreen |
| 14:15 |
Dyrcona |
Ah.. here's a question. |
| 14:15 |
Dyrcona |
What happens to results from a substream search if the transaction is rolled back and the editor disconnected? |
| 14:16 |
Dyrcona |
S'pose I can write a test program to find out. |
| 14:18 |
berick |
cseditor does everything synchronously, so you couldn't disconnect/rollback until all results had been retrieved. |
| 14:19 |
berick |
in which case they're no different than non-substream data |
| 14:19 |
Dyrcona |
OK/ |
| 14:19 |
Dyrcona |
ok. |
| 14:27 |
|
akilsdonk joined #evergreen |
| 14:35 |
|
krvmga joined #evergreen |
| 14:46 |
|
chatley joined #evergreen |
| 14:59 |
bshum |
Aww, Google Maps engine is going away? |
| 15:04 |
jeff |
looks like GME goes away sometime next Jan (2016), and they're returning focus to the Maps API. |
| 15:21 |
bshum |
mmorgan: Thanks for confirming bug 1412893 with your findings. |
| 15:21 |
pinesol_green |
Launchpad bug 1412893 in Evergreen "Applying lost and paid status at the wrong time" (affected: 2, heat: 10) [Undecided,Confirmed] https://launchpad.net/bugs/1412893 |
| 15:22 |
mmorgan |
bhsum: You're welcome! |
| 15:28 |
bshum |
I'm contemplating some ways of trying to pin it to only apply closing the transactions on Lost or Longoverdue (the other status) |
| 15:28 |
bshum |
But I'm just not sure about what if a stop_fines get added before either of those reasons. For some reason. But the end result is still some sort of lost thingy. |
| 15:30 |
mmorgan |
So if a transaction already has a stop_fines reason, and then it's marked lost, doesn't stop_fines get changed to LOST? |
| 15:31 |
bshum |
That's what I'm not sure of. |
| 15:31 |
bshum |
I think it doesn't change. |
| 15:32 |
bshum |
But I might be wrong on that. |
| 15:32 |
kmlussier |
I thought it did get changed when it's marked as lost. |
| 15:32 |
bshum |
If so, then that seems like an easy thing to check for in the logic... |
| 15:32 |
bshum |
Well "easy" |
| 15:33 |
mmorgan |
Just delared a MAXFINES transaction lost on our training system and the stop_fines changed to LOST |
| 15:33 |
kmlussier |
But another thing you might want to check is what happens to that stop fines reason when the item is checked in again. |
| 15:34 |
kmlussier |
I knew the answer to that question a few months ago. |
| 15:34 |
tsbere |
I believe marking as claims returned will overwrite the lost stop fines reason as well. |
| 15:34 |
tsbere |
Just as an extra data point |
| 15:35 |
bshum |
Then I feel better about looking at the stop_fine reason to decide whether to set the lost&paid status |
| 15:35 |
bshum |
mmorgan++ # testing |
| 15:42 |
* dbs |
moves onto trying to find out why "Add to list" is failing silently (at least client side), wonders whether our HTTPS-everything config may be a factor. |
| 15:44 |
dbs |
"GET /eg/opac/mylist/add?locg=105;record=830689 HTTP/1.0" 302 4896 "http://laurentian.concat.ca/eg/opac/mylist/add?locg=105;record=830689" says yes. |
| 15:44 |
dbs |
302 = "go to HTTPS dummy!" |
| 15:45 |
kmlussier |
For those who missed the email, the scheduling poll for our next Bug Squashing Day is at http://doodle.com/umc27afh7akqczft |
| 15:46 |
* dbs |
squints at ctx.opac_root |
| 15:47 |
* Dyrcona |
pushed a commit to fix a/ts to the collab branch. |
| 15:47 |
Dyrcona |
Tested it on dev with a hold notification and it still works. |
| 15:48 |
Dyrcona |
We're going to load it into production next time we have to restart services. |
| 15:49 |
dbs |
$ctx->{base_path} = $r->dir_config('OILSWebBasePath'); # getting there |
| 15:51 |
|
vlewis joined #evergreen |
| 15:58 |
dbs |
but of course it works fine for me. what the... |
| 16:00 |
gsams |
I have two reports related questions(SQL is alright as well, but reports would help more of less acquainted.) |
| 16:01 |
gsams |
Has anyone had to pull information on merged patrons before? |
| 16:01 |
gsams |
as in, identify patrons that have been merged over time |
| 16:02 |
bshum |
gsams++ # trying to help Ashbury with their ILS witchery :\ |
| 16:02 |
|
vlewis_ joined #evergreen |
| 16:03 |
gsams |
heh, that one was a single easy part of a much murkier whole. |
| 16:03 |
bshum |
gsams: If they were merged via the staff client or with the corresponding SQL function, there wouldn't be much evidence of the separate accounts. |
| 16:03 |
bshum |
How would you identify them as having been merged? |
| 16:03 |
|
julialima_ left #evergreen |
| 16:03 |
bshum |
What are you trying to prove/disprove/gather intel on? |
| 16:04 |
gsams |
bshum: my assumption would be finding multiple cards referencing the same id from the usr table |
| 16:04 |
gsams |
but that would also include replacement cards if I'm not mistaken |
| 16:04 |
bshum |
gsams: Correct. |
| 16:04 |
bshum |
So that might not be the best indicator. |
| 16:04 |
gsams |
I think the libraries that are asking are looking for a way to make sure patrons are being merged appropriately |
| 16:05 |
gsams |
Of course, I felt that the patrons could be easily switched after the fact which would negate the problem entirely |
| 16:05 |
Dyrcona |
You might also find cases of patrons who legitimately have more than one card, though you can't really do that via the client. |
| 16:05 |
bshum |
Dyrcona: Well you can now. |
| 16:06 |
bshum |
I think there's an active toggle on all cards in the client. |
| 16:06 |
Dyrcona |
I meant more than one active card. |
| 16:06 |
RoganH |
I can think of lots of reasons for patrons to have more than one active card, especially in consortiums. |
| 16:07 |
gsams |
We try to avoid that within the group, which I suppose is why this question formed |
| 16:07 |
bshum |
Dyrcona: Plus I think it's a YAOUS to configure to deactivate / delete cards. Otherwise, it might keep them all active on the user post-merge? |
| 16:07 |
gsams |
technically the cards from both of the original records work on the merged record |
| 16:07 |
RoganH |
So, there are staff level concerns that it's not working correctly? Because of an incident or because they are concerned about something they haven't observed? |
| 16:07 |
gsams |
and appear to be active, at least in my experience here |
| 16:07 |
bshum |
gsams: Well, technically they both retrieve the user, but only the "active" card can be checked out to. |
| 16:08 |
gsams |
bshum: ah. |
| 16:08 |
gsams |
RoganH: I think they are concerned that the patron's wishes are not being kept in mind when merging and they wish to double check the work in some fashion |
| 16:08 |
bshum |
If they're both active, then I think it's the YAOUS |
| 16:09 |
gsams |
I am unfamiliar with YAOUS |
| 16:09 |
bshum |
~yaous |
| 16:09 |
pinesol_green |
yaous is an acronym for Yet Another Org Unit Setting |
| 16:09 |
gsams |
ha |
| 16:09 |
RoganH |
I'd do this as a controlled experiment. |
| 16:09 |
bshum |
The setting in question being in group Circulation "Patron Merge Deactivate Card" |
| 16:10 |
bshum |
If that's set to TRUE for a given org unit, it'll deactivate the cards on patron merge. |
| 16:10 |
bshum |
Otherwise, I think it'll leave any merged cards as active. |
| 16:10 |
RoganH |
Merge two known accounts and show them the before and after to show them what happens. I wouldn't put too much research into what sounds like a vaguely defined concern. |
| 16:11 |
gsams |
bshum: What is the default for that setting? It appears to be blank in my group. |
| 16:11 |
bshum |
gsams: I don't believe there is a default. |
| 16:11 |
|
mnsri_ joined #evergreen |
| 16:11 |
|
mtcarlson joined #evergreen |
| 16:11 |
gsams |
RoganH: I was actually planning to do just that in case this came up. |
| 16:11 |
bshum |
If it's unset, I would assume it would leave all barcodes active on the user post-merge |
| 16:11 |
bshum |
If you set it to TRUE, then only the primary card of the winning account post-merge stays active, other cards are deactivated. |
| 16:12 |
gsams |
Okay, thanks for helping out on that |
| 16:12 |
gsams |
Dyrcona++ |
| 16:12 |
gsams |
bshum++ |
| 16:12 |
gsams |
RoganH++ |
| 16:12 |
bshum |
gsams: If you really wanted to get a list of all users with multiple cards though, that ought to be simple enough :) |
| 16:13 |
bshum |
With SQL anyways |
| 16:13 |
bshum |
:D |
| 16:13 |
bshum |
@love SQL |
| 16:13 |
pinesol_green |
bshum: The operation succeeded. bshum loves SQL. |
| 16:13 |
gsams |
bshum: I have that list actually. From the effort that took I would suggest it isn't reasonable to pull it through reports |
| 16:13 |
gsams |
but I had to ask! |
| 16:14 |
|
maryj left #evergreen |
| 16:15 |
gsams |
second question: Our state recently requested collection age information in the annual report. I've been messing around with various methods of doing this within reports and none of them come out clean. |
| 16:15 |
gsams |
I was actually wondering if anyone had a query that pull a count of the collection broken down by age. |
| 16:15 |
gsams |
relatively cleanly, I might add |
| 16:16 |
gsams |
I'm more afraid this is a problem due to poor cataloging than anything else. |
| 16:16 |
bshum |
gsams: Assuming you mean age in terms of when the material was published... then yeah, probably cataloging is not your friend there. |
| 16:18 |
gsams |
bshum: apologies, yes by publication date indeed |
| 16:18 |
gsams |
I'm getting a lot of garbage no matter the way I try within reports. |
| 16:18 |
gsams |
There is mostly correct information, just a lot of oddities. |
| 16:20 |
Dyrcona |
Yeah, the dates are often messy. |
| 16:20 |
Dyrcona |
strike often, replace with always. |
| 16:21 |
|
nhilton_ joined #evergreen |
| 16:22 |
bshum |
Yep. |
| 16:22 |
gsams |
Dyrcona: indeed, I'll just run with what pulls the best. Currently within the group there are probably somewhere around 80 different botched Date1 variants. |
| 16:23 |
gsams |
Which could easily be worse... |
| 16:28 |
bshum |
Dyrcona++ # "No and no, basically." :D |
| 16:29 |
gsams |
Dyrcona++ #indeed |
| 16:31 |
RoganH |
I feel like there needs to be warning label on the reporter "Dear Librarian Used to Old Proprietary Weeding Solution: This is Both More Powerful and Less User Friendly Than You're Used To. Have a Nice Day." |
| 16:31 |
RoganH |
er, reporting not weeding. I shouldn't glance over at other emails while typing |
| 16:32 |
jeff |
only 40 distinct values (across 2501 records) for this query: select count(*), attrs->'date1' from metabib.record_attr where attrs->'date1' !~ '^[ |u0-9]{4}$' group by 2 order by 2; |
| 16:33 |
jeff |
my favorite may be '197l' -- lowercase l instead of number 1 being an old typewriter convention. |
| 16:37 |
* dbs |
determines that the http 302 redirects for lists are from yandex web crawler. *sigh* |
| 16:38 |
bshum |
mmorgan: I added a new comment with a potential working branch for https://bugs.launchpad.net/evergreen/+bug/1412893/comments/2 |
| 16:38 |
pinesol_green |
Launchpad bug 1412893 in Evergreen "Applying lost and paid status at the wrong time" (affected: 2, heat: 10) [Undecided,Confirmed] |
| 16:39 |
bshum |
mmorgan: If you get time later to try tossing that in some test environment and seeing if it handles the lost&paid situation better, let me know what you can find out. |
| 16:39 |
bshum |
I plan to try it out more when I can get it on a system too. |
| 16:39 |
bshum |
Dyrcona++ # helping me fix my sucky perl |
| 16:42 |
|
mrpeters left #evergreen |
| 16:46 |
mmorgan |
bhum: I will give it a try at some point soon. |
| 16:47 |
mmorgan |
bhsum++ |
| 16:47 |
gsams |
jeff: that pulled 137 distinct values for me |
| 16:48 |
mmorgan |
er, bshum++ |
| 16:48 |
jeff |
@karma bhsum |
| 16:48 |
pinesol_green |
jeff: Karma for "bhsum" has been increased 3 times and decreased 0 times for a total karma of 3. |
| 16:48 |
jeff |
heh. |
| 16:48 |
bshum |
Heh |
| 16:53 |
|
mmorgan1 joined #evergreen |
| 16:54 |
|
Shae joined #evergreen |
| 16:59 |
jeff |
hrm. opac.hold_notify user settings of "email|phone" and "phone:email" |
| 17:01 |
tsbere |
jeff: I think either works. I also think "emailphone" and "phonemail" might result in the same thing, but am less positive about that. |
| 17:03 |
tsbere |
aka, no delimiters get looked for, just the strings "email", "phone", and "sms" |
| 17:04 |
dbs |
Weird. Person just tried adding about 10 different records to lists using a mix of IE and Firefox, and I see a total of 4 requests on the server. WTH. |
| 17:05 |
jeff |
tsbere: yeah, doesn't seem to break, i'm just curious where the variation originated. :-) |
| 17:24 |
|
mmorgan1 left #evergreen |
| 18:12 |
|
nhilton_ joined #evergreen |
| 18:26 |
|
ying joined #evergreen |
| 18:27 |
|
kmlussier joined #evergreen |
| 18:27 |
|
mceraso joined #evergreen |
| 18:28 |
|
bshum joined #evergreen |
| 19:08 |
|
gmcharlt joined #evergreen |
| 19:25 |
|
wsmoak joined #evergreen |
| 19:26 |
wsmoak |
Firefox search widget *and* hold notifications via text message! |
| 19:27 |
wsmoak |
is there a page of release notes for what got added to PINES ? |
| 19:30 |
bshum |
wsmoak: only thing I see is http://pines.georgialibraries.org/news-2015-01-upgradevideo |
| 19:31 |
bshum |
Not sure what else may exist. |
| 19:31 |
bshum |
In theory, they went from some 2.5 to 2.7 |
| 19:32 |
bshum |
So you could also read the release notes for 2.6 and 2.7 from the Evergreen pages and it'd be a close approximation of new things too. |
| 19:33 |
bshum |
Though every site implements their own way and may not carry every new feature. |
| 19:33 |
bshum |
csharp can probably say more, of course ;) |
| 19:38 |
wsmoak |
thanks bshum. I think that covers it. |
| 20:00 |
dbs |
wsmoak: btw, after upgrading to a new version of firefox on a windows machine, it offered a "new search experience" and that seems to align with what you were seeing |
| 20:01 |
wsmoak |
dbs: the missing icon ? |
| 20:02 |
dbs |
yeah. maybe a firefox bug |
| 20:08 |
dbs |
I guess we could add an <Image> element to the opensearch description though |
| 20:16 |
dbs |
http://www.opensearch.org/Specifications/OpenSearch/1.1#The_.22Image.22_element |
| 20:57 |
|
remingtron joined #evergreen |
| 21:01 |
|
jcamins__ joined #evergreen |
| 22:46 |
|
dcook joined #evergreen |
| 22:48 |
|
sbrylander joined #evergreen |
| 23:35 |
|
akilsdonk joined #evergreen |
| 23:40 |
|
artunit_ joined #evergreen |
| 23:40 |
|
dreuther joined #evergreen |
