| Time |
Nick |
Message |
| 02:32 |
|
yar joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:24 |
|
agoben joined #evergreen |
| 07:58 |
|
remingtron joined #evergreen |
| 08:15 |
|
Dyrcona joined #evergreen |
| 08:19 |
|
rlefaive joined #evergreen |
| 08:29 |
|
ngf42 joined #evergreen |
| 08:50 |
|
mmorgan joined #evergreen |
| 08:51 |
|
kmlussier joined #evergreen |
| 09:16 |
|
yboston joined #evergreen |
| 09:22 |
|
mmorgan1 joined #evergreen |
| 09:24 |
|
jvwoolf joined #evergreen |
| 09:31 |
|
mmorgan joined #evergreen |
| 09:36 |
kmlussier |
dbwells++ Bmagic++ # Release building. |
| 09:36 |
kmlussier |
I'll do the blog / email announcements |
| 10:05 |
|
mmorgan1 joined #evergreen |
| 10:27 |
mmorgan |
kmlussier++ |
| 10:29 |
|
jwoodard joined #evergreen |
| 11:00 |
JBoyer |
Hatch is becoming a big topic of discussion here, would anyone on the web team be able to upload 0.1.4? It fixes an important permissions issue and it's about to be downloaded a lot more than I'd prefer in it's current state. |
| 11:00 |
JBoyer |
(I can't actually *build* a copy of 0.1.4 right now, if no one else can I'll be able to later tonight) |
| 11:06 |
|
Christineb joined #evergreen |
| 11:09 |
bshum |
JBoyer: |
| 11:09 |
bshum |
Oops, heh |
| 11:09 |
bshum |
JBoyer: Looking back at old logs, looks like berick uploaded Hatch 0.1.4 to lupin https://evergreen-ils.org/downloads/Hatch-Installer-0.1.4.exe |
| 11:09 |
bshum |
But we just have to edit the page to point at it |
| 11:09 |
bshum |
I can try that |
| 11:10 |
JBoyer |
Excellent. That's all that needs done. |
| 11:10 |
JBoyer |
bshum++ |
| 11:10 |
berick |
bshum: is the page in a repo or do you just hop on and edit the html? |
| 11:10 |
bshum |
berick: Wordpress, whee |
| 11:11 |
berick |
oh right |
| 11:11 |
bshum |
Okay links updated on the downloads page to point at the newer installer file |
| 11:13 |
* berick |
has a feeling 0.1.5 will be right around the corner |
| 11:13 |
bshum |
Heh |
| 11:14 |
Dyrcona |
Grr. |
| 11:14 |
* Dyrcona |
is not having any fun with logs. |
| 11:14 |
Dyrcona |
I have a forgive_payment and I'm trying to figure out where it was done because someone suspects another library of using their login. |
| 11:15 |
Dyrcona |
I can't find any logins for the user in the logs for the day this happened. |
| 11:15 |
Dyrcona |
I also haven't found the authtoken associated with the payment, either. |
| 11:27 |
JBoyer |
berick, interesting new feature, or do you think there's a fix for the Dymo issue, or? (I'm hoping it's not installer based, it should be in pretty good shape finally) |
| 11:30 |
JBoyer |
Oh, path related, probably |
| 11:31 |
berick |
JBoyer: yeah, was looking at the java path stuff |
| 11:31 |
berick |
well, not fixing it, just looking at the reports |
| 11:34 |
JBoyer |
There's just no fixing some situations. For instance, our "enterprise-y" installer here specifically leaves out the keys that Hatch looks for to determine if Java is installed. I know it normally puts the current version in the system PATH variable also, there may not be a change required. |
| 11:35 |
JBoyer |
(We kind of have to assume its in %PATH%, because if it's not and we do a string substitution in hatch.bat we |
| 11:36 |
JBoyer |
've just locked ourselves into a specific version of Java and Hatch breaks if you upgrade...) |
| 11:36 |
berick |
yeah, true |
| 11:38 |
* JBoyer |
gets chills remembering $VENDOR installing their own version of Java with their client because it wouldn't work with anything else... |
| 11:39 |
* mmorgan |
shudders at bad memories, too. |
| 11:39 |
berick |
yeah, that was raised as an option for Hatch, but there are obvious security problems there |
| 11:39 |
berick |
and packaging problems, etc. |
| 11:42 |
Dyrcona |
If someone switches users in the staff client, does that show up in the logs, and if so, how? |
| 11:43 |
Dyrcona |
I found what I think is the appropriate auth key, but it doesn't correspond to a login of the user in the payment table. |
| 11:43 |
JBoyer |
Dyrcona, it should show up like any other login, but I'm not certain off hand if you can tell it was a switch user operation or not. |
| 11:43 |
Dyrcona |
JBoyer: Does the authtoken change? |
| 11:43 |
Dyrcona |
I guess it would have to.... |
| 11:44 |
JBoyer |
Should be a second one with a potentially different timeout, yeah |
| 11:46 |
Dyrcona |
And, why does the login username used for this session not exist as a usrname nor barcode in my database? |
| 11:46 |
Dyrcona |
"Curiouser and curiouser," said Alice. |
| 11:48 |
Dyrcona |
'Cause they changed the usrname yesterday morning. :) |
| 11:49 |
JBoyer |
Sounds like someone is going to get all sorts of talking to. |
| 11:49 |
|
sandbergja joined #evergreen |
| 11:50 |
Dyrcona |
Well, I guess the library changed their username 'cause they thought someone else was using their account. |
| 11:51 |
Dyrcona |
JBoyer: Do you know any tricks to associate a payment with the authtoken of the user that made it? |
| 11:51 |
JBoyer |
Hmm. Maybe. Let me look at something |
| 11:51 |
Dyrcona |
I got this far by find the payment creation in the logs by the payment id, then grepping the Cstore pid, and the thread trace. |
| 11:52 |
Dyrcona |
The trace lead me to some org unit permission look and then to one with the authtoken and user id. |
| 11:53 |
JBoyer |
That's what I was going to suggest; any authtoken used in the same trace should be the one that called it. |
| 11:55 |
JBoyer |
Ah, looks like set_audit_info may be called, which has an authtoken in it. |
| 11:55 |
Dyrcona |
That's what I thought. |
| 11:56 |
kmlussier |
Bah! I'm commenting on bugs under the bug maintenance account again. :( |
| 11:56 |
JBoyer |
And the "successful login" line can get you the login thread trace, and IF the login_type in that trace is temp then it's definitely a New User situation. It looks like "persist" may be used for normal logins OR switch users though. |
| 11:56 |
JBoyer |
kmlussier, I wondered if that was you. :) |
| 11:57 |
kmlussier |
JBoyer: I couldn't figure out why my comments weren't showing up in my Inbox. :) |
| 12:00 |
Dyrcona |
JBoyer: I'm not seeing a type in the successful login line. I also had to grep the logs on all the bricks to find it. :( |
| 12:01 |
Dyrcona |
Anyway, looks like someone is gonna get a talking to, 'cause this library's staff did it themselves. :) |
| 12:01 |
* mmorgan |
looks wistfully at bug 1354482 |
| 12:01 |
pinesol_green |
Launchpad bug 1354482 in Evergreen "reports: need workstation tracking for all payment types" [Wishlist,Confirmed] https://launchpad.net/bugs/1354482 |
| 12:01 |
Dyrcona |
For that to happen, I think payments would need workstation tracking. :) |
| 12:02 |
JBoyer |
Dyrcona, you've got to grep the thread trace from the successful login line to get the open-ils.auth_internal.session.create entry (should be the next line in the trace) that has the user id, login_type, and workstation. |
| 12:02 |
mmorgan |
Yes, indeed. Maybe workstation tracking for all payment types should be its own bug? |
| 12:03 |
Dyrcona |
JBoyer: Thanks, I'll give that a look next time. |
| 12:05 |
csharp |
re: Hatch - we're definitely seeing problems where the Java path gets borked somehow |
| 12:06 |
csharp |
C:\ProgramData\Oracle\Java\javapath (which is a junction point pointing to something like C:\ProgramData\Oracle\Java\javapath_target_1685229022) |
| 12:07 |
csharp |
the solution I've seen online is to set java_home to the correct version's /bin (\bin) then make sure %java_home% is in the Path variable |
| 12:07 |
|
khuckins_ joined #evergreen |
| 12:07 |
csharp |
and I'm researching scripts that people have already written to do that (e.g.: https://stackoverflow.com/questions/27080846/java-path-set-wrongly#27080931 ) |
| 12:08 |
|
yboston joined #evergreen |
| 12:08 |
csharp |
in any case, this is way above the presumed skill level of most of our local admins |
| 12:08 |
csharp |
it'd be nice if there was a "here, run this to fix your issue"-style solution |
| 12:15 |
Dyrcona |
It's be nicer if it didn't happen in the first place. :) |
| 12:17 |
csharp |
yeah |
| 12:18 |
JBoyer |
I am curious how it's getting installed without editing the system path. I don't remember if that's still an option. (Easy fix, if so...) |
| 12:36 |
|
mmorgan joined #evergreen |
| 12:38 |
csharp |
I'm actually wondering if Java may have been already installed on the affected stations |
| 12:38 |
csharp |
honestly, workstation administration is not our game and since we leave it up to the libraries, who knows what state these stations are in |
| 12:39 |
csharp |
we learned, for instance, that multiple libraries are still running Windows XP with no immediate plans to upgrade |
| 12:39 |
JBoyer |
<Flames>That's Fine.</Flames> |
| 12:56 |
|
jihpringle joined #evergreen |
| 13:00 |
|
mmorgan1 joined #evergreen |
| 13:23 |
pinesol_green |
[evergreen|Dan Wells] Adjust COMMIT placement in 3.0.3 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=af4dc46> |
| 13:27 |
* miker |
reads up a little bit... |
| 13:28 |
miker |
it'd be nice if Windows had a halfway usable script interpreter and CLI so we could just do it right... |
| 13:28 |
Dyrcona |
It's be nice if everyone would just switch to a decent O/S, like OpenBSD. :P |
| 13:28 |
Dyrcona |
j/k |
| 13:29 |
JBoyer |
I hear Powershell is quite nice compared to cmd. At least if you have fond memories of VB. |
| 13:29 |
Dyrcona |
I also wonder if the libraries with XP are actually running the computers or if someone else is running them. :) |
| 13:30 |
JBoyer |
Depending on their firewall situation the answer is "both" |
| 13:30 |
Dyrcona |
heh |
| 13:30 |
rhamby |
Jboyer : I had to do a few tasks in Powershell a few years ago, it was way better than I remembered from anything of windows scripting from another age of the world |
| 13:32 |
JBoyer |
I'm worried that the real sticking point is console access. Windows is really weird about that and I don't think any of the scripting engines offer the correct access. (PS may, though, I don't recall.) |
| 13:41 |
miker |
new client requirement: strawberry perl |
| 13:41 |
miker |
OH! let's just write hatch in perl! |
| 13:42 |
JBoyer |
*flames* |
| 13:42 |
Dyrcona |
Python would be better than Perl, honestly, if you want to target Windows. |
| 13:42 |
* Dyrcona |
ducks |
| 13:43 |
miker |
sorry, you lost me after the first phrase |
| 13:44 |
JBoyer |
I can't read what you wrote miker, you don't have the correct whitespace preceding that line. ;) |
| 13:45 |
miker |
in all seriousness, if 1) python has good printing support on windows and 2) someone wanted to do that, ExeMaker would simplify our lives |
| 13:45 |
miker |
I don't know about (1) at all, and bet tuits for (2) are spendy |
| 13:48 |
miker |
hrm... launch4j? |
| 13:50 |
miker |
JBoyer / berick: would launch4j be a possible solution? it pins the java version, but we can update the official when java is fixed. and have hatch check for updates (similar to, but simpler than, what the xul client does) and alert the user, maybe? |
| 13:50 |
berick |
@google launch4j |
| 13:50 |
pinesol_green |
berick: PHRASING!!! |
| 13:52 |
miker |
http://launch4j.sourceforge.net/ |
| 13:52 |
miker |
sorry |
| 13:52 |
berick |
maybe, but not something I've used before (clearly) |
| 13:54 |
JBoyer |
It looks like it's capable of just figuring out the current version itself (the embedded JRE is only an option) so it may work out well enough. |
| 13:55 |
JBoyer |
While it supports console apps, I don't see any indication as to whether or not it opens a console itself (for passthrough) that would be a dealbreaker if not. |
| 13:56 |
JBoyer |
I can look at it some evening. (work machine is useless for Java because reasons.) |
| 14:01 |
miker |
JBoyer++ |
| 14:04 |
|
hbrennan joined #evergreen |
| 14:06 |
JBoyer |
Although, if you use a "modern" Java, it looks like this path should always work: %PROGRAMDATA%\Oracle\Java\javapath\java (mentioned in the bug but I wanted to look at some more things) |
| 14:07 |
JBoyer |
Looks like someone is finally using some of NTFS |
| 14:07 |
JBoyer |
's fancy bits. |
| 14:07 |
JBoyer |
(i.e. it's a Windows symlink) |
| 14:08 |
JBoyer |
That may be the shortest path forward (hey-oh!) without dragging even more dependencies and whatnot into things. |
| 14:20 |
* kmlussier |
just realized the EOB meeting isn't happening right now. |
| 14:20 |
hbrennan |
kmlussier: But you're ahead of schedule now for tomorrow |
| 14:20 |
hbrennan |
:) |
| 14:21 |
JBoyer |
kmlussier should start the meeting off tomorrow with "well it took you all long enough!" |
| 14:24 |
kmlussier |
hbrennan / JBoyer: I'm now thinking I should always put meetings in my calendar a day early. People would think I was so organized! |
| 14:24 |
JBoyer |
kmlussier++ |
| 14:24 |
hbrennan |
ha! |
| 14:25 |
hbrennan |
It's at 1pm Eastern tomorrow if I'm doing the math correctly |
| 14:26 |
kmlussier |
hbrennan: Yes, 1 pm is correct. I just updated the EOB calendar too. |
| 14:27 |
hbrennan |
Thanks for doing that |
| 14:55 |
mmorgan |
Does anyone have a script or other process to check in items in a batch? |
| 14:56 |
mmorgan |
I know it can be done in Item Status in small batches. |
| 14:57 |
phasefx |
mmorgan: you could craft a list of barcodes into an offline transactions file, import it, and process it |
| 14:57 |
phasefx |
I've never done that before, though |
| 14:58 |
phasefx |
of course, just using offline may be no harder than populating such a barcode list, depending on circumstances :) |
| 14:58 |
phasefx |
why batch? |
| 14:58 |
mmorgan |
I thought of offline, too, but was thinking of something more automated. |
| 14:59 |
phasefx |
craft a list of barcodes into a srfsh script |
| 14:59 |
phasefx |
fun part is getting an authtoken and using it in an automated fashion |
| 15:01 |
mmorgan |
The idea is, we have items that are very overdue. We want to delete them, but don't want to delete items with open transactions. |
| 15:02 |
phasefx |
ooh, I'd be tempted to write a CheckIn reactor for A/T |
| 15:02 |
mmorgan |
a srfsh script sounds intriguing. |
| 15:02 |
phasefx |
A/T might would be more convenient for capturing the output |
| 15:03 |
phasefx |
you'll want to use a noop parameter with the checkin to suppress holds and transits, I bet |
| 15:03 |
mmorgan |
True. A/T is an iteresting idea, and certainly sounds more robust than srfsh. |
| 15:05 |
phasefx |
could even make a CheckInThenDelete reactor |
| 15:06 |
phasefx |
or as a parameter to a CheckIn reactor |
| 15:08 |
phasefx |
mmorgan: one thing, checking an item in won't necessarily close a transaction |
| 15:08 |
* mmorgan |
has used action triggers a lot but has never built a reactor. |
| 15:08 |
JBoyer |
mmorgan, there's also the option of using CronScript.pm in your onw scripts, which can be used to do a lot of things in a simple way (you could, for instance, feed your script all of the barcodes and then do this checkin and delete all in one step) |
| 15:09 |
mmorgan |
phasefx: Understood. But it would have a checkin_date. |
| 15:10 |
miker |
mmorgan: FWIW, there's no need to edit EG code to create a reactor. just write a perl module (using any existing reactors as a guide) and place it somewhere that perl can find it, add it as a reactor via the staff client, and build your event def. |
| 15:11 |
|
jwoodard joined #evergreen |
| 15:11 |
mmorgan |
miker: That's cool! Didn't know you could do that. |
| 15:12 |
miker |
related, my hope and dream is that one day reactors will be traded, maintained, enhanced outside of EG proper, rather than folks waiting for a new release to get a new reactor. (everything is in place for that since A/T was introduced, except the knowledge transfer on the capability, and a place to share them) |
| 15:14 |
mmorgan |
miker: Are there seeds for that knowledge accessible somewhere for perusal? |
| 15:15 |
* miker |
looks |
| 15:15 |
miker |
I've mentioned it on the list a time or two, I think ... lemme looks through commits and such |
| 15:15 |
mmorgan |
JBoyer: I'm not familiar with using Cronscript.pm, but will look at that, too. |
| 15:32 |
|
mmorgan1 joined #evergreen |
| 15:33 |
* mmorgan1 |
had to run off to a meeting |
| 15:33 |
mmorgan1 |
miker++ phasefx++ JBoyer++ |
| 16:08 |
kmlussier |
jeff: To follow up on your question from way back when on bug 1414197, what I'm seeing in the xul client right now is that when you delete that serials item, it also deletes the issuance without updating the summary statement. You therefore don't have a means of updating that summary information from the client. I think that's why I considered it a bug rather than expected behavior. |
| 16:08 |
pinesol_green |
Launchpad bug 1414197 in Evergreen "serials: deleting an item does not update the basic summary statement" [Medium,New] https://launchpad.net/bugs/1414197 |
| 16:08 |
miker |
mmorgan1: so, there's not. in fact, the docs as written suggest the opposite (must put something specifically in Reactor.pm, which is FAKE NEWS) :( |
| 16:11 |
miker |
mmorgan1: if you look at Open-ILS/src/perlmods/lib/OpenILS/Application/Trigger/ModRunner.pm starting at line 49, it does the following for a reactor called, say, My::Fancy::Reactor::some_method ... |
| 16:11 |
kmlussier |
More FAKE NEWS from the failing Evergreen docs. So dishonest. |
| 16:11 |
miker |
heh |
| 16:13 |
kmlussier |
For the record, I love the Evergreen docs. |
| 16:13 |
miker |
1) use the regular perl module loading mechanisms to try and load a module called My::Fancy::Reactor::some_method |
| 16:14 |
miker |
2) try to load a module called (for reactors) OpenILS::Application::Trigger::Reactor::My::Fancy::Reactor::some_method |
| 16:14 |
miker |
3) try to load a module called (for reactors) OpenILS::Application::Trigger::Reactor::My::Fancy::Reactor |
| 16:14 |
miker |
1) use the regular perl module loading mechanisms to try and load a module called My::Fancy::Reactor |
| 16:14 |
miker |
er, that second 1 is actually 4. alternative fact! |
| 16:15 |
miker |
and, finally, try to load OpenILS::Application::Trigger::Reactor and look for a sub in it called some_method |
| 16:16 |
miker |
so, you can put a file in perl's module path called My/Fancy/Reactor.pm that has a sub in it called some_method and it'll work as if it were a "blessed" reactor that EG ships |
| 16:19 |
miker |
this works for any A/T module -- collectors, validators, reactors, clean-up modules |
| 16:20 |
miker |
it was designed to be a method of injecting custom code to react to things that happen in the ILS -- events, if you will :) ... adding autocreate calls to more in-code events would maybe help drive the use more outside notifications |
| 16:23 |
miker |
for instance (jeff and others, this may be relevant to your interest) if we added event autocreate calls surrounding bib create/update/delete calls, a custom a/t reactor could ship the record out to an external thing that cares about bib changes |
| 16:23 |
Dyrcona |
I'd be wary of writing a check-in reactor to delete things. You don't want to delete everything you check-in. |
| 16:24 |
miker |
sprinkling those around should be made with /some/ forethought to how often the events will happen, of course, but ever circ event tells the a/t system to create events if configured, so... |
| 16:24 |
miker |
Dyrcona: oh, certainly. you'd want to protect it with a granularity at the very least |
| 16:28 |
phasefx |
can you make up events (in the vein of longoverdue.auto) as a way of chaining multiple A/T together? I could imagine a CheckInDelete reactor firing off a checkin.delete.auto that another A/T reacts to notify the libraries |
| 16:40 |
|
mmorgan joined #evergreen |
| 16:40 |
|
mmorgan2 joined #evergreen |
| 16:41 |
|
jvwoolf left #evergreen |
| 16:44 |
Dyrcona |
I'm being asked if there is a way to disable enriched EDI. B&T apparently thinks it's a problem for one of our accounts. |
| 16:44 |
berick |
Dyrcona: that's INCLUDE_COPIES |
| 16:44 |
berick |
in the template |
| 16:44 |
berick |
boolean |
| 16:45 |
Dyrcona |
So, I'd have to modify the template to disable it for this vendor and this account? |
| 16:45 |
berick |
right |
| 16:46 |
Dyrcona |
So I don't have to spend a lot of time looking, do you know the event def off the top of your head? |
| 16:46 |
berick |
i think id 23 |
| 16:47 |
Dyrcona |
Thanks! |
| 16:47 |
Dyrcona |
berick++ |
| 16:47 |
* mmorgan |
returns from meeting and reads backscroll with interest. |
| 16:52 |
|
mmorgan1 joined #evergreen |
| 16:57 |
jeff |
my irc input line has consisted of the following string for most of the day: "also, " |
| 16:57 |
jeff |
i've no idea where i was interrupted. |
| 16:58 |
jeff |
JBoyer++ for kicking off bug 1744153 |
| 16:58 |
pinesol_green |
Launchpad bug 1744153 in Evergreen "Usernames should be case insensitive" [Wishlist,Confirmed] https://launchpad.net/bugs/1744153 |
| 16:58 |
jeff |
i could have sworn we had one of those already, but it might have just been several irc conversations / debates. |
| 17:08 |
|
mmorgan1 left #evergreen |
| 17:11 |
Dyrcona |
Well, I'm making nothing but a string of typos in everything I type at the moment, so time to call it a day. |
| 17:12 |
hbrennan |
Dyrcona: (laughing crying emoji) |
| 18:02 |
|
khuckins__ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
