| Time |
Nick |
Message |
| 03:13 |
|
rri_ joined #evergreen |
| 03:16 |
|
mtj_ joined #evergreen |
| 03:24 |
|
misilot joined #evergreen |
| 05:35 |
|
Mark__T joined #evergreen |
| 07:36 |
|
jboyer-isl joined #evergreen |
| 07:44 |
|
jboyer-isl joined #evergreen |
| 07:46 |
|
rjackson-isl joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 08:16 |
|
kmlussier joined #evergreen |
| 08:26 |
|
mrpeters joined #evergreen |
| 08:34 |
|
akilsdonk joined #evergreen |
| 08:37 |
|
kbeswick joined #evergreen |
| 08:46 |
|
ericar joined #evergreen |
| 09:01 |
|
mmorgan joined #evergreen |
| 09:19 |
|
Mark__T joined #evergreen |
| 09:29 |
|
Mark__T joined #evergreen |
| 09:48 |
|
yboston joined #evergreen |
| 09:57 |
|
senator joined #evergreen |
| 10:00 |
mrpeters |
anyone still using syslog-ng and have a configuration more up to date than the one in the ESIContrib branch? We're having trouble with egstats/gateway logs getting mashed into the osrfsys.$HOUR.log files and it's making a mess of troubleshooting. |
| 10:01 |
bshum |
mrpeters: I never updated syslog-ng to 3, I think we're still using old 2. |
| 10:01 |
mrpeters |
yeah :( they're using 3 in this case |
| 10:01 |
mrpeters |
maybe that is the problem |
| 10:01 |
bshum |
3 is pretty different in the config file, to my recollection. |
| 10:01 |
mrpeters |
its driving me crazy to have to sort through egstats for every minute over 6 servers |
| 10:02 |
bshum |
I think that's why I started switching to rsyslog like the rest of the folks |
| 10:04 |
bshum |
But then I kept an old server around with syslog-ng 2 for central logging for the short-term. I'll get that updated eventually. |
| 10:04 |
bshum |
Sorry I can't be more helpful mrpeters. It's on my long to-do list to work on syslog stuff. |
| 10:06 |
mrpeters |
no worries ben |
| 10:06 |
mrpeters |
i would like to go to rsyslog too, but, not my servers ;) |
| 10:10 |
mrpeters |
is there a way to start just one perl service? for example, opensrf.math? |
| 10:11 |
mrpeters |
ah -s |
| 10:12 |
|
kayals joined #evergreen |
| 10:27 |
|
_bott_ joined #evergreen |
| 10:33 |
|
ericar joined #evergreen |
| 10:40 |
|
robertl_ joined #evergreen |
| 10:44 |
|
dkyle joined #evergreen |
| 10:46 |
|
ElliotFriend joined #evergreen |
| 10:48 |
ElliotFriend |
Hi, All! I have a holds question on behalf of my library: |
| 10:49 |
ElliotFriend |
If someone places a hold on a copy, another patron can check that book out until the copy is physically placed on the holds shelf |
| 10:49 |
ElliotFriend |
is there a way to make the copy unavailable as soon as the hold is placed? For an awful lot of records, we have just one copy. |
| 10:50 |
tsbere |
Not really |
| 10:50 |
bshum |
That doesn't sound very friendly to me. And sounds like it would just lead to folks hitting override at the circ desk anyways. |
| 10:50 |
bshum |
End of the day, the person who grabs the book usually wins. |
| 10:50 |
ElliotFriend |
it's my understanding that this behavior is common in most (if not all) libraries, so I was expecting that |
| 10:51 |
jeff |
At out libraries, item in hand always trumps a hold. |
| 10:51 |
ElliotFriend |
Thanks for the confirmation |
| 10:51 |
jeff |
s/out libraries/our libraries/ |
| 10:51 |
bshum |
I mean, it just seems like it would lead to unhappy patrons. |
| 10:51 |
ElliotFriend |
bshum, it definitely would. But, I don't make the procedure decisions, I just ask the devs :-D |
| 10:51 |
jeff |
Speaking from a personal standpoint, it would seem like bad customer service to deny someone the ability to check out the item that they picked up off of the shelf. |
| 10:52 |
jeff |
I've never gone looking to see if it would be possible to make happen. |
| 10:58 |
jeffdavis |
ElliotFriend: You could probably do it with an action trigger using the hold.capture hook, but you'd probably need to create a new reactor to change the status of the captured item. |
| 10:58 |
jeff |
jeffdavis: i think ElliotFriend's example happens before any hold capture has taken place. |
| 10:59 |
ElliotFriend |
jeff: jeffdavis: their idea was as soon as (or shortly thereafter) the patron clicks "Hold" in the TPAC, the book becomes unavailable for checkout to anyone else |
| 11:00 |
ElliotFriend |
I think jeff said it best, "item in hand always trumps a hold" |
| 11:00 |
* jeffdavis |
mutters something about not having any coffee |
| 11:01 |
jeffdavis |
I guess you'd need to change the item status when the copy is targeted then? |
| 11:01 |
jeffdavis |
That's probably a bad idea since items can be un-targeted and you'd want to revert the status in that case. |
| 11:03 |
jeffdavis |
So, could be done if you're willing to modify the hold targeter or create a new action trigger hook + reactor, but doesn't fit well with EG's hold model. |
| 11:03 |
|
RoganH joined #evergreen |
| 11:04 |
jeff |
I suspect that additional checks would need to be added to OpenILS::Application::Circ::Circulator -- likely in handle_checkout_holds where we currently re-target the hold in question, if the copy being checked out is the "current copy" for another patron's hold. |
| 11:04 |
jeff |
But again, I'd recommend against it for reasons of customer service. :-) |
| 11:05 |
phasefx |
if you want to edit the Perl, you could move the lines at the top of run_renew_permit that throw a COPY_NEEDED_FOR_HOLD event to right before run_renew_permit gets called |
| 11:05 |
jeff |
(for one thing, it would be silly in a lot of environments, where another copy on the shelf might just as easily fill the hold) -- which isn't ElliotFriend's situation, but still. :-) |
| 11:06 |
phasefx |
at least I think that would work |
| 11:06 |
phasefx |
no, needs to go elsewhere |
| 11:07 |
phasefx |
duplicate those lines and throw in front of ->do_checkin() in Circulate.pm maybe. I wouldn't recommend any of this really :) |
| 11:07 |
jeff |
purely a thought exercise. i was reading OpenILS::Application::Circ::Circulator last night on my tablet. |
| 11:07 |
jeff |
took a while to clone the repo, but i found a git client that makes code reading somewhat reasonable. |
| 11:08 |
jeff |
better than the "download individual files and open them in an app that does syntax hilighting. |
| 11:08 |
jeff |
" |
| 11:08 |
jeff |
option |
| 11:08 |
|
ericar joined #evergreen |
| 11:10 |
ElliotFriend |
awesome thought-process, but I'm 90% confident I would do more damage than good by modifying anything in Perl haha |
| 11:11 |
robertl_ |
Hi. Anyone knows how long it takes for beta release before it becomes stable? |
| 11:12 |
RoganH |
robertl_: as soon as bugs are squashed |
| 11:13 |
RoganH |
The beta blocker list is pretty small, then we get RC. How long something stays at RC depends partly on how much testing it gets. |
| 11:22 |
robertl_ |
thanks Rogan |
| 11:50 |
|
Dyrcona joined #evergreen |
| 11:52 |
Dyrcona |
pinesol_green: Any laters for me? |
| 11:52 |
pinesol_green |
Dyrcona: (any [<channel>] [--user <name>] [<nick>]) -- Returns the last time <nick> was seen and what <nick> was last seen doing. This includes any form of activity, instead of just PRIVMSGs. If <nick> isn't specified, returns the last activity seen in <channel>. If --user is specified, looks up name in the user database and returns the last time user was active in <channel>. <channel> is only (1 more message) |
| 11:52 |
pinesol_green |
Dyrcona: I am only a bot, please don't think I'm intelligent :) |
| 11:52 |
Dyrcona |
heh. |
| 11:52 |
Dyrcona |
any Dyrcona |
| 11:52 |
Dyrcona |
@any Dyrcona |
| 11:52 |
pinesol_green |
Dyrcona: Dyrcona was last seen in #evergreen 5 seconds ago: <Dyrcona> any Dyrcona |
| 11:54 |
Dyrcona |
Heh. Made me think of this: http://www.mst3kinfo.com/ward_e/Bit610.html |
| 11:58 |
* jeff |
attempts to search launchpad |
| 11:58 |
jeff |
Looking to see if we have any "auto-generate usernames" wishlist tickets yet. |
| 12:00 |
|
jdouma joined #evergreen |
| 12:00 |
jeff |
looks like no, but bug 1200735 will likely help. |
| 12:00 |
pinesol_green |
Launchpad bug 1200735 in Evergreen "patron search by user name can be slow" (affected: 1, heat: 6) [Undecided,Fix committed] https://launchpad.net/bugs/1200735 |
| 12:05 |
|
krvmga joined #evergreen |
| 12:07 |
tsbere |
jeff: At some point I hope to have a "usernames should be nullable and default to null" change, if only because people get *really* confused between barcode and username when an old barcode is in the username field. |
| 12:07 |
jeff |
Dyrcona: i like the look of your billing enhancements. We might need/want to backport them to 2.5 here. |
| 12:07 |
jeff |
tsbere: yeah. |
| 12:07 |
jeff |
tsbere: and i can see benefit to having nullable and default to something at least somewhat memorable, possibly based on library settings. |
| 12:08 |
jeff |
tsbere: first initial + last name + tie breaker |
| 12:08 |
jeff |
or somesuch. |
| 12:08 |
jeff |
i've mostly given up on the idea of making them able to be email addresses... since we've so many accounts that have the same email address. |
| 12:09 |
jeff |
but i would like them to be case insensitive still. THAT'S not a fun upgrade path to deal with. |
| 12:10 |
|
akilsdonk joined #evergreen |
| 12:11 |
Dyrcona |
jeff: There is a really crufty WIP branch: http://git.mvlcstaff.org/?p=jason/ILS.git;a=shortlog;h=refs/heads/Bill_01-Conditional-Negative-Balances |
| 12:11 |
Dyrcona |
I just loaded it this weekend to look at it this week to make sure that the code basically works. |
| 12:12 |
krvmga |
i added identifier|music_number and identifier|gov_doc_number to the options list in numeric.tt2 for advanced search |
| 12:12 |
krvmga |
the music number search works fine; the government document number not |
| 12:12 |
krvmga |
any thoughts? |
| 12:12 |
Dyrcona |
Ah, SUDOC.... Maybe he's on furlough, too? |
| 12:13 |
krvmga |
btw, i can search for a government document number as a keyword and be successful. |
| 12:13 |
kmlussier |
krvmga: That's a local index? |
| 12:13 |
eeevil |
krvmga: depends on the data, and the normalizers, and the config.metabib_field setup |
| 12:13 |
eeevil |
also |
| 12:13 |
eeevil |
Dyrcona++ |
| 12:13 |
eeevil |
heh |
| 12:14 |
kmlussier |
krvmga: My initial thought is that the index was only created as part of the keyword class? |
| 12:14 |
ldwhalen |
If I want to add a constant value to Evergreen should I add it to OpenILS/Const.pm? |
| 12:15 |
ldwhalen |
I have added one for a maximum limit value for SQL queries |
| 12:15 |
ldwhalen |
and I want to add another to represent the MFHD subfields. |
| 12:15 |
tsbere |
jeff: Case insensitive sounds nice too....but who do you give the username to on conflict.....PITA. |
| 12:15 |
tsbere |
too many "would be really nice if..." on the username front |
| 12:15 |
Dyrcona |
ldwhalen: I was actually looking at Const.pm this weekend and thinking that it needs more constants, many are missing. |
| 12:16 |
Dyrcona |
ldwhalen: To answer your question, I give a tentative yes. I say put it in there, share the branch and see what others think of your specific case. |
| 12:16 |
ldwhalen |
Dyrcona: these are values that are present in the current code base, but that I am now using elsewhere as well. |
| 12:16 |
krvmga |
kmlussier: music_number and gov_doc_number have the same setup in config.metabib_field |
| 12:16 |
eeevil |
ldwhalen: OpenILS/Utils/MFHD.pm (or a submodule) might be a better place for MFHD stuff |
| 12:16 |
tsbere |
jeff: "Default username to email address" might not be a bad OU setting, in lieu of "default to barcode". or a "allow to be null and don't default it at all" which is my personal preference. |
| 12:17 |
* Dyrcona |
is off to pick up his car from the shop. |
| 12:17 |
ldwhalen |
eeevil: Ok, I will take a look at that. |
| 12:17 |
jeff |
tsbere: i'd also like the patron interfaces to offer to set a username when the username is barcode (or null, in future) |
| 12:17 |
kmlussier |
krvmga: What value do you have in the class field? |
| 12:18 |
tsbere |
jeff: As in "on login"? |
| 12:18 |
krvmga |
kmlussier: identifier |
| 12:18 |
krvmga |
for both |
| 12:18 |
* tsbere |
believes that you can already say "if it looks like a barcode let them change it, otherwise don't" |
| 12:18 |
jeff |
tsbere: right, or similar. |
| 12:18 |
jeff |
tsbere: yeah, we don't use that option. :-) |
| 12:18 |
jeff |
tsbere: we're happy to allow multiple changes of usrname. |
| 12:19 |
ldwhalen |
Dyrcona: I will look at MFHD.pm and see if it works for my situation. I have a number of commits that I need to redo for the community |
| 12:19 |
ldwhalen |
but I will post these as soon as I can |
| 12:19 |
jeff |
krvmga: if one or both of those indexes are local to you, and newly added, have you reingested records so that the fields are actually indexed? |
| 12:19 |
krvmga |
jeff: thx for the thought. they're not newly added. |
| 12:20 |
jeff |
krvmga: just checking the usual suspects. :-) |
| 12:20 |
kmlussier |
krvmga: I would look up the record in metabib.identifier_field_entry to see how the gov doc number is being indexed. |
| 12:20 |
krvmga |
jeff: :) |
| 12:20 |
jeff |
krvmga: do you have entries in -- yeah, where kmlussier is headed. |
| 12:20 |
krvmga |
kmlussier: i'll check. |
| 12:25 |
krvmga |
bbl |
| 12:38 |
|
ericar joined #evergreen |
| 12:42 |
dbwells |
grabbing 0839 |
| 12:46 |
pinesol_green |
[evergreen|Mike Rylander] Capture all alternative titles - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c08953a> |
| 12:46 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Replace inappropriate browse reingest with ... - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ef7cefb> |
| 12:46 |
pinesol_green |
[evergreen|Dan Wells] Stamping upgrade 0839: alternative title index fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b8ec73d> |
| 12:47 |
jeff |
dbwells++ |
| 12:48 |
* Dyrcona |
is back |
| 12:52 |
jeff |
bah. pound appears to be unsuitable for use in environments where your local interface IP is not your public-facing IP, unless you go down the path of split dns. |
| 12:53 |
jeff |
perhaps exclusively where the local interface IP can change. |
| 12:53 |
jeff |
and another option is to update pound.cfg dynamically. |
| 12:59 |
jeff |
oh that's weird. re-test server behavior seems to skip/cache the version check. |
| 13:11 |
* tsbere |
hates library vendors that refuse to change how they send email because it worked the way they are when they started decades ago... |
| 13:16 |
Dyrcona |
@later tell gmcharlt Would you be interested in records that appear to OK in UTF-8 but cause warnings when converted to MARC-8 with MARC::Charset? |
| 13:16 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 13:16 |
gmcharlt |
Dyrcona: yes |
| 13:16 |
gmcharlt |
for my sins, yes |
| 13:16 |
Dyrcona |
OK. |
| 13:16 |
Dyrcona |
It will take me a day or two, but I'll send you the UTF-8 records. |
| 13:17 |
|
smyers_ joined #evergreen |
| 13:32 |
Dyrcona |
Ah, our old friend, u with a hook is back. I should make sure that the computer where I'm doing this has the latest MARC::Charset, but I'm pretty sure it does. |
| 13:37 |
senator |
ư |
| 13:38 |
eeevil |
I hate ư |
| 13:38 |
senator |
heh |
| 13:41 |
gmcharlt |
ư should be dealt with the same way Captain Hook was |
| 13:41 |
gmcharlt |
nom-nom-nom |
| 13:51 |
senator |
hah |
| 13:53 |
paxed |
hmmm... so, me, alongside with Kivilahtio, have been asked to make an objective choice whether our project should use Eg or Koha. |
| 13:54 |
paxed |
just lovely. |
| 13:56 |
RoganH |
Is this the updated version of King Solomon and the baby? Can you just cut the source codes in half? |
| 13:56 |
paxed |
hey, if i could, i would, but we'd end up with the frankenstein's monster ... |
| 13:57 |
RoganH |
It would be like running (rest of commented redacted on behalf of Rogan's lawyers who remind him not to mention certain vendors in public). |
| 13:58 |
paxed |
i've been trying to be as objective as i can (considering i'd "lose" a year's worth of work), but i know kivilahtio's in love. |
| 14:00 |
ldwhalen |
If I want to access the Staff Client's ws_ou in the TPAC, is there a ctx object for that? |
| 14:00 |
ldwhalen |
I have added ctx->{ws_ou} from cts->{user}->ws_ou |
| 14:01 |
ldwhalen |
For some reason ctx.user.ws_ou will not give me a value in the TPAC |
| 14:01 |
ldwhalen |
s/cts/ctx/ |
| 14:02 |
paxed |
i wonder if that's connected with bug 1201820? |
| 14:02 |
pinesol_green |
Launchpad bug 1201820 in Evergreen "ctx.user.home_ou is not consistent between OPAC and staff client" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1201820 |
| 14:05 |
ldwhalen |
paxed: is home_ou synonymous for ws_ou? |
| 14:05 |
paxed |
don't know, and it's too late for me to go and start looking for it. (9 pm for me) |
| 14:06 |
|
smyers_ joined #evergreen |
| 14:06 |
Dyrcona |
ldwhalen: No. It isn't. |
| 14:06 |
ldwhalen |
np, I have not looked into why ctx->{user}->ws_ou does not work. I think the user part is getting lost some where. |
| 14:06 |
ldwhalen |
It is defined in the search results but not in the record view. |
| 14:06 |
Dyrcona |
ldwhalen: home_ou should come from the actor.usr entry. |
| 14:06 |
ldwhalen |
Dyrcona: thank you |
| 14:07 |
Dyrcona |
ldwhalen: ws_ou comes from actor.workstation entry of the worksration staff specified when loggin in. |
| 14:08 |
ldwhalen |
to be specific {user}->ws_ou is defined when at eg/home/results but not at eg/home/record |
| 14:09 |
ldwhalen |
s/home/opac/ |
| 14:10 |
Dyrcona |
ldwhalen: I'd have to look at the code. |
| 14:11 |
ldwhalen |
Dyrcona: I will get around to it eventually, for now I am going to keep the ctx-{ws_ou} addition. |
| 14:12 |
|
dMiller_ joined #evergreen |
| 14:21 |
Dyrcona |
ldwhalen: Off the top of my head ctx->{ws_ou} should only be set from the staff client. In the OPAC with a patron logged in, it should be undefined. |
| 14:22 |
ldwhalen |
Dyrcona: thanks, I just caught that and fixed it with a check for {is_staff}. I appreciate the concern for my code though, thank you. |
| 14:23 |
Dyrcona |
ldwhalen: It ends up being everyone else's code at some point. :) |
| 14:23 |
Dyrcona |
Which reminds me.... |
| 14:23 |
ldwhalen |
:) |
| 14:23 |
Dyrcona |
There's a big fix that I want to push. |
| 14:44 |
Dyrcona |
big? no, bug! |
| 14:44 |
Dyrcona |
eeevil: As for crossing the streams, I've gone through a total protonic reversal. |
| 14:46 |
Dyrcona |
kmlussier: What version is NOBLE on? |
| 14:47 |
kmlussier |
Dyrcona: 2.3. I can't remember which point release but mmorgan should know. |
| 14:47 |
Dyrcona |
Thanks! That's all I needed. |
| 14:49 |
Dyrcona |
grabbing 0840. |
| 14:50 |
|
Bmagic007 joined #evergreen |
| 14:51 |
mmorgan |
Here I am! NOBLE's on 2.3.7 in production |
| 15:01 |
pinesol_green |
[evergreen|Garry Collum] lp1193487 Circulation Policy Column Picker not saving configuration. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ee6318> |
| 15:01 |
pinesol_green |
[evergreen|Jason Stephenson] Wrap upgrade script for 0840 circulation column picker. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=741c114> |
| 15:01 |
Dyrcona |
There is no 2_5_rc branch, so I'm assuming that if something goes into master, it will make it into 2_5_rc? |
| 15:04 |
berick |
hm, yeah, I would expect rel_2_5 to have been created at beta1, since that's the feature cut off |
| 15:05 |
berick |
as in, origin/rel_2_5 (not a tag) |
| 15:05 |
berick |
well, tags, are fine, i just mean.. ah, you know what I mean |
| 15:06 |
csharp |
mmorgan: congrats! |
| 15:06 |
csharp |
oh - didn't read far enough up |
| 15:06 |
Dyrcona |
heh. |
| 15:06 |
csharp |
that looked like an announcement ;-) |
| 15:06 |
* csharp |
blushes |
| 15:06 |
Dyrcona |
:) |
| 15:07 |
csharp |
well congratulations anyway! |
| 15:07 |
* csharp |
*hiccup* |
| 15:07 |
kmlussier |
LOL |
| 15:07 |
collum |
Yay. Thanks Dyrcona. I got a patch in. |
| 15:08 |
* csharp |
has been fuzzyheaded all day - fighting a lingering cold |
| 15:08 |
gmcharlt |
csharp: no worries -- I read it the same way initially |
| 15:11 |
kmlussier |
collum++ |
| 15:12 |
Dyrcona |
collum++ |
| 15:13 |
* kmlussier |
wanders off to add collum to http://wiki.evergreen-ils.org/doku.php?id=contributing:contributors&s[]=contributors |
| 15:13 |
gmcharlt |
collum++ |
| 15:15 |
Dyrcona |
Hope I didn't step on backporting 0839, or is it for 2.5+ only? |
| 15:18 |
berick |
@later tell dbwells since we're in beta now, can we get an origin/rel_2_5 branch so master can remain open for business? |
| 15:18 |
pinesol_green |
berick: The operation succeeded. |
| 15:19 |
dbwells |
berick: I think in the past we have deliberately closed master until final release to encourage more testing and less new stuff. Maybe I am mistaken, though. |
| 15:19 |
dbwells |
berick: And by closed, I mean kept for bugfixes only. |
| 15:22 |
kmlussier |
It's been a while since I updated that page. I also added fparks_ and yboston to http://wiki.evergreen-ils.org/doku.php?id=contributing:contributors. fparks++ yboston++ |
| 15:22 |
kmlussier |
new_contributors++ |
| 15:22 |
berick |
hm, i think that's great as a policy -- let's focus on bug fixes - i'm not fond of enforcing it in that manner, though |
| 15:22 |
berick |
something is going to seep in eventually that way |
| 15:23 |
dbwells |
berick: I am simply stating how I thought we did it in the past, but it isn't like we have a long and rich tradition here. |
| 15:24 |
berick |
i think we did that once. i could be wrong |
| 15:26 |
berick |
i'll raise it at the dev mtg |
| 15:27 |
bshum |
fwiw, I remember having a frozen master during at least one of the recent releases too. |
| 15:29 |
remingtron |
kmlussier: you can grab a list of contributors using git |
| 15:29 |
remingtron |
git log --since=10/8/2012 --before=10/8/2013 --pretty=format:"%an" | sort -u |
| 15:29 |
|
roses joined #evergreen |
| 15:29 |
remingtron |
that will show author names for commits in the last year |
| 15:30 |
kmlussier |
remingtron: Thanks! I usually scan the new contributors on ohloh to verify that new people are there. |
| 15:31 |
remingtron |
ah, same idea I guess |
| 15:31 |
remingtron |
ohloh++ |
| 15:32 |
kmlussier |
I like the fact that you can sort by first commit, although apparently that's not always the best method for finding people. yboston's first commit was a doc commit from a long time ago. |
| 15:33 |
roses |
I'm having a sys admin problem with the user not being able to "cleanly" delete a patron. Could someone share with me what permissions the sys admin should have to be able to delete a patron without errors being thrown? |
| 15:34 |
dbwells |
berick: Are you fine with waiting for the dev meeting? Like I said, I am not trying to make a new policy (and haven't even given it much thought), I think I am just following what was done for 2.4 (which is frankly as far back as I can remember). |
| 15:36 |
bshum |
roses: It usually dpeneds on the errors (they usually explain what permission is lacking and can be helpful) |
| 15:36 |
bshum |
*depends |
| 15:36 |
berick |
dbwells: yeah, that's fine, I'm not trying to do anything in particular. Dyrcona's question from 15:01 made me itchy, though. |
| 15:36 |
bshum |
I don't think giving the sys admin blanket deletion is always wise, personally. |
| 15:37 |
dbwells |
berick: ah, ok, I didn't see that |
| 15:38 |
RoganH |
roses: for what it's worth we never delete patrons in SCLENDS |
| 15:38 |
roses |
bshum: It starts with an update_user error and I went in and made sure the particular library sys admin had that right and then I made sure they had delete_user rights - |
| 15:38 |
RoganH |
roses: we may scrub a record of identifying data but leave the record to preserve dependencies |
| 15:38 |
roses |
RoganH: Never. Why did you make that decision? |
| 15:39 |
RoganH |
roses: There are a lot of connections between records, bills, etc... |
| 15:39 |
bshum |
roses: With an update_user error, I would imagine that maybe the permission level is too low. Or perhaps that sys admin doesn't have all the proper working library org units assigned to them to make changes. |
| 15:39 |
roses |
RoganH: I think it's those dependencies that are creating the errors. Again, if the patron is "clean" it's not a problem. |
| 15:39 |
RoganH |
roses: although you can delete a record in a way that's clean to the db (ie not break anything) that doesn't mean it won't play havoc long term with financial reports and stuff |
| 15:39 |
RoganH |
roses: I try to make my auditors happy :) |
| 15:39 |
Dyrcona |
Hardly anything in evergreen is actually deleted when you say delete. |
| 15:40 |
bshum |
Like it might be set to the library level, but it should be update_user of the consortial level |
| 15:40 |
bshum |
Or it could be that they need the group-application-whatever-thing-permission-i-can-never-memorize... |
| 15:41 |
bshum |
RoganH: That's a very logical explanation for not deleting users as any and I will actually be passing this note off to folks here for consideration. |
| 15:41 |
bshum |
Crazy auditing. |
| 15:41 |
roses |
bshum: I had thought about the consortial level - but that gave me heartburn to think they would delete somebody elses user. I'm thinking about Rogan's idea. |
| 15:42 |
bshum |
roses: Sounds like the kind of hell I used to wrestle with. |
| 15:42 |
bshum |
I'm very "oh, you want the flaming baton? Here it is." now. |
| 15:42 |
roses |
bshum: So what was your answer to getting out of "looping" hell. |
| 15:43 |
Dyrcona |
heh. |
| 15:43 |
Dyrcona |
Our directors say, "We want our staff to be able to do everything!" |
| 15:43 |
Dyrcona |
I say, "Um, no you don't. You really, really don't." |
| 15:43 |
bshum |
roses: I'm fairly sure that we also don't often give people the power to obliterate just any user. |
| 15:44 |
bshum |
Or at least we definitely stopped that after a staff member deleted their own Evergreen login once. |
| 15:44 |
roses |
Dyrcona: I'm going to steal that line and tell them that!! |
| 15:44 |
Dyrcona |
Crazy staff.... |
| 15:44 |
bshum |
"I don't recognize this account, I'm gonna delete it." |
| 15:44 |
roses |
bshum: sounds like something i would do to myself while "testing" |
| 15:44 |
jeff |
All disclaimers about deleting users aside, to answer the original question, a staff user deleting another user will need DELETE_USER at the target user's home_ou, and may also need ACTOR_USER_DELETE_OPEN_XACTS.override at the target user's home_ou as well. You'll also need the same group application permissions that you would need to be able to edit the user in the first place -- for a stock install, that means you'd need group_application.user.patron fo |
| 15:45 |
jeff |
oh, and that truncated. if someone would kindly tell me where, i can re-send. |
| 15:45 |
bshum |
group_application.user.patron for... |
| 15:45 |
jeff |
for a target user in the Patrons group |
| 15:45 |
jeff |
bshum++ |
| 15:46 |
bshum |
jeff++ for finding the real answer to the question :) |
| 15:46 |
jeff |
perhaps if i had been less verbose... "may also need... as well" |
| 15:46 |
bshum |
group_application.user.* is the thing I always forget. |
| 15:46 |
dbwells |
berick (or bshum, senator, eeevil, Dyrcona, jeff, gmcharlt, phasefx, or tsbere (or anyone else I missed)): P.S. If anyone wants 2.5 RC to come sooner, you could maybe (pretty please) check out bug #1235497. It will resolve both remaining blockers. |
| 15:46 |
pinesol_green |
Launchpad bug 1235497 in Evergreen "Title browse has display and sorting issues" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1235497 |
| 15:47 |
* senator |
will give it a try later this afternoon if it's still needed then |
| 15:49 |
Dyrcona |
If kmlussier will have a look at it, I could load that branch in a few minutes. |
| 15:50 |
Dyrcona |
Which reminds me that I should run the inter-authority linking script on my dev server for better browse anyway. |
| 15:50 |
kmlussier |
Dyrcona: I can look at it. I wasn't sure if it would require one of those long reingests, though. |
| 15:50 |
roses |
bshum++,RoganH++,jeff++,Dyrcona: Thanks. You've given me something to think about (head exploding thoughts) |
| 15:51 |
* bshum |
groans inwardly at the words "long reingests" |
| 15:51 |
bshum |
:( |
| 15:51 |
Dyrcona |
kmlussier: Those reingests are back down to 5 hours on my development VM. Dunno what was making them take days before. |
| 15:51 |
kmlussier |
5 hours sounds like a big improvement! :) |
| 15:54 |
Dyrcona |
dbwells: Does that branch require a reingest? I think it might, but there doesn't seem to be on in the upgrade scripts. |
| 15:54 |
Dyrcona |
s/(on)/$1e/ |
| 15:56 |
bshum |
Reingest seems required based on the nature of the upgrade script |
| 15:58 |
Dyrcona |
Yeah, that is what I thought, thanks, bshum. |
| 15:58 |
Dyrcona |
I'll install this and start the reingest. |
| 15:58 |
dbwells |
Dyrcona: yes, reingest is needed. |
| 15:58 |
bshum |
But as the saying goes, the only folks who need the separate reingest would likely be me and you. |
| 15:58 |
bshum |
Or anyone's dev machines. |
| 15:58 |
* Dyrcona |
has a script for that. |
| 15:58 |
Dyrcona |
:) |
| 16:03 |
Dyrcona |
One thing I've noticed right off the bat: The upgrade script should probably lose the id on the metabib.field_entry insert. It causes a duplicate key error with our database and added fields. |
| 16:04 |
dbwells |
Dyrcona: would you like me to add a reingest step to the end of that upgrade? I was already thinking ahead to the big 2.5 upgrade script which already has it for other reasons, but your right, it should probably at least have a post commit reingest of some sort. |
| 16:06 |
|
dMiller__ joined #evergreen |
| 16:06 |
bshum |
Dyrcona: Eh... I'm not sure I agree with that personally. By default, people shouldn't have metabib entries in the way of the stock indexes (like the one being created) |
| 16:07 |
bshum |
Or at least, they should have been moved up to 100+ at some point during the regular course of the upgrade process. |
| 16:07 |
bshum |
But maybe I'm sticking too hard to the ID being important here, which it doesn't always have to be. |
| 16:07 |
* bshum |
feels like there's a bug about this somewhere |
| 16:07 |
Dyrcona |
bshum: In the case of metabib.field_entry, I don't think the id is used anywhere. |
| 16:08 |
Dyrcona |
bshum: Since when do you or I do the normal upgrade process? :) |
| 16:08 |
dbwells |
Dyrcona: It's possible that your ID 31 is remnant of the old browse index, which was added to the dev branch then removed, but never put in any upgrade scripts. |
| 16:08 |
* Dyrcona |
has a look. |
| 16:08 |
bshum |
Ah, that's possible. |
| 16:08 |
bshum |
Stupid 31. |
| 16:08 |
bshum |
:) |
| 16:09 |
dbwells |
And by 'dev branch', I mean senator's browse dev branch. |
| 16:09 |
Dyrcona |
Yar! |
| 16:09 |
Dyrcona |
Helps to get the table name correct: config.metabib_field. |
| 16:10 |
Dyrcona |
dbwells: I've blown the database and the vm out a few times since then, so I don't think so. |
| 16:10 |
dbwells |
Dyrcona: well, it was in master until just a few days ago. |
| 16:11 |
dbwells |
It has a confusing history at this point :) |
| 16:13 |
Dyrcona |
Nope, our 31 is LCCN, so we've added something long ago. |
| 16:14 |
Dyrcona |
Actually, I think I know where and when. |
| 16:15 |
Dyrcona |
Turns out, that no, that wasn't where we did it. |
| 16:15 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1097399 |
| 16:15 |
pinesol_green |
Launchpad bug 1097399 in Evergreen 2.4 "Reserve room for system config.metabib_field values" (affected: 4, heat: 24) [Medium,Confirmed] |
| 16:16 |
bshum |
I knew it existed somewhere |
| 16:17 |
dbwells |
bshum: very interesting, so it isn't in yet. Bummer. Same problems, different day :) |
| 16:18 |
bshum |
Dyrcona: Fwiw, my test system that I setup last Saturday only goes to id 30. With 30 being LCCN, so something is awry in there. |
| 16:19 |
bshum |
dbwells: Yeah, I think it was covered in an upgrade SQL during the 2.0 era. |
| 16:19 |
bshum |
dbwells: So folks who upgraded in that time were covered, but folks who went to Evergreen or always were on master were broken by the lack of proper sequencing. |
| 16:21 |
bshum |
dbwells: I'm curious about something (which I guess I would see if I did apply the branch), but... |
| 16:21 |
dbwells |
bshum: you must be right, because our custom indexes start at 101. |
| 16:21 |
bshum |
dbwells: What should the title data look differently between browse vs. regular? |
| 16:21 |
bshum |
*how should |
| 16:21 |
bshum |
Just getting an example to see it's acting as expected. |
| 16:22 |
Dyrcona |
Bingo! |
| 16:23 |
Dyrcona |
We have 28 "all_authors" |
| 16:23 |
bshum |
dbwells: Yeah it's in the 1.6.1-2.0 upgrade script. |
| 16:23 |
Dyrcona |
We were never on Evergreen that long ago. |
| 16:24 |
Dyrcona |
If we're reserving the bottom 100 for system use, then the sequence should be set to 100 in 950.data.seed.values or wherever. |
| 16:25 |
bshum |
Dyrcona: Yeah, the bug I linked to has a branch you created to do that ;) |
| 16:25 |
dbwells |
bshum: the bigger issue it fixes (which is why it is a blocker) is that the non-filing stuff was ending up in the sort_value in metabib.browse_entry. |
| 16:26 |
dbwells |
Dyrcona: so, you agree with yourself from 5 months ago, that's good :) http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=95251643c7a60945f50b30be7e328ecbcae38cd6 |
| 16:26 |
Dyrcona |
I can still test it, though. |
| 16:28 |
Dyrcona |
That's amazing. These days I'm lucky if I agree with myself from 5 minutes ago. |
| 16:28 |
|
Bmagic joined #evergreen |
| 16:28 |
dbwells |
:) |
| 16:29 |
bshum |
Ha, the comments in 1.6.1-2.0 upgrade sql where they bump to 100+ for custom indexes amuse me. |
| 16:29 |
bshum |
"I'm throwing my hands up in surrender" classic. |
| 16:30 |
Dyrcona |
That's the trouble with numeric ids and sequence fields in general. |
| 16:30 |
Dyrcona |
IMHO, you should never assume anything about a field's id. That's kind of the point about sequence/serial fields. They start at 1 and go up. |
| 16:31 |
Dyrcona |
Having reserved ranges is a sort of a kludge. |
| 16:31 |
jboyer-isl |
Hey, let's move everything to UUIDs! :D |
| 16:31 |
Dyrcona |
I think I'll fix my ids before doing the ingest. |
| 16:31 |
jboyer-isl |
And with that, I'm, out. |
| 16:31 |
Dyrcona |
heh. |
| 16:37 |
dbwells |
Dyrcona: I agree that fixed IDs are a kludge, but I think the main point it to separate 'ours' from 'theirs' (devs and end-users). It's horribly fragile, but at least it breaks in obvious and usually reversible ways. |
| 16:37 |
|
dconnor joined #evergreen |
| 16:38 |
|
dconnor joined #evergreen |
| 16:40 |
|
dconnor joined #evergreen |
| 16:41 |
* Dyrcona |
alters the foreign key constraints on config.metabib_field to all have on update cascade. |
| 16:41 |
Dyrcona |
some do, some don't. |
| 16:44 |
|
smyers_ joined #evergreen |
| 16:45 |
dbwells |
bshum: did my change explanation make sense? If you do something like "select * from metabib.browse_entry where value like 'The%';", you should generally no longer see 'the' in the sort_value (for titles at least). |
| 16:45 |
|
sseng_ joined #evergreen |
| 16:46 |
bshum |
dbwells: That helps, thanks! Sorry, I got distracted reminiscing about the old days. |
| 16:47 |
|
sseng__ joined #evergreen |
| 16:47 |
|
smyers_ joined #evergreen |
| 16:47 |
dbwells |
bshum: the second (more minor) change is that trailing punctuation for titles should be gone now from the title browse display (especially '/'). |
| 16:47 |
|
dconnor joined #evergreen |
| 16:48 |
|
smyers_ joined #evergreen |
| 16:51 |
|
dconnor joined #evergreen |
| 16:52 |
|
dconnor joined #evergreen |
| 16:53 |
dbwells |
bshum: Dyrcona: one thing I should also point out if you are watching the DB while testing is that metabib.browse_entry builds up dead rows. I don't think any code ever deletes them. I intend to open that as a separate bug, but it practice, I don't think it is a big deal. |
| 16:53 |
|
dMiller_ joined #evergreen |
| 16:56 |
mrpeters |
any syslog-ng experts left? i know most have switched to rsyslog but I am pulling my hair out trying to figure out why gateway and eg-stats logs are going to both their own log files, AND to osrfsys.$HOUR.log |
| 16:56 |
mrpeters |
its making troubleshooting a nightmare |
| 16:58 |
mrpeters |
syslog-ng.conf --- http://pastebin.com/7V8e246q |
| 17:02 |
bshum |
mrpeters: My gut feeling without looking too closely is likely that the content is being put into the various local# and the filters aren't getting everything. |
| 17:02 |
|
sseng joined #evergreen |
| 17:03 |
bshum |
And thus things get shown in more than one storage and thus printed out into the log files. |
| 17:05 |
|
dconnor joined #evergreen |
| 17:05 |
bshum |
Are you using any special log shipping? Like multiple hosts to a single store? |
| 17:05 |
bshum |
Or is this syslog-ng.conf from a single server |
| 17:05 |
mrpeters |
this is the config from the logger server |
| 17:05 |
mrpeters |
multiple hosts ship logs to it |
| 17:05 |
mrpeters |
i think you're right...all that stuff is getting pushed to local0 and not getting filtered out right for osrfsys.$HOUR.log |
| 17:06 |
mrpeters |
i wish i could just give it a regex or something and say if it looks like this don't log it to osrfsys$hour.log |
| 17:06 |
mrpeters |
i thought thats what the filters did...but apparently not |
| 17:06 |
mrpeters |
for example -- filter f_eg_sip { match("acs-server"); }; |
| 17:06 |
mrpeters |
filter f_egstats { match("eg-stats") and not match("CRON"); }; |
| 17:07 |
|
misilot joined #evergreen |
| 17:08 |
bshum |
Note that in syslog-ng version 2.1 and earlier, the match() filter was applied only to the text of the message, excluding the headers. This functionality has been moved to the message() filter. |
| 17:08 |
bshum |
http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/en/syslog-ng-ose-v3.3-guide-admin-en/html/reference_filters.html |
| 17:08 |
bshum |
mrpeters: See above --^ |
| 17:08 |
Dyrcona |
kmlussier: Looks like this won't be ready for tomorrow. |
| 17:08 |
bshum |
Looks like match() may not do what it used to do in 2 vs. 3. |
| 17:08 |
mrpeters |
ah damn, thanks ben |
| 17:08 |
mrpeters |
this helps a lot |
| 17:08 |
Dyrcona |
I have to drop about 12 constraints and recreate them with on update cascade and on delete cascade. |
| 17:09 |
mrpeters |
that totally explains why the config works on another system thats on an earlier version of syslog |
| 17:09 |
Dyrcona |
Some have the latter, but most have neither. |
| 17:09 |
Dyrcona |
:( |
| 17:09 |
kmlussier |
Dyrcona: OK, well thanks for the attempt. :) |
| 17:09 |
* mrpeters |
now debates time investment vs switching them to rsyslog versus fixing syslog-ng |
| 17:13 |
Dyrcona |
kmlussier: Or maybe it will. A little regexp magic goes a long way. |
| 17:14 |
bshum |
dbwells: Interesting.... on the concerto test dataset from clean to running the reingest after applying the patch I do notice there are extra rows in metabib.browse_entry that don't appear in the metabib.browse_entry_def_map |
| 17:15 |
bshum |
I should have checked right before I ran it... doh |
| 17:16 |
dbwells |
bshum: right, those are the old rows which no longer apply. It will need a fix, but since those rows are likely to build up very slowly in real life, I don't want to block RC for it. |
| 17:16 |
bshum |
"slowly" |
| 17:16 |
* bshum |
goes to try his query in production for kicks :) |
| 17:17 |
|
dconnor joined #evergreen |
| 17:19 |
|
mmorgan left #evergreen |
| 17:21 |
bshum |
Oh so I guess it's not that crazy, just 6619 results. |
| 17:22 |
|
gsams joined #evergreen |
| 17:27 |
dbwells |
bshum: is that checking both def_map and simple_heading_map? Just curious. |
| 17:27 |
bshum |
Hmm, no, I was just checking def_map |
| 17:27 |
bshum |
I can look at simple_heading_map too now that you mention it. |
| 17:28 |
dbwells |
bshum: I did this: |
| 17:28 |
dbwells |
select * from metabib.browse_entry mbe LEFT JOIN metabib.browse_entry_def_map mbedm ON mbedm.entry = mbe.id LEFT JOIN metabib.browse_entry_simple_heading_map mbeshm ON mbeshm.entry = mbe.id where mbedm.id IS NULL AND mbeshm IS NULL; |
| 17:29 |
dbwells |
I still found 5 things I wasn't expecting to be orphaned from the concerto set, so I am not sure what is going on there. |
| 17:30 |
bshum |
What is simple_heading_map? |
| 17:30 |
* bshum |
doesn't seem to have that in his production DB... |
| 17:31 |
bshum |
Oh I see |
| 17:31 |
bshum |
We don't have it yet, nevermind. |
| 17:31 |
bshum |
That went in after our last step forward |
| 17:37 |
bshum |
dbwells: Is there supposed to be a difference in how 6 vs. 31 metabib field present in the metabib.title_field_entry? Or are they basically identical and the question is just how they are rendered in the browse table values? |
| 17:38 |
bshum |
Having only just run that against the concerto test set quickly, the only 7 bibs that show differences in those indexed values were like: |
| 17:38 |
bshum |
L'unique et sa propriété vs. L' unique et sa propriété |
| 17:38 |
bshum |
The extra space gets removed, and so forth |
| 17:39 |
bshum |
Otherwise, every other 6 and 31 were exactly the same on every bib in the test dataset. |
| 17:39 |
* bshum |
needs more test databases |
| 17:40 |
dbwells |
bshum: I am totally confused, as that is a change I would not expect to see. |
| 17:40 |
bshum |
dbwells: Well, I didn't inspect very closely, I just ran the final upgrade SQL from the branch on the bug ticket. |
| 17:40 |
bshum |
Maybe I missed something |
| 17:41 |
* senator |
hasn't been following this conversation, so i'm not sure this is still wanted, but in case it is: https://bugs.launchpad.net/evergreen/+bug/1235497/comments/8 |
| 17:41 |
pinesol_green |
Launchpad bug 1235497 in Evergreen "Title browse has display and sorting issues" (affected: 1, heat: 6) [Undecided,New] |
| 17:41 |
dbwells |
bshum: maybe you still have the old 31? |
| 17:41 |
dbwells |
(though I assume the upgrade would have blown up at you) |
| 17:41 |
bshum |
dbwells: The test system I applied the upgrade to didn't have a 31 in it before I applied the sql. |
| 17:42 |
senator |
"the baroque concerto" moves from the wrong place to the right place in my test |
| 17:42 |
bshum |
It's a fresh DB as of last Saturday, but I can rebuild again just in case. |
| 17:42 |
senator |
and similar |
| 17:42 |
bshum |
Oops, maybe tomorrow. (just saw the clock) |
| 17:45 |
dbwells |
senator: thanks for the testing and signoff. Glad it worked for you. |
| 17:48 |
|
RBecker joined #evergreen |
| 17:51 |
dbwells |
senator: I also responded to Liam before I saw your comment. We said roughly the same thing, save one point. The stock MODS <titleInfo> field does have the <nonSort> tag, so the main hang up is that we only get one 'joiner' for everything in title, while we (ideally) need a different joiner from <nonSort>-><title> than from <title>-><subtitle>. |
| 17:52 |
dbwells |
maybe I misunderstood what you were saying. In any case, it is a topic for another day. |
| 17:53 |
* dbwells |
hopes not tomorrow |
| 17:56 |
senator |
heh |
| 17:56 |
|
smyers_ joined #evergreen |
| 17:57 |
senator |
ah k, well, that is a significant point |
| 17:57 |
senator |
you put it more correctly |
| 17:57 |
senator |
dbwells++ |
| 17:57 |
senator |
yeah, enough of this for today :-) |
| 18:00 |
|
mrpeters left #evergreen |
| 19:02 |
|
smyers_ joined #evergreen |
| 19:53 |
|
zerick joined #evergreen |
| 19:59 |
|
sseng_ joined #evergreen |
| 22:43 |
|
Guest18642 joined #evergreen |
| 22:45 |
|
RBecker_ joined #evergreen |
| 22:46 |
|
RBecker joined #evergreen |
| 22:59 |
|
RBecker_ joined #evergreen |
| 23:10 |
|
RBecker_ joined #evergreen |
| 23:14 |
|
BigRig_ joined #evergreen |
| 23:22 |
|
LLckfan joined #evergreen |
| 23:23 |
LLckfan |
Hello |
| 23:23 |
LLckfan |
Does any1 know how to get a stale house smell out of a clean house without opening windows as fresh air is of no help? |
| 23:49 |
|
RBecker joined #evergreen |
