Time |
Nick |
Message |
01:42 |
|
Mark__T joined #evergreen |
02:51 |
|
dbwells_ joined #evergreen |
07:32 |
|
timlaptop joined #evergreen |
07:34 |
|
jboyer-isl joined #evergreen |
08:05 |
|
rjackson-isl joined #evergreen |
08:11 |
|
collum joined #evergreen |
08:22 |
|
mrpeters joined #evergreen |
08:30 |
|
RoganH joined #evergreen |
08:34 |
|
akilsdonk joined #evergreen |
08:38 |
|
berick joined #evergreen |
08:40 |
|
berick joined #evergreen |
08:42 |
mrpeters |
anyone devised a nagios plugin that monitors logs for IS NOT CONNECTED TO THE NETWORK!! type errors? |
08:45 |
|
mmorgan joined #evergreen |
08:46 |
|
berickm joined #evergreen |
08:55 |
|
ericar joined #evergreen |
09:03 |
|
rfrasur joined #evergreen |
09:16 |
rfrasur |
I suspect this has been discussed in the past, but has there been conversation about a thin staff client that only does patron stuff? No cataloging, no reporting, etc.? |
09:17 |
RoganH |
Not to my knowledge. I suspect that would touch on the "do we want to support two staff clients" issue. |
09:17 |
RoganH |
Mind you that is kinda what was being batted around for a staged roll out of a web only staff client at the hack-a-way. |
09:18 |
rfrasur |
Hmm. |
09:18 |
* rfrasur |
adds those thoughts into the mix |
09:20 |
rfrasur |
ok |
09:20 |
RoganH |
I'm going from memory so apply big bit of salt but ... |
09:20 |
rfrasur |
yeah...me too...and mine is lacking. |
09:20 |
RoganH |
the discussion was to have patron searching and checkout only first to have most important thing up front |
09:20 |
* rfrasur |
is just thinking about how to run a staff client for "essential services only" on a less than minimum spec system. |
09:21 |
RoganH |
then add things in order of priority to that |
09:21 |
RoganH |
in order to get folks something they could use, that wouldn't have the memory issues and could get people accustomed to the idea of the web client and get feedback from |
09:21 |
rfrasur |
le sigh |
09:22 |
RoganH |
now that sound easy but there are the extra bits - receipts, authentication, etc... |
09:22 |
rfrasur |
It doesn't sound easy at all. |
09:22 |
RoganH |
everything is easy if broken down into discrete bits with enough manpower to do it :) |
09:23 |
rfrasur |
I was misunderstanding how the staff client functions. In my mind, it was start it up...and then as it's loading, it's starting different services... |
09:23 |
rfrasur |
so it'd just be a matter of not starting certain services...but that's not what happens. |
09:24 |
RoganH |
nope |
09:24 |
RoganH |
really ... and this is an oversimplification ... the staff client is a big web browser |
09:25 |
rfrasur |
that makes sense...so to just have it do certain things, you'd basically have to build a new one. |
09:25 |
RoganH |
Unfortunately the web with addons like dojo is a lot more than just HTML anymore for all that extra stuff you want to be able to do via javascript and beyond |
09:26 |
RoganH |
with the potential for great power comes the potential for great memory leaks |
09:26 |
|
kmlussier joined #evergreen |
09:26 |
rfrasur |
plus xulrunner isn't going to be supported anymore. |
09:26 |
rfrasur |
okay, I guess it's not a battle to fight right now |
09:26 |
RoganH |
And it's not really meant to be used the way we are using (abusing) it. To keep people from doing so in more recent versions they've explicitly taken out things we need. |
09:27 |
RoganH |
So we can't advance the version we use to get rid of issues like the memory leaking without losing that functionality. |
09:27 |
rfrasur |
oss should be used any way it can be. :p That's why it's oss. |
09:27 |
RoganH |
Galen has a write up on it somewhere he did for GAPINES. I haven't seen it but I keep meaning to bug Chris for a copy out of curiosity. |
09:28 |
kmlussier |
RoganH: That writeup is posted on a Launchpad bug somewhere. |
09:29 |
RoganH |
kmlussier: I was about to type "and it's probably floating out there somewhere but I haven't gone to look for it." |
09:29 |
RoganH |
:) |
09:30 |
* RoganH |
finds that time is always the enemy. |
09:30 |
csharp |
rfrasur: I would consider running your circ stations on Linux if you're interested in performance gains on older hardware |
09:30 |
csharp |
something like xubuntu or lubuntu would *fly* compared to Windows |
09:31 |
rfrasur |
Well, I think, if nothing else, I'll keep thinking about the possibility of a pared down client because I know of several implementations that have been mentioned in our community...mostly book mobile...but they got me thinking about some other things. |
09:32 |
rfrasur |
csharp: could it run on 512MB? I'm thinking of Linux anyway. |
09:33 |
csharp |
rfrasur: you would probably want lubuntu on RAM that low |
09:33 |
csharp |
but I would also consider RAM upgrade |
09:33 |
rfrasur |
Not possible in this case. that's the challenge |
09:34 |
csharp |
I see |
09:34 |
bshum |
It's too tight, the min memory for xul 14 is supposed to be 512 MB. So that leaves not much room for the rest. |
09:34 |
csharp |
rfrasur: not possible for technical reasons? or budget? (don't mean to pry ;-)) |
09:35 |
bshum |
She's being awesome and building with fun toys. |
09:35 |
rfrasur |
technical reasons. I want to build a portable workstation for less than $100 w/ a raspberry pi. |
09:35 |
csharp |
ah |
09:35 |
csharp |
rfrasur++ |
09:35 |
rfrasur |
(I may or may not be bored of administrating...don't tell my board...no pun intended) |
09:36 |
rfrasur |
I don't even know if that's a word, btw. administering? I dunno. |
09:36 |
* rfrasur |
files and reads forums |
09:37 |
bshum |
rfrasur: I didn't look at any of the code ESI and CWMARS experimented with, but vaguely recall there being a test branch with some added circ options for the selfcheck interface. |
09:37 |
rfrasur |
bshum++ I hadn't thought about that. |
09:38 |
kmlussier |
bshum: Was that ever put in a branch? I don't recall seeing it. |
09:38 |
bshum |
Ideally what you want is addressed with the new web client stuff. But I wonder if there's any shirt gain in that. |
09:38 |
bshum |
*short |
09:38 |
csharp |
kmlussier: bug 1161122? |
09:38 |
pinesol_green |
Launchpad bug 1161122 in Evergreen "rejiggered staff client patron search, summary, display" (affected: 3, heat: 16) [Wishlist,Triaged] https://launchpad.net/bugs/1161122 |
09:38 |
rfrasur |
well, that's the thing. I dunno that what I'm thinking of would be of much value for the community at this point. |
09:39 |
rfrasur |
It'd be a pretty narrow use. |
09:39 |
* rfrasur |
reads the bug |
09:39 |
kmlussier |
csharp: No. that's something different. C/W MARS also made improvements to self check so that staff could use it to check materials in and out. I don't think there was any functionality for patron registration. It was fairly limited to handle the most common circ tasks. |
09:40 |
bshum |
rfrasur: I was thinking about using selfcheck with pi. Just didn't think up enough USB ports for a keyboard + barcode scanner the night I pondered. |
09:40 |
csharp |
kmlussier: ah - gotcha |
09:40 |
rfrasur |
oh, you can use a powered USB hub |
09:41 |
rfrasur |
the Model B has two USB ports also. (but I'd want to use one of those for a wireless dongle). |
09:41 |
bshum |
kmlussier: I think maybe it's in the ESI repositories. Or at least there was a branch named in such a way that made me think of selfcheck changes. |
09:41 |
bshum |
But no bug ticket or working branches filled to my recollection. |
09:43 |
rfrasur |
And then maybe we'll replace ALL of our public computers w/ internet only PI-run stations...and just keep 2 productivity stations...because all they want to do is play FB games anyway and go to dating sites...and then we'd cut our tech costs would be 20% of what they are now...and muahahahahah |
09:43 |
* rfrasur |
continues reading the bug report. |
09:43 |
kmlussier |
There were also options to print holds slips, print transit slips, checkin with amnesty mode and to backdate a checkin. |
09:44 |
rfrasur |
kmlussier: along w/ the patron registration, that'd be perfect |
09:44 |
bshum |
A library I visited in CT replaced all their catalog stations with Pi machines. They 3D printed their own custom cases with mount points to hide them under desks, inside shelves, etc. |
09:44 |
* csharp |
mmmm pi |
09:44 |
bshum |
I thought it was pretty awesome |
09:44 |
bshum |
And efficient. |
09:44 |
kmlussier |
rfrasur: Sure, so patron registration would be the thing you would have to add. There also was nothing built in to deal with fines and other issues. |
09:45 |
rfrasur |
oh, we're not that cool. Though....now I'd like to look at 3D printers. |
09:45 |
bshum |
The power usage is stupid small. And if they break you put on a new SD card with preset images. |
09:45 |
rfrasur |
hmm, kmlussier...good to note. |
09:45 |
* tsbere |
has used 3D printers before. Some are more useful than others. |
09:45 |
bshum |
So maintenance can be pretty low. |
09:46 |
rfrasur |
well, I'm gonna start here. I think it's dumb to not be utilizing cheap, "powerful" technology when our budgets are expected to do so much more than they used to. |
09:46 |
* rfrasur |
files 3D printing for after something is accomplished with PI |
09:47 |
bshum |
Their big hurdle was dealing with the monitors and using the hdmi/vga adapter. Some weird dell monitors didn't always work or some such. |
09:47 |
rfrasur |
and it'll also kill the Linux bird |
09:47 |
rfrasur |
Yeah, I'm going to start w/ monitors we have in the closet...if they don't work, no loss. |
09:47 |
jcamins |
rfrasur: not the penguin! What do you have against penguins?!? |
09:48 |
rfrasur |
jcamins: probably a bad analogy...killing two birds w/ one stone... |
09:48 |
* rfrasur |
shouldn't throw stones at birds |
09:48 |
* jcamins |
understood, but couldn't resist taking it literally. |
09:48 |
rfrasur |
my apologies. The penguin will live on...and live well. |
09:48 |
rfrasur |
no worries...same :D |
09:48 |
csharp |
tux++ |
09:48 |
rfrasur |
I'd also like to test out Linux for myself before launching it on my staff.... |
09:48 |
jcamins |
rfrasur: I don't think there's any such program currently, but one option might be a SIP client. |
09:49 |
csharp |
@blame search tux |
09:49 |
pinesol_green |
csharp: 1 found: #8: "$who stole bradl's tux doll!" |
09:49 |
jcamins |
You couldn't do patron registration with that, but it'd require way less in the way of resources. |
09:50 |
csharp |
@blame 8 rfrasur |
09:50 |
pinesol_green |
csharp: rfrasur stole bradl's tux doll! |
09:50 |
rfrasur |
jcamins: I think it's the patron registration (as well as the billing stuff) that's the tie-up...or A tie-up |
09:51 |
rfrasur |
w/ regard to the staff client, I'm thinking of bookmobile use as well as some of our VERY poor libraries. Although a remote self-check also has some interesting possibilities. |
09:52 |
rfrasur |
am I correct in thinking that I18N deals w/ language support? |
09:52 |
jcamins |
Yeah, that wouldn't work for a bookmobile, but I was thinking of poor branch libraries. |
09:53 |
jcamins |
Yes. Internationalization. |
09:53 |
rfrasur |
jcamins: yeah, the poor branch libraries...I think that could actually work quite well. |
09:53 |
jeff |
rfrasur: in our adventures in web based staff interfaces, we're probably going to start with service desk functions, but not so much the "this only happens at the welcome desk" stuff. for us, that may include patron-related things such as updating information, renewing cards, resetting username/password, placing holds, renewing items... just not brand new checkouts or taking payments. |
09:53 |
jeff |
oh dear. that probably truncated. |
09:53 |
csharp |
jeff: came through for me ;-) |
09:54 |
rfrasur |
jeff: it came through good for me as well. when you say "we," are referring to TADL? or EG community? |
09:54 |
jeff |
cool. i tend to be... verbose. i should probably configure my client to split my lines properly. |
09:54 |
rfrasur |
(adventures in web-based staff interfaces....great title) |
09:54 |
jeff |
rfrasur: sorry, i should have clarified. that was a "we" in the TADL sense of the word. |
09:55 |
rfrasur |
jeff: that's what I thought. As you proceed w/ your adventures...or get somewhere, I'm interested to see where you end up. |
09:55 |
jeff |
rfrasur: but that's with the full intent of it being work that's done within the community and with an eye toward being at least an experiment that can be built upon or learned from -- this would not be a "tadl only" interface. |
09:56 |
jeff |
it's always that balancing act, but the intent is that we would be working (with others as available) and our priorities would drive where i focused my effort first. |
09:56 |
rfrasur |
jeff++ |
09:56 |
jeff |
and of course things may change, but that's the info that's most current, in terms of our plans. |
09:57 |
jeff |
i'm also interested in little experiments like a mobile hold pull list interface -- those can sometimes be smaller in scope and still useful as learning experiments. |
09:58 |
rfrasur |
brb, have a phone call |
09:58 |
jeff |
i keep saying "experiments" a lot. i suppose that's just one way of managing expectations. :-) |
10:00 |
|
yboston joined #evergreen |
10:00 |
|
cjohnson joined #evergreen |
10:01 |
rfrasur |
well, most of what we do is experimenting anyway. |
10:01 |
|
mllewellyn joined #evergreen |
10:07 |
cjohnson |
Does anyone know of a devel resource outlining the function of all the XUL / js files in Evergreen? |
10:07 |
cjohnson |
I'm looking for the files that control workstation toolbars--not sticking on our Mac client workstations. |
10:08 |
rfrasur |
I like the stuff that I see come out of TADL. From an end-user standpoint, that is. I've used your web stuff often to illustrate some things to other librarians. |
10:10 |
|
zamboli joined #evergreen |
10:20 |
jeff |
rfrasur: thanks! wjr and scott get a lot of credit for those -- i make very ugly web pages, for the most part. |
10:20 |
rfrasur |
well, feel free to pass along my compliments. And it's not just how things look (although that's part of it) but what they do. |
10:21 |
tsbere |
cjohnson: The toolbars are controlled by menu.xul/menu.js, I believe. That doesn't include the "edit toolbars" interface, mind you. |
10:22 |
|
mschell joined #evergreen |
10:24 |
jeff |
rfrasur: passing along. thanks! :-) |
10:24 |
rfrasur |
tadl_et_al++ |
10:27 |
jeff |
rfrasur: thanks again -- see msgs. |
10:27 |
mschell |
Hoping for some direction. Whats the best way to change all of type of item (ie. DVD) to floating, in the client. (EG 2.4)? Thanks! |
10:30 |
|
j_scott joined #evergreen |
10:32 |
tsbere |
mschell: In the client? Copy bucket, I think. Filling the bucket is harder. |
10:33 |
mschell |
yeah. not sure how to fill the bucket |
10:33 |
* tsbere |
finds that kind of thing easiest in the DB itself, but that requires that you have access to the DB... |
10:34 |
jeff |
mschell: My recommendation is influenced by the fact that I can make bulk changes like that at the database level without needing to ask someone else to make the change for me, but I recommend making bulk updates at the database level (carefully), especially if you're talking about more than a few dozen items. |
10:34 |
|
kbeswick joined #evergreen |
10:35 |
tsbere |
mschell: How are you defining "DVD"? MARC? Circ Modifier? Copy Location? |
10:35 |
cjohnson |
tsbere: Thanks! I'll look at these. Have a hunch it's specific to the MacOS/user permissions. Can't get the toolbars to save on Mac but fine on Windoze and Linux clients. |
10:35 |
jeff |
mschell: you can write a report that outputs only the barcode of the items you are interested in changing, and you can open a Copy Status tab and upload that file (containing one barcode per line), and either edit those items or add them to a bucket. |
10:36 |
mschell |
tsbere: circ modifier or shelving location |
10:36 |
mschell |
jeff: that could work. thanks |
10:40 |
jeff |
mschell: you're welcome! |
10:49 |
|
moodaepo joined #evergreen |
11:33 |
cjohnson |
goodbye |
11:34 |
|
cjohnson left #evergreen |
11:42 |
|
phasefx2 joined #evergreen |
12:01 |
|
jdouma joined #evergreen |
12:07 |
zamboli |
hi, i'm a newer programmer looking to help out on an open source project, do you guys have a place for people looking to learn? |
12:07 |
zamboli |
i know it's a large complex application... |
12:08 |
rfrasur |
zamboli, have you already checked out evergreen-ils.org? |
12:08 |
zamboli |
i've read the FAQ and such |
12:09 |
rfrasur |
You can also get more information at our Launchpad site https://launchpad.net/evergreen |
12:09 |
zamboli |
okay, i didn't see that, thanks |
12:10 |
rfrasur |
https://github.com/evergreen-library-system/Evergreen there's also this. |
12:11 |
zamboli |
master is the release branch i presume? |
12:11 |
rfrasur |
You may also want to start by looking at the code as well as maybe doing an install so you can see what does what. Yes, master is the release branch. |
12:11 |
zamboli |
or is it the development repository? |
12:11 |
zamboli |
ok |
12:12 |
rfrasur |
I'm a mere librarian. You'll need to talk to a developer/smarter person for more details. gmcharlt, eeevil, csharp or any number of others can give you more info. |
12:13 |
RoganH |
master is what is currently being worked on for release |
12:13 |
rfrasur |
http://evergreen-ils.org/dokuwiki/doku.php?id=community:irc_channel If you check out this list, you can get some idea of who might be most helpful...or at least get started. bshum and kmlussier are also very good at explaining things for new people. |
12:13 |
gmcharlt |
zamboli: if you want some low-hanging fruit, the "bitesize" bugs are suitable for those new to the codebase |
12:13 |
gmcharlt |
see https://bugs.launchpad.net/evergreen/+bugs?field.tag=bitesize |
12:16 |
zamboli |
cool, i'll poke around there |
12:16 |
zamboli |
thanks |
12:16 |
dbwells |
zamboli: also, maybe you found this, but our full git working repo is here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=summary |
12:16 |
|
kayals joined #evergreen |
12:17 |
dbwells |
zamboli: the gitbug stuff is there for people to stumble upon, but we don't really use it for any of the higher-level features |
12:17 |
dbwells |
s/gitbug/github/ |
12:18 |
csharp |
~contribute |
12:18 |
pinesol_green |
Interested in contributing to the Evergreen project? Please see http://www.evergreen-ils.org/dokuwiki/doku.php?id=contributing |
12:18 |
kmlussier |
zamboli: http://evergreen-ils.org/dokuwiki/doku.php?id=eg_developer_overview might also be helpful. |
12:19 |
dbwells |
csharp: thanks, was about to post that, but didn't know that fancy trick |
12:19 |
csharp |
heh ;-) |
12:19 |
csharp |
you can even do |
12:19 |
csharp |
~contribute | zamboli |
12:19 |
pinesol_green |
zamboli: Interested in contributing to the Evergreen project? Please see http://www.evergreen-ils.org/dokuwiki/doku.php?id=contributing |
12:19 |
rfrasur |
(the awesomeness of pinging all the people) |
12:20 |
kmlussier |
Any interest in a dev meeting next week? |
12:20 |
|
smyers_ joined #evergreen |
12:23 |
csharp |
~no contribute is <reply> Interested in contributing to the Evergreen project? Please see http://www.evergreen-ils.org/dokuwiki/doku.php?id=contributing and http://evergreen-ils.org/dokuwiki/doku.php?id=eg_developer_overview. |
12:23 |
pinesol_green |
I'll remember that csharp |
12:25 |
rfrasur |
pinesol_green, it'd be great if you could also be programmed to deliver lunch |
12:25 |
pinesol_green |
rfrasur: Mr. Spock: Something fascinating just happened. |
12:25 |
pinesol_green |
rfrasur: I am only a bot, please don't think I'm intelligent :) |
12:34 |
|
smyers_ joined #evergreen |
12:38 |
|
akilsdonk joined #evergreen |
12:44 |
bshum |
depesz's email to the list is fascinating reading. |
12:44 |
depesz |
hope it will help a bit. |
12:44 |
* csharp |
agrees |
12:44 |
bshum |
depesz++ for sharing |
12:44 |
csharp |
depesz++ |
12:46 |
kmlussier |
Doodle poll for October dev meeting is at http://www.doodle.com/4m6xg8p3qdpusvsn. |
12:46 |
eeevil |
depesz++ # indeed |
12:47 |
depesz |
if anything in that mail/code is not clear, please let me know. |
12:47 |
eeevil |
depesz: fwiw, we use the fast-start properties of cursors in plpgsql for other purposes, too, so no worries about relying on that here :) |
12:47 |
depesz |
eeevil: :) |
12:51 |
mrpeters |
following up on services dying discussion from friday --- just discovered memcache was running with just 64MB of ram....have a good feeling this is the culprit |
12:51 |
jeff |
mrpeters: what's your theory as to why that would cause services to die? |
12:52 |
mrpeters |
not so much the services dying....the people being unable to login part |
12:53 |
mrpeters |
because the services are still running |
12:53 |
mrpeters |
people just can't log in |
12:53 |
mrpeters |
so my thinking is memcache is getting full |
12:53 |
paxed |
depesz: when reading your post on the db query improvements, i get the feeling of ancient times, when people hand-crafted assembly :) |
12:53 |
depesz |
:) |
12:53 |
bshum |
I really hated assembly class. |
12:53 |
bshum |
It's the main reason I think I switched majors in college. |
12:54 |
bshum |
That and Calculus 2. |
12:57 |
rfrasur |
I'd switch my majors now to comp sci/programing...except for the whole having graduated thing. |
12:57 |
mrpeters |
so, jeff, i could be way off base...but i think we can agree 64MB is too low :P |
12:57 |
* rfrasur |
loved calculus |
12:57 |
* mrpeters |
failed calculus 3 times |
12:57 |
mrpeters |
and my 2 roomates were actuaries |
12:57 |
mrpeters |
i was hopeless at calculus |
12:57 |
mrpeters |
i finally passed though haha |
12:57 |
rfrasur |
hehe |
13:03 |
rfrasur |
I honestly still am not quite sure of the value (unless you're going into quantum physics or astronomy or some other theoretical something. I just liked it because it was puzzly. |
13:05 |
jeff |
mrpeters: agreed. 64 MB is low for memcached, especially when caching covers/etc. If you find that that resolves your auth problem, I'd be interested in pulling at that thread to see why. |
13:05 |
mrpeters |
yeah, ill have to wait and see |
13:10 |
kmlussier |
eeevil: FWIW, Dyrcona already created a git branch for the first proposed change from depesz. bug 1234845 |
13:10 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1234845 |
13:11 |
eeevil |
kmlussier: cool. I hadn't seen that. I'll pitch in there if there's anything left to be done :) |
13:11 |
kmlussier |
eeevil++ |
13:16 |
|
RoganH joined #evergreen |
13:41 |
|
rndall joined #evergreen |
13:42 |
rfrasur |
the agony of buying a computer that matters |
13:43 |
* bshum |
is still waiting for the new thinkpads to come along. |
13:43 |
* RoganH |
thinks that bshum is a hardware addict. |
13:43 |
rfrasur |
This is for the office. The one ring to rule them all and all that. |
13:44 |
rfrasur |
RoganH, I think he may be in good company |
13:44 |
bshum |
RoganH: I think I've owned like 4 smartphones in the last couple years. |
13:44 |
bshum |
And I'm waiting for the Nexus 5 to see what that's like :D |
13:44 |
* bshum |
is a proud hardware addict |
13:44 |
RoganH |
bshum: I have had a new smartphone every year for the last five years. |
13:44 |
RoganH |
bshum: And if Verizon will carry the nexus 5 I think I will find myself carrying two phones. |
13:44 |
jeff |
interesting. a patron email address (likely from migration) with a < character is displayed in the staff client (running on OS X as a winebottled win32 app) displays the unicode square "i don't know this character" with 003c in the square (which is 'LESS-THAN SIGN') |
13:45 |
jeff |
i wonder if that's a quirk of how i'm running the staff client, or something else. |
13:45 |
rndall |
hello everybody, I'd want to know where can I find who created a user in evergren? |
13:45 |
jeff |
odd, anyway. i think i've seen that in one other area, but i'm not sure which. possibly with a checkbox in All Cards. |
13:46 |
jeff |
rndall: Evergreen does not keep track of that information by default in the database. You'd likely need to dig through logs, if you still have the logs from the time period in question. |
13:47 |
rndall |
jeff: What is the log name of the log I have to look for? |
13:47 |
jeff |
I've occasionally had desire for Evergreen to track that info -- either creator or editor on actor.usr -- as well as edit time (what counts as an "edit" being one question to answer)... |
13:50 |
jeff |
rndall: in a default configuration, you'd be looking at the information in osrfsys.log, but your install may have logging set up differently. Your systems administrator (if that isn't you) should know. It would be a bit of a needle in a haystack -- you'd be looking for a call to the method open-ils.actor.patron.update and then you'd take the auth token and use that to find the login log entry for that user... |
13:50 |
jeff |
rndall: (let me know if that truncated before "for that user..." |
13:51 |
jeff |
rndall: you'd likely limit your search to the time period around the create_date timestamp for the created user in question. |
13:55 |
|
smyers_ joined #evergreen |
13:55 |
mllewellyn |
I have a question about electronic cancellations. The cancellation shows at the copy level and the lineitem level, but the item created when the PO was activated is still in the catalog. Is there a setting that causes an item to be deleted when a lineitem is cancelled through EDI? |
13:55 |
mllewellyn |
Have we missed doing something? Or is this a bug? |
13:55 |
kmlussier |
Sounds familiar. |
13:56 |
mllewellyn |
kmlussier, you're going to give me a link to a bug ticket, aren't you. :) |
13:56 |
* kmlussier |
is looking. |
13:57 |
mllewellyn |
I'm looking at this https://bugs.launchpad.net/evergreen/+bug/978095 |
13:57 |
kmlussier |
I can't remember if it's a bug ticket or just discussion among our acq people here. |
13:57 |
pinesol_green |
Launchpad bug 978095 in Evergreen 2.4 "Acq: lineitems display as "on order" even after all copies have been cancelled" (affected: 4, heat: 22) [Medium,Confirmed] |
13:57 |
mllewellyn |
It's similar but not quite the same, becuase the lineitem display did change to a beautiful blue. |
13:57 |
kmlussier |
mllewellyn: Here it is! https://bugs.launchpad.net/evergreen/+bug/1175740 |
13:57 |
pinesol_green |
Launchpad bug 1175740 in Evergreen "Acq: Certain workflows produce orphaned fund debits" (affected: 2, heat: 14) [Undecided,Triaged] |
13:57 |
mllewellyn |
And it says cancelled. |
13:58 |
kmlussier |
And there's code attached. |
13:58 |
* kmlussier |
should have tested that code before 2.5. |
13:59 |
mllewellyn |
hm, talking about debits, but not orphaned items in the OPAC. |
13:59 |
kmlussier |
No, if you read further down, it talks about deleting copies too. |
13:59 |
mllewellyn |
Oh, talk of a warning. |
13:59 |
kmlussier |
But it looks like it only happens if the lineitem is deleted, not canceled. |
14:00 |
mllewellyn |
When the ordersp comes in, the library staff wouldn't be watching, let alone see a warning about deleting the copy. |
14:01 |
kmlussier |
mllewellyn: Sure, that's probably why it happens when the lineitem is deleted instead of canceled. |
14:02 |
mllewellyn |
My librarians seem to want the copy deletion to be automatic when the lineitem is cancelled. |
14:02 |
kmlussier |
It might be nice to have an org setting to say that the copy is deleted if a lineitem is canceled with a reason where keep debits is false. |
14:02 |
mllewellyn |
though these are backorders, so I can see keeping them. |
14:03 |
kmlussier |
Oh, for backorders, I think we would want to keep the copies. |
14:03 |
mllewellyn |
If a lineitem can be uncancelled when the item is finally sent? |
14:03 |
mllewellyn |
Or can you received a cancelled/backordered lineitem? |
14:04 |
kmlussier |
Well, there's another LP bug related to that. ;) |
14:04 |
mllewellyn |
Ah, sorry. |
14:04 |
kmlussier |
mllewellyn: It looks like you can now. Though it probably isn't on your system yet. It was just merged a couple of weeks ago. https://bugs.launchpad.net/evergreen/+bug/1206649 |
14:05 |
pinesol_green |
Launchpad bug 1206649 in Evergreen "Receiving canceled lineitem / copy not fully implemented" (affected: 3, heat: 16) [Undecided,Fix committed] |
14:05 |
mllewellyn |
Several I see. |
14:06 |
mllewellyn |
Ah, I'll ask Ben about it. Thanks! |
14:07 |
rfrasur |
(I hope this computer has the sound of angels singing when it's unboxed.) |
14:08 |
bshum |
rfrasur: That would make for an excellent ringtone. |
14:09 |
rfrasur |
bshum: based on the new AT&T commercials...they may actually already have one. |
14:14 |
rfrasur |
(BTW dude, just because I forgave your fine doesn't mean I believed your story.) |
14:14 |
|
cjohnson joined #evergreen |
14:15 |
bshum |
mllewellyn: So that receiving canceled stuff went in 9/16, and our upgrade was 9/7. So no, we don't have that yet. |
14:17 |
mllewellyn |
bshum, that's OK, I don't think it's an issue YET. But I'm looking ahead. |
14:17 |
bshum |
mllewellyn: I imagine we'll get there during our next incremental upgrade. I expect we'll have one to resolve some final 2.5 quirks. |
14:17 |
bshum |
Looking ahead is good. |
14:30 |
jeff |
it's right up there with "don't use regex to 'parse' XML", but i find myself crafting a regex for patron email validation. |
14:30 |
jeff |
in postgresql-speak, my current stab looks like this: email !~ '^[a-zA-Z0-9\._+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9\.-]+$' |
14:30 |
jeff |
i'm trying to err on the side of permissiveness. |
14:38 |
rfrasur |
Hah! Bought 1 computer for $1k and two more for $100 (including an HDMI to VGA adaptor). |
14:38 |
remingtron |
jeff: permissiveness is good |
14:41 |
jeff |
remingtron: agreed. mostly i'm trying to help prevent things like "NONE", 'N/A", "no e-mail", and "(mom) userexample.com" |
14:41 |
jeff |
not to mention "lives at [city] address from june thru aug" |
14:42 |
csharp |
we have lots of that kind of data :-/ |
14:42 |
remingtron |
jeff: you are a noble man |
14:42 |
remingtron |
jeff++ |
14:43 |
jeff |
since we have the option to invalidate those address while preserving their old contents, my plan is to do so -- and institute the regex to help prevent some in the future. |
14:44 |
jeff |
also lots of common providers where the .com gets dropped. |
14:45 |
remingtron |
sadly, it's harder to prevent personyaho.com |
14:45 |
remingtron |
but those are more rare, I suppose |
14:46 |
jeff |
right. there's code out there for performing a domain name validation on the address when entered -- tsbere worked on that. |
14:46 |
jeff |
but i think in the specific case of yaho.com it would pass that check, since the domain "exists" |
14:48 |
|
smyers_ joined #evergreen |
14:53 |
|
akilsdonk joined #evergreen |
14:56 |
jeff |
only 509 addresses fail to validate with that regex. |
14:58 |
|
sseng_ joined #evergreen |
15:17 |
tsbere |
remingtron/jeff: Always fun when you get "user at example dot com" actually entered into the field. <_< |
15:18 |
jeff |
i have one "userexample.com / no solicitation" |
15:18 |
jeff |
also one "userexample.com MM.DD.YY [staff initials]" |
15:19 |
jeff |
(where YY.MM.DD is >13 years ago) |
15:20 |
tsbere |
even WITH the regex in place and us supposedly having thrown out most of the bad data we still have 105 without an @ in them. :( |
15:20 |
* tsbere |
wonders about the one that is just =, as well as the various timestamps... |
15:20 |
jeff |
does the regex enforce an @, or are those just values that haven't yet been invalidated? |
15:21 |
jeff |
timestamps sound almost like bad migrated data, or "ILS before the last ILS used that field for $OTHER_PURPOSE" |
15:21 |
tsbere |
The regex should force them to have a localpart, @, and domainpart |
15:22 |
tsbere |
Looks like the timestamps are from our newest member's migration, so who knows what caused that |
15:22 |
tsbere |
But the phone numbers, Mailing addresses, just the domain part, what could be just the localpart OR passwords of some kind, "NOT YET CIRCULATING ONLINE"... |
15:23 |
tsbere |
localpart.domain.ext instead of localpartdomain.ext |
15:23 |
tsbere |
# instead of @, 2 instead of @... |
15:25 |
jeff |
yep. |
15:25 |
jeff |
sorry, didn't mean to distract you down this rabbit hole also :-) |
15:27 |
tsbere |
I poke this every so often anyway ;) |
15:28 |
jeff |
good. :-) |
15:33 |
|
jboyer-isl joined #evergreen |
15:33 |
|
remingtron joined #evergreen |
15:34 |
|
Callender_ joined #evergreen |
15:35 |
|
j_scott joined #evergreen |
15:53 |
|
roses joined #evergreen |
15:54 |
roses |
Does anyone have a report that picks up cash/credit card amounts from a self checkout machine/sip user? |
16:06 |
dbwells |
grabbing 0838 |
16:06 |
|
mrpeters left #evergreen |
16:09 |
|
akilsdonk joined #evergreen |
16:13 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] OPAC: Make advanced search -> numeric search -> bib cn hone in on right target - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a2430db> |
16:13 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] The identifier|bibcn field is best served by having no normalizers applied - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2cb2011> |
16:13 |
pinesol_green |
[evergreen|Dan Wells] Stamping 0838 - remove bibcn normalizers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9e8baba> |
16:37 |
|
ericar joined #evergreen |
16:45 |
csharp |
roses: I do have one, but don't have time right this minute to dig it up |
16:52 |
roses |
csharp: Thanks |
16:58 |
roses |
csharp: can you email me when you have the time (rose.schoofflva.virginia.gov) Thanks. |
17:10 |
|
mmorgan left #evergreen |
17:28 |
|
DPearl joined #evergreen |
19:01 |
|
sseng joined #evergreen |
20:16 |
|
mtcarlso- joined #evergreen |