| Time |
Nick |
Message |
| 01:34 |
|
dcook joined #evergreen |
| 02:57 |
|
eady joined #evergreen |
| 07:14 |
|
dbwells_ joined #evergreen |
| 07:18 |
|
pmurray_` joined #evergreen |
| 07:20 |
|
BigRig_ joined #evergreen |
| 07:29 |
|
paxed joined #evergreen |
| 07:31 |
|
graced joined #evergreen |
| 07:33 |
|
jeffdavi1 joined #evergreen |
| 07:33 |
|
dkyle2 joined #evergreen |
| 07:33 |
|
egbuilder_ joined #evergreen |
| 07:33 |
|
Bmagic joined #evergreen |
| 07:33 |
|
artunit joined #evergreen |
| 07:33 |
|
gmcharlt joined #evergreen |
| 07:33 |
|
rangi joined #evergreen |
| 07:33 |
|
phasefx joined #evergreen |
| 07:39 |
csharp |
I wasn't around for the big DOB discussion yesterday, but fwiw, we use DOB as a matching criterion for patron de-duplication - in fact, our staff depend on it heavily |
| 07:40 |
|
jboyer-isl joined #evergreen |
| 07:40 |
|
pmurray joined #evergreen |
| 07:42 |
csharp |
vaguely related: a soon-to-be-coming feature request from GPLS/PINES will be a "potential duplicate patrons matcher" interface (similar in concept to the Admin -> Local Administration -> Transit List) where you could match patrons with the same (say) first name, last name, and DOB and scope those matches to your library or system or to the whole consortium to find duplicates |
| 07:42 |
csharp |
s/duplicates/potential duplicates/ |
| 07:44 |
csharp |
oh, and we require DOB as a matter of policy, and for patrons who don't want to provide DOB, we use the magical date of 1901-01-01 (we're betting that there are no living patrons with that actual birthdate, of course ;-) ) |
| 07:46 |
|
jboyer-isl joined #evergreen |
| 07:57 |
|
rjackson_isl joined #evergreen |
| 08:09 |
|
krvmga joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:12 |
|
Dyrcona joined #evergreen |
| 08:20 |
|
mrpeters joined #evergreen |
| 08:21 |
|
akilsdonk joined #evergreen |
| 08:24 |
|
ericar joined #evergreen |
| 08:30 |
|
mmorgan joined #evergreen |
| 08:38 |
|
maryj joined #evergreen |
| 08:39 |
|
maryj joined #evergreen |
| 08:47 |
* kmlussier |
seems to recall a grocery discussion in here a few months ago. |
| 08:49 |
kmlussier |
+1 to renaming it |
| 08:49 |
* jboyer-isl |
no longer sees the groceries; there's a rutabega, that's a squash, over here is a pod of peas. |
| 08:50 |
jboyer-isl |
Will you take the blueberry or the raspberry? |
| 08:51 |
mmorgan |
+1 from me, too. |
| 08:55 |
mmorgan |
Found the previous discussion: http://irc.evergreen-ils.org/evergreen/2015-01-08#i_148257 |
| 08:55 |
kmlussier |
heh, I was just about to post that link. mmorgan beat me to it. |
| 08:55 |
kmlussier |
mmorgan++ |
| 08:58 |
jboyer-isl |
I'm a fan of "manual" since that gets the human-generated part across. I don't particularly care for "staff" |
| 08:58 |
|
jwoodard joined #evergreen |
| 09:04 |
|
Shae joined #evergreen |
| 09:09 |
jboyer-isl |
Well, that was potentially exciting. Apparently the query planner was quite loathe to give up the age_protect index I just put together and tried to discard. Table locks ahoy! |
| 09:15 |
dbwells |
We switched "Grocery" to "General" locally a while back. It's not a perfect label, but it stopped the complaints. Other terms to consider: "Direct", (or if we want to be really literal) "Transactionless", or even "None" (since these are bills not tied to what EG calls a "transaction"). |
| 09:21 |
|
yboston joined #evergreen |
| 09:26 |
eeevil |
dbwells: well, that's not really true. money.grocery and money.circulation are both child tables of money.billable_xact |
| 09:27 |
eeevil |
</pedant> |
| 09:27 |
dbwells |
eeevil: I was actually just looking at that (not remembering how "grocery-ness" was captured) :P |
| 09:33 |
dbwells |
makes sense. So it is a transaction, but just one with the sole purpose (from a system perspective) of GETTING MONEY :) |
| 09:34 |
Dyrcona |
M-O-N-E-Y... |
| 09:34 |
* Dyrcona |
is listening to Lyle Lovett at the moment. |
| 09:35 |
tsbere |
I know some libraries have asked if they can put negative grocery bills in for "they put money on their card ahead of time" >_> |
| 09:35 |
tsbere |
Intended to deal with rental fees and such instead of paying out each time they grab a rental item |
| 09:35 |
* tsbere |
never had a good answer for them |
| 09:37 |
jboyer-isl |
tsbere: isn't that what the patron credit option is for? (or is that not allowed and they doing this goofy negative bill thing anyway?) |
| 09:37 |
jonadab |
We've had patrons do that (put a credit on their account), but we hate it because it confuses the staff. (Part of the problem is that our existing ILS doesn't automatically apply the credit to new charges when they later occur. That has to be done manually, using the "pay" interface.) |
| 09:37 |
kmlussier |
Yes, that is what I was thinking. The patron credit. |
| 09:38 |
kmlussier |
But is there a way to just add patron credit? I thought the only way to put money there was to convert change to a patron credit. |
| 09:38 |
eeevil |
jboyer-isl: that is what it's for, but getting money into that is non-trivial -- there's not "put money on in their credit pile" interface. that would be nice, though |
| 09:38 |
jboyer-isl |
I see. |
| 09:38 |
Dyrcona |
I'm surprised our members would be interested in giving patrons credit. Most of them seem dead set against negative balances. |
| 09:38 |
eeevil |
kmlussier: zackly :) |
| 09:40 |
kmlussier |
But patron credit doesn't really create a negative balance, so I think it could work well in this situation if an interface was created for it. |
| 09:40 |
kmlussier |
And good training provided. I don't think we see a lot of use of the patron credit feature around these parts. |
| 09:42 |
csharp |
patron credit has always been against PINES policy, so we've disabled its display with every upgrade |
| 09:42 |
csharp |
well, until it became a YAOUS |
| 09:43 |
* Dyrcona |
thinks circ/billing needs an overhaul. |
| 09:43 |
* Dyrcona |
has unpopular thoughts. |
| 09:43 |
* csharp |
, who is currently trying to create reports for bills/payments billed/received at specific libraries, agrees with Dyrcona |
| 09:43 |
jboyer-isl |
How is patron credit even stored? I was going to see if it's even possible to use in consortia where payments are allowed anywhere and the money redistributed, but I can't find where the balances are kept. |
| 09:44 |
csharp |
it's very cumbersome to trace billings/payments back to specific libraries for reports purposes |
| 09:44 |
* jboyer-isl |
needs to add some odd to balance all of these events. |
| 09:44 |
jboyer-isl |
evens. Bah. |
| 09:44 |
csharp |
we at least need another view, but I haven't figured out what it should look like |
| 09:45 |
csharp |
jboyer-isl: it's on the actor.usr object |
| 09:46 |
* csharp |
thinks for consistency that it should not be on actor.usr, but exist in an money.patron_credit_map table |
| 09:46 |
jboyer-isl |
Whoa! That's off limits then. There's absolutely no way to determine where that was originally depostied for "pay me" purposes. I guess we won't ever offer that. |
| 09:46 |
csharp |
or somethin' |
| 09:47 |
jboyer-isl |
csharp: it would be ugly, but if that proposed table had entries for each deposit location it could be very useful. |
| 09:47 |
jboyer-isl |
Though I do like the simplicity of the "we're not a bank" stance. |
| 09:49 |
jonadab |
We're not a bank. We're more of an internet cafe and a video store, rolled into one. |
| 09:50 |
jboyer-isl |
jonadab++ |
| 09:51 |
csharp |
jboyer-isl: "we're not a bank" is exactly the rationale behind the PINES policy |
| 09:53 |
csharp |
http://pines.georgialibraries.org/annual-meeting-2006#AI4 |
| 09:53 |
csharp |
that was actually before PINES went live |
| 09:58 |
* csharp |
goes back to trying to figure out why his "payments received at my library" report is busted |
| 09:58 |
jboyer-isl |
csharp: can you share a paste of the sql you're getting (or using, if this is a manual thing) |
| 09:58 |
|
tsbere_ joined #evergreen |
| 10:02 |
csharp |
jboyer-isl: it's a template I'm trying to create... here's the generated SQL (edited for readability): http://pastie.org/10054941 |
| 10:02 |
csharp |
it's apparently a fieldmapper issue, because the problem is that money.billable_xact doesn't have a "billing_total" column |
| 10:05 |
jeff |
csharp: what are you trying to report on? |
| 10:07 |
csharp |
jeff: the request is a report for "total amount paid to the library during a specified period of time" and they want to see the total billing amount in the output rows |
| 10:08 |
jboyer-isl |
mbx doesn't have any money related columns, so it definitely sounds like a fieldmapper issue. Does this report do anything when you run it or do you get an error message? |
| 10:08 |
csharp |
DBD::Pg::st execute failed: ERROR: column a6ab8ad791a40039d0a9a9cb75b7f4df.billing_total does not exist |
| 10:08 |
csharp |
LINE 6: "a6ab8ad791a40039d0a9a9cb75b7f4df"."billing_total" AS "Tota... |
| 10:08 |
csharp |
^ at /openils/bin/clark-kent.pl line 217. |
| 10:09 |
csharp |
mbx has that as a virtual field (linked from reporter.xact_billing_totals) |
| 10:11 |
jeff |
csharp: and what should the value in "total billing amount" represent? |
| 10:12 |
|
TaraC joined #evergreen |
| 10:17 |
jboyer-isl |
There's a might_have link from mbt to rxbt for total_balance, but there are nothing but inner joins in that sql (and nothing to rxbt). That will make it hard to get what you're looking for. |
| 10:17 |
jeff |
csharp: also, something of note in your paste -- you seem to be limiting to voided payments, which are pretty rare (nigh-on "unsupported" rare) -- AND mdpv."voided" = 't' |
| 10:17 |
jboyer-isl |
billing_total, rather. |
| 10:19 |
csharp |
jeff: good catch - I reversed the logic in my head |
| 10:20 |
csharp |
jboyer-isl: yeah, I figured there were other problems with the template, but "not working at all" wasn't the problem I was anticipating ;-) |
| 10:20 |
jeff |
i'd be surprised if this returned anything other than a single row: select count(*), voided from money.payment group by voided; |
| 10:21 |
csharp |
huh - there are 16 voided payments |
| 10:21 |
jeff |
neat. |
| 10:22 |
csharp |
but your point remains - I can probably drop the filter ;-) |
| 10:22 |
jeff |
i don't think there's a way to void from the staff client, and i'm not sure if SIP or even the API support it either, I think the last time I looked it was possible only by direct database manipulation (or, you know... migrations!) |
| 10:23 |
jeff |
well, pcrud probably lets you void 'em, now that i think about it. |
| 10:23 |
jeff |
last time i looked was long ago. |
| 10:24 |
jboyer-isl |
Something else to think about csharp, the rxbt view that this report wants to use includes voided bills in the total, there's an unvoided column if that's what the libs really want. (you know, when it's all plumbed properly) |
| 10:26 |
dbs |
kmlussier++ # linking to previous discussions |
| 10:26 |
dbwells |
csharp: getting back to your original question, I think you're right, there is a bug in the IDL. "billing_total" and "payment_total" on mbt should be reporter:datatype="link", not "money" (methinks). |
| 10:27 |
dbs |
mmorgan++ |
| 10:28 |
dbwells |
csharp: they're already defined in <links>, so I think just the datatype is off |
| 10:28 |
mmorgan |
csharp++ # opening the bug ticket! |
| 10:29 |
Stompro |
Migration press-release posted :-) - http://esilibrary.com/lake-agassiz-and-nw-regional-choose-evergreen/ |
| 10:30 |
kmlussier |
Stompro++ |
| 10:30 |
kmlussier |
Congratulations! |
| 10:31 |
mmorgan |
Stompro++ |
| 10:32 |
krvmga |
Stompro++ |
| 10:32 |
krvmga |
Grats! |
| 10:33 |
Stompro |
Thanks, we are all very excited. |
| 10:33 |
csharp |
Stompro++ |
| 10:34 |
csharp |
dbwells++ # excellent |
| 10:34 |
jboyer-isl |
dbwells: Oh, I missed that the types were "money" for both of those. Mystery (probably!) solved. :D |
| 10:34 |
csharp |
yeah - I'll test |
| 10:35 |
berick |
hackfest proposal, hood river style: http://assets-s3.mensjournal.com/img/essential/where-to-learn-to-kiteboard-hood-river-or/618_348_where-to-learn-to-kiteboard-hood-river-or.jpg |
| 10:35 |
jboyer-isl |
Quick note: money.grocery has the same issue (just happened to see it at the top of my screen) |
| 10:35 |
csharp |
berick++ |
| 10:35 |
csharp |
@praise berick |
| 10:35 |
* pinesol_green |
Shall I compare berick to a summer's day? berick is more lovely and more temperate. |
| 10:35 |
berick |
gotta love the snow-capped mountain |
| 10:35 |
berick |
hah |
| 10:37 |
* kmlussier |
re-arranges here conference schedule so that she can learn to kiteboard. |
| 10:45 |
jboyer-isl |
csharp, dbwells: This search is illustrative in vim: /oils_persist\:virtual="true" reporter\:datatype="[^l] |
| 10:45 |
jboyer-isl |
A surprising number of hits, not all of which can I tell if they can/do work or now. |
| 10:45 |
jboyer-isl |
not. |
| 10:52 |
csharp |
jboyer-isl: thanks for that tip |
| 11:06 |
|
jboyer-isl joined #evergreen |
| 11:07 |
|
jboyer-isl joined #evergreen |
| 11:17 |
|
Newziky1 joined #evergreen |
| 11:17 |
|
sal_ joined #evergreen |
| 11:20 |
|
dcook__ joined #evergreen |
| 11:37 |
|
dMiller_ joined #evergreen |
| 11:48 |
|
jeffdavis joined #evergreen |
| 11:59 |
|
graced joined #evergreen |
| 12:01 |
|
maryj joined #evergreen |
| 12:08 |
|
bmills joined #evergreen |
| 12:09 |
|
jihpringle joined #evergreen |
| 13:52 |
|
Newziky joined #evergreen |
| 14:01 |
|
BigRig_ joined #evergreen |
| 14:17 |
|
Newziky joined #evergreen |
| 14:25 |
* dbs |
suspects bugs like bug 1436983 should have a title prefix like "Web Staff Client: " or something to define where the problem is occurring |
| 14:25 |
pinesol_green |
Launchpad bug 1436983 in Evergreen "Calendar widget does not work in Firefox" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1436983 |
| 14:25 |
* dbs |
prefixes that one accordingly |
| 14:26 |
* dbs |
adds "webstaffclient" tag for good measure |
| 14:28 |
dbs |
oh, there's "browserclient" already in unofficial use |
| 14:29 |
* dbs |
having fun with https://bugs.launchpad.net/evergreen/+manage-official-tags - moves "serials" with 30 related bugs from unofficial to official tag status |
| 14:29 |
bshum |
dbs++ |
| 14:31 |
* dbs |
moves a few open bugs from "browserclient" to "webstaffclient" |
| 14:44 |
|
Newziky joined #evergreen |
| 14:45 |
Dyrcona |
dbs++ |
| 14:45 |
Dyrcona |
webstaffclient is a better tag, imho. |
| 14:59 |
* kmlussier |
agrees with webstaffclient |
| 15:04 |
kmlussier |
I don't understand why some of the old browserclient-tagged bugs ever had that tag. For example, bug 1357037 is an issue in any client. |
| 15:04 |
pinesol_green |
Launchpad bug 1357037 in Evergreen "Additional sort order options when viewing purchase order line items" (affected: 2, heat: 10) [Wishlist,Confirmed] https://launchpad.net/bugs/1357037 |
| 15:06 |
dbs |
kmlussier: I was thinking the same thing, after I changed it, but was separating the simple activity of unifying tags from the more complex determination of whether the tag is relevant :) |
| 15:07 |
kmlussier |
dbs: Yeah, I know. The comment wasn't directed at you. It just had the effect of bringing the bug to my attention. :) |
| 15:55 |
gmcharlt |
metadata correction ==> coming across more metadata issues ==> metadata correction ==> coming across.... |
| 15:57 |
kmlussier |
It's like shelf reading in the children's room. :) |
| 15:57 |
gmcharlt |
*shudder*, *shudder* |
| 16:04 |
dbs |
Shelf reading the fairy tales section |
| 16:13 |
jonadab |
Can't be that much worse than the Chiltons. |
| 16:14 |
jonadab |
We also have at least one shelver with a strong dislike for the manga section. |
| 16:14 |
kmlussier |
I can imagine that the manga section would be difficult. That is, if you have a lot of manga. |
| 16:15 |
dbs |
As computer page in my first library job at the ripe old age of 14, I was given the responsibility of shelf reading the fairy tales. the memory burns |
| 16:16 |
jonadab |
Heh. |
| 16:16 |
jonadab |
We at one point had a volunteer remove from the shelf, scan for inventory, and then reshelve large sections of the collection, including the entire non-fiction section. |
| 16:17 |
kmlussier |
dbs: It didn't scare you away from libraries for good? |
| 16:35 |
|
vlewis joined #evergreen |
| 16:37 |
|
maryj joined #evergreen |
| 16:57 |
|
dMiller_ joined #evergreen |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:13 |
|
mmorgan left #evergreen |
| 17:46 |
|
buzzy joined #evergreen |
| 17:48 |
|
Newziky left #evergreen |
| 19:01 |
|
dMiller_ joined #evergreen |
| 19:21 |
|
dMiller_ joined #evergreen |
| 19:57 |
|
bmills left #evergreen |
| 20:54 |
|
bmills joined #evergreen |
| 21:42 |
|
dcook joined #evergreen |
