| Time |
Nick |
Message |
| 00:43 |
|
zerick2 joined #evergreen |
| 01:06 |
|
zerick2 joined #evergreen |
| 01:32 |
|
b_bonner joined #evergreen |
| 01:33 |
|
mtcarlson_away joined #evergreen |
| 01:35 |
|
zerick2 joined #evergreen |
| 02:34 |
|
dac joined #evergreen |
| 05:27 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:14 |
|
kbeswick joined #evergreen |
| 07:30 |
|
jboyer-home joined #evergreen |
| 07:38 |
|
rjackson-isl joined #evergreen |
| 07:44 |
|
collum joined #evergreen |
| 08:11 |
|
akilsdonk joined #evergreen |
| 08:15 |
|
timf joined #evergreen |
| 08:28 |
|
mrpeters joined #evergreen |
| 08:41 |
|
ericar joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:44 |
|
Shae joined #evergreen |
| 08:52 |
|
akilsdonk_ joined #evergreen |
| 08:53 |
|
kbeswick joined #evergreen |
| 09:10 |
|
mceraso joined #evergreen |
| 09:11 |
|
yboston joined #evergreen |
| 09:13 |
|
ericar joined #evergreen |
| 09:31 |
|
tspindler joined #evergreen |
| 09:33 |
|
mllewellyn joined #evergreen |
| 09:39 |
|
Dyrcona joined #evergreen |
| 10:02 |
|
ldw joined #evergreen |
| 10:07 |
|
JennyBlue joined #evergreen |
| 10:08 |
JennyBlue |
Hello........ If I install the Evergreen client 2.5.4 or 2.6.0 in windows 8 do I will get any error? |
| 10:11 |
mrpeters |
JennyBlue no, you shouldnt |
| 10:11 |
mrpeters |
Windows 8 has been out a while now, and I know many libraries use it without issues. |
| 10:11 |
JennyBlue |
So it should work fine? |
| 10:11 |
mrpeters |
yes |
| 10:11 |
tsbere |
JennyBlue: That depends, are you connecting to a 2.5.4 or 2.6.0 server that accepts the staff client you are installing? |
| 10:12 |
JennyBlue |
both... |
| 10:12 |
JennyBlue |
the local and the server... 2.6.0 I am planning to upgrade my OS to winodws 8 I wonder if I get incompatibility issues |
| 10:13 |
|
ldw joined #evergreen |
| 10:13 |
mrpeters |
you should be fine, JennyBlue, at least with Evergreen. |
| 10:13 |
JennyBlue |
Thanks sir... |
| 10:13 |
JennyBlue |
evergreen = <3 |
| 10:24 |
|
tfaile joined #evergreen |
| 10:24 |
|
BigRig joined #evergreen |
| 10:25 |
|
Callender joined #evergreen |
| 10:28 |
|
dkyle joined #evergreen |
| 10:32 |
|
RoganH joined #evergreen |
| 11:19 |
|
RoganH joined #evergreen |
| 12:09 |
|
dac joined #evergreen |
| 12:16 |
|
gsams joined #evergreen |
| 12:37 |
|
kmlussier joined #evergreen |
| 12:37 |
|
JLDAGH joined #evergreen |
| 12:38 |
|
JLDAGH joined #evergreen |
| 12:41 |
bshum |
wow.... VTLS is bought out by III |
| 12:41 |
bshum |
Another one bites the dust |
| 12:51 |
collum |
At least they didn't do it on April Fool's day this time. |
| 12:52 |
gsams |
I'm having an odd problem with email notifications not having a sender address. |
| 12:53 |
gsams |
I'm finally moving into the action/trigger setup, and I have the library settings editor email addresses set |
| 12:53 |
tsbere |
gsams: Given that is a template issue we would need to have the "From" (at least) on the template. |
| 12:53 |
gsams |
From: [%- params.sender_email || default_sender %] |
| 12:53 |
tsbere |
gsams: Also, amazingly enough, I don't think the A/T setup, by default, does anything with the library settings. Though you can make it do so. |
| 12:54 |
tsbere |
gsams: Well, sender_email would be event template specific and isn't set by default. default_sender is, I think, in opensrf.xml |
| 12:54 |
gsams |
hmm. |
| 12:55 |
tsbere |
gsams: We use this format in most of ours: From: "[% user.home_ou.name %]" <[% params.sender_email || helpers.get_org_setting(user.home_ou.id, 'org.bounced_emails') || default_sender %]> |
| 12:55 |
tsbere |
gsams: Note that we always send these out with the user's home ou as the "sender" as if they bounce that is the library that should be dealing with it. Your policies may vary. |
| 12:56 |
gsams |
tsbere: indeed, that is what I am shooting for as well here. |
| 12:58 |
gsams |
tsbere: it appears that I am a bit too behind in version for that to work properly? |
| 12:58 |
tsbere |
gsams: Also note that to get home_ou.name we extend the environment to include usr.home_ou (from whatever it came from) |
| 12:58 |
gsams |
or that perhaps |
| 12:59 |
tsbere |
gsams: Click on the name (instead of double-click on the row) and change whatever contains "usr" to have .home_ou after it. If there is already something after it add a new entry with home_ou just after usr. |
| 12:59 |
tsbere |
(that is in field_path) |
| 13:01 |
gsams |
tsbere: that did the trick, now its just bouncing off of my city's email firewall... |
| 13:01 |
gsams |
but, it did at least work! |
| 13:01 |
|
ericar joined #evergreen |
| 13:02 |
tsbere |
gsams: We also have the bounced_emails setting set to a locally run mailing list for all libraries, which we then sign staff members up for, to avoid issues with anti-spam measures. |
| 13:03 |
tsbere |
(aka, we are always the sender, even if the library uses someone else for email |
| 13:04 |
gsams |
tsbere: very nice, I might have to take a stab at that idea myself |
| 13:04 |
gsams |
tsbere++ |
| 13:21 |
|
bmills joined #evergreen |
| 13:47 |
|
hbrennan joined #evergreen |
| 13:48 |
Dyrcona |
eeevil: Have you ever considered adding an array datatype in the IDL that can translate from Pg arrays to Perl arrayrefs? |
| 13:51 |
eeevil |
Dyrcona: no, for several reasons: it's not language agnostic, it's more complicated than it seems, and (generally speaking) if you're using an array in SQL (short of reports) you're probably doing it wrong (for some definition of "you" and "wrong") ;) |
| 13:51 |
eeevil |
(there are, obviously, exceptions to the last point, given specific circumstances) |
| 13:52 |
Dyrcona |
eeevil: Yeah, I thought you might have considered it. (And, I'm not taking the last bit personally.) |
| 13:52 |
eeevil |
Dyrcona: that said, if you're inside the storage app, you can already leverage magical arrays from DB data, via cdbi |
| 13:53 |
Dyrcona |
eeevil: Ah ha! So, I should look into moving this to action::publisher, then? |
| 13:53 |
eeevil |
that would be a way to leverage db-level magic in perl, aye |
| 13:54 |
|
jihpringle joined #evergreen |
| 14:16 |
|
ldw joined #evergreen |
| 14:27 |
* jeff |
looks to see if he has disagreement between money.open_usr_summary and reality |
| 14:29 |
Dyrcona |
jeff: What is this "reality" you speak of? |
| 14:45 |
jeff |
bah. xact_finish set on some transactions that have a balance_owed >0 |
| 14:48 |
jeff |
but none since our most recent upgrade, so there's that. |
| 14:49 |
jeff |
also, many, MANY fewer occurrences once i remember to exclude some things that should be excluded. :P |
| 14:49 |
jeff |
"don't know if this was the result of an old bug or an infrequent bug. better create a report to monitor just in case." :P |
| 15:02 |
tsbere |
jeff: Fun is when it isn't the result of a bug at all. "I thought it was a bug, but someone ran a DB query that bypassed all the middle layer code and broke the DB side" ;) |
| 15:02 |
jeff |
likely our friend bug 793550 |
| 15:02 |
pinesol_green |
Launchpad bug 793550 in Evergreen 2.3 "xact_finish (prematurely?) set on claimed returned item if transaction balance reaches zero" (affected: 7, heat: 38) [Medium,Fix released] https://launchpad.net/bugs/793550 |
| 15:02 |
jeff |
tsbere: yes, indeed! i try to be careful with things like that so that there's record of the batch update -- or avoid the batch update when possible. :-) |
| 15:03 |
|
kmlussier joined #evergreen |
| 15:03 |
tsbere |
jeff: Also fun when it is "old migration data" even years after the last migration that should have been involved. >_> |
| 15:06 |
* jeff |
nods |
| 15:07 |
jeff |
more and more i'm thinking of a db health check script. |
| 15:09 |
|
bmills1 joined #evergreen |
| 15:13 |
tsbere |
jeff: As in a "if any of the following queries return anything then something is wrong" type deal? |
| 15:14 |
jeff |
yeah. |
| 15:14 |
jeff |
an eg-db-fsck, if you will. |
| 15:15 |
jeff |
or just eg-db-check, etc. |
| 15:15 |
jeff |
sanity checks. not sure if it would be useful or not. might play with it to see. |
| 15:44 |
jeff |
I suppose that the money.open_usr_summary view excludes non-null xact_finish for performance reasons. |
| 15:44 |
jeff |
I wonder if the same could be had by excluding balance_owed = 0 |
| 15:52 |
|
kbutler joined #evergreen |
| 16:31 |
|
tspindler left #evergreen |
| 16:36 |
|
sseng joined #evergreen |
| 16:49 |
|
kmlussier left #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 20:29 |
|
dcook joined #evergreen |
| 21:12 |
|
dluch joined #evergreen |
| 21:14 |
|
bmills joined #evergreen |
| 21:19 |
|
dluch2 joined #evergreen |
| 21:43 |
|
dluch joined #evergreen |
| 22:51 |
|
dluch joined #evergreen |
