| Time |
Nick |
Message |
| 01:41 |
|
dbwells_ joined #evergreen |
| 01:41 |
|
remingtron_ joined #evergreen |
| 01:50 |
|
dbwells__ joined #evergreen |
| 02:40 |
|
remingtron joined #evergreen |
| 03:01 |
|
dbwells_ joined #evergreen |
| 03:13 |
|
dbwells joined #evergreen |
| 03:13 |
|
remingtron_ joined #evergreen |
| 04:07 |
|
remingtron joined #evergreen |
| 04:07 |
|
dbwells_ joined #evergreen |
| 04:14 |
|
remingtron_ joined #evergreen |
| 07:03 |
|
agoben joined #evergreen |
| 07:27 |
|
artunit_away joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:48 |
|
bos20k joined #evergreen |
| 09:01 |
jeff |
hrm. "adjust to zero" appears to make one payment per billing line item, even on a single transaction. |
| 09:02 |
|
mmorgan joined #evergreen |
| 09:11 |
|
Dyrcona joined #evergreen |
| 09:14 |
|
yboston joined #evergreen |
| 09:15 |
jeff |
Dyrcona: do you remember why "adjust to zero" makes one payment per billing line item on a transaction? |
| 09:15 |
jeff |
Dyrcona: or have you blocked everything about that from memory, and i should review commit logs, bug comments, and code comments? ;-) |
| 09:16 |
dbwells |
jeff: It is meant to prevent any possibility of the same billing being zeroed/adjusted more than once. The adjustments and billings are linked directly. |
| 09:16 |
Dyrcona |
jeff: I didn't write the adjust to zero code, just to be clear. ;) |
| 09:21 |
jeff |
Dyrcona: ah, my mistake! |
| 09:22 |
jeff |
dbwells: ah, i see the money.account_adjustment.billing column now. |
| 09:22 |
jeff |
interesting. |
| 09:23 |
dbwells |
Well, the roots of that design are certainly still firmly in the original "void payment" branch. I think it is fair to declare it a joint effort, or maybe a "dis-joint" effort. ;) |
| 09:24 |
jeff |
in terms of UI, it's a regression for us from our previous use of Forgive payments to handle that kind of thing. |
| 09:24 |
jeff |
but I like the link for this payment type. |
| 09:24 |
jeff |
and i don't think "looks worse in the UI" is reason to change that. |
| 09:25 |
jeff |
i think "improve display logic in the UI" might be a better option there. :-) |
| 09:25 |
dbwells |
jeff: I recall spending time trying to take that linkage out, only to put it back in again, as there are just certain cases where things can get so mangled. |
| 09:25 |
jeff |
or even grouping them in the middle layer if appropriate. it might have some things in similar with chained circs. |
| 09:27 |
|
maryj joined #evergreen |
| 09:30 |
|
DPearl joined #evergreen |
| 09:30 |
dbwells |
jeff: I definitely agree that the display logic improvement would be a good strategy. I've got a branch from two hack-a-ways ago which made some good progress on that. It's apalling to me sometimes how much useful but half-done stuff I have :( I need a new strategy, cause "when I have free time" is starting to mean "never". |
| 09:36 |
* mmorgan |
would also like to see account_adjustments grouped in the display. |
| 09:37 |
jeff |
at or around the same time, i think it could be helpful to group the billings (also grouped, in the case of contiguous daily overdue billings, for example) and payments chronologically, rather than in two different areas of the interface. |
| 09:38 |
jeff |
should make it far easier for frontline staff to make sense of things. |
| 09:39 |
jeff |
heck, everyone. |
| 09:39 |
dbwells |
jeff: that's what it does! Now I really feel ashamed. Maybe we should look at this at the Hack-a-way? |
| 09:40 |
jeff |
dbwells: sure! in our free time! |
| 09:40 |
* jeff |
ducks |
| 09:42 |
dbwells |
jeff: unfortunately, the chronological mixing of bills/payments is what convicted me to try to move the billing timestamps. It's /possible/ to do it without that change, but not without gymnastics. |
| 09:45 |
* jeff |
nods |
| 09:45 |
jeff |
i still think that needs to be done. |
| 09:51 |
|
dbwells_ joined #evergreen |
| 10:17 |
Bmagic |
Anyone here know about this TT function called get_ccvm() ? I can't find the definition anywhere in the source. |
| 10:20 |
Bmagic |
Maybe it's a BLOCK that is dynamically created from the IDL? |
| 10:20 |
berick |
Bmagic: autogenerated function from EGCatLoader/Util.pm |
| 10:21 |
Bmagic |
Ah, thanks! |
| 10:21 |
berick |
it generates a number of functions for grabbing publicly visible data and caching the results |
| 10:23 |
Bmagic |
I see that now |
| 10:23 |
Bmagic |
clever |
| 10:23 |
Bmagic |
and confusing |
| 10:26 |
Bmagic |
There are a number of hallucinated perl functions from the IDL as well, that are relied upon by this :) |
| 10:27 |
Bmagic |
double runtime-invented stuff. It's all starting making sense |
| 10:29 |
tsbere |
Bmagic: It making sense may not be healthy. Perhaps you should back off for a bit ;) |
| 10:30 |
Dyrcona |
hah! |
| 10:33 |
|
kmlussier joined #evergreen |
| 10:33 |
Bmagic |
lol |
| 10:41 |
kmlussier |
+1 to display improvements for adjusted payments. |
| 10:42 |
kmlussier |
dbwells++ # Thanks for the explanation on why the bills are adjusted one at a time. That's a question a few people have raised with me. |
| 10:50 |
mmorgan |
Related thought: Some of our staff users would like a way to filter out from the display the payment types where no money was exchanged, like the adjustment and forgive payments. |
| 10:51 |
mmorgan |
When they look at a summary that shows the amount paid, they'd like to see the total of just what the patron has actually handed over. |
| 10:55 |
* jeff |
nods |
| 10:56 |
jeff |
not stated, but in my head, part of the work discussed earlier would be to exclude certain things from summary totals like "total paid" -- where adjustments / forgive wouldn't show there. |
| 10:56 |
jeff |
but it requires some thought and planning :-) |
| 10:57 |
mmorgan |
For sure! |
| 11:15 |
Bmagic |
miker and jeff and I have code here lp1174498 - after upgrading to 2.9 - I reworked it to treat the adjustments differently. Might be interested to some of you |
| 11:15 |
Bmagic |
LP 1174498 |
| 11:15 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" [Wishlist,Triaged] https://launchpad.net/bugs/1174498 |
| 11:17 |
csharp |
@dunno |
| 11:17 |
pinesol_green |
csharp: Yeah, well, you know, that's just like uh, your opinion, man. |
| 11:18 |
berick |
@band add Erlang Hoverboard |
| 11:18 |
pinesol_green |
berick: I'm sorry, Dave. I'm afraid I can't do that. |
| 11:23 |
Dyrcona |
Hmm... I thought one could age a circulation just by deleting it.... |
| 11:23 |
csharp |
Dyrcona: yep |
| 11:23 |
Dyrcona |
Well, it's not working on my training database with 2.10.5. |
| 11:24 |
csharp |
it should be a trigger on action.circulation |
| 11:24 |
Dyrcona |
It is. |
| 11:24 |
Dyrcona |
Maybe I should see exactly what the trigger does. |
| 11:24 |
csharp |
action_circulation_aging_tgr |
| 11:24 |
Dyrcona |
I tried deleting a single row from action.circulation but it is still there. |
| 11:25 |
tsbere |
Dyrcona: Does it have child circs? |
| 11:25 |
csharp |
it executes action.age_circ_on_delete() |
| 11:26 |
* tsbere |
believes that you need to delete the last circ in the chain, then the rest of the chain auto-deletes. Though he hasn't looked at that recently so he may be mistaken. |
| 11:26 |
Dyrcona |
tsbere++ That's it. |
| 11:26 |
Dyrcona |
I should delete the child circulation. |
| 11:27 |
Dyrcona |
That worked. Aged them both. |
| 11:27 |
csharp |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/090.schema.action.sql;h=c79793a32196ebbbebc13666326df3c3e3484c92;hb=refs/heads/rel_2_10#l264 |
| 11:27 |
Dyrcona |
Thanks, tsbere and csharp for the suggestions. |
| 11:43 |
|
bmills joined #evergreen |
| 11:49 |
|
sandbergja joined #evergreen |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:32 |
dbs |
Hmm. If I keep seeing #012 sprinkled in "no active transaction to rollback" and other database-related errors, is it potentially one bad cstore connection? |
| 12:33 |
dbs |
Like: "Call to open-ils.auth for method open-ils.auth.session.delete #012 failed [...] <404> Not enough params for method open-ils.auth.session.delete / service open-ils.auth#012#012" |
| 12:35 |
tsbere |
dbs: That looks more like something isn't parsing line break chars properly before making calls |
| 12:36 |
berick |
dbs: using rsyslog? config has '$EscapeControlCharactersOnReceive off' set somewhere? |
| 12:39 |
miker |
dbs: that's just, yeah, rsyslog |
| 12:40 |
miker |
tabs become #011, IIRC |
| 12:47 |
tsbere |
miker: I would assume they become #011, octal and all. |
| 12:59 |
dbs |
thanks y'all |
| 13:00 |
dbs |
linefeed I guess |
| 13:41 |
kmlussier |
abneiman++ # https://esilibrary.com/welcome-andrea/ |
| 13:44 |
abneiman |
:) thank you kmlussier |
| 13:46 |
JBoyer |
abneiman++ |
| 13:47 |
JBoyer |
It'll be difficult to get a bass to a conference for the Evergreen Musical Revue, but perhaps we can have one in Maryland someday? ;) |
| 13:47 |
Dyrcona |
abneiman++ |
| 13:48 |
bshum |
abneiman++ |
| 13:50 |
abneiman |
thanks all :) |
| 13:51 |
berick |
abneiman++ # very cool |
| 13:51 |
abneiman |
jboyer: I can bring it in my carry-on, right? |
| 13:52 |
JBoyer |
I'm no flight attendant; if it fits, it ships! |
| 14:01 |
csharp |
abneiman++ # congrats (again) :-) |
| 14:04 |
miker |
abneiman++ indeed |
| 14:06 |
abneiman |
thank you berick, csharp, miker ! |
| 14:42 |
|
bos20k_ joined #evergreen |
| 14:42 |
|
maryj_ joined #evergreen |
| 14:42 |
|
mmorgan1 joined #evergreen |
| 14:43 |
|
DPearl1 joined #evergreen |
| 14:45 |
Stompro |
Json Query question, is it possible to do a relative date comparison? like "due_date < now()-'14 days'::interval" ? |
| 14:47 |
Stompro |
I want to move the processing delay to the custom filter file, so I can add events for items that have different grace periods to the same event_def, so they will be combined when possible. |
| 14:57 |
* csharp |
sees that https://wiki.evergreen-ils.org/doku.php?id=documentation:tutorials:json_query doesn't have date examples |
| 14:57 |
miker |
Stompro: the short answer is "yes, and there's an analogous example in the json_query docs linked from the wiki" ... I don't have time to dig up the link atm, sorry, but I'm certain it's there. it boils down to using the functions behind the subtraction operator as a field transform |
| 14:58 |
csharp |
or maybe it does? :-) |
| 14:58 |
miker |
csharp: has, however, the time to dig up said doc :) |
| 14:58 |
csharp |
heh - I was just looking at it a few days ago |
| 14:58 |
miker |
csharp: not "date" specifically, but /any/ function can be used as a transform |
| 14:58 |
csharp |
ah gotcha |
| 14:59 |
* Dyrcona |
might have an example he can share. |
| 14:59 |
miker |
(and, age() might be all you need. untested...) |
| 15:01 |
Stompro |
miker, I think I found it, the example says that operators are not really checked. So something like "due_date":{ "now()-":"14 days"::interval ) |
| 15:01 |
Stompro |
I'm not sure if the ::interval is allowed.. I look for type casting examples. |
| 15:01 |
miker |
Stompro: I don't know that that will pass the "safe operator string" test |
| 15:02 |
miker |
and no, the cast won't work like that, but may not be needed depending on the other stuff in that specific clause |
| 15:02 |
miker |
it may be auto-casted. |
| 15:02 |
miker |
I suggest using the json_query tester to see what the sql will end up looking like |
| 15:04 |
* Stompro |
is off to find the json_query tester! |
| 15:04 |
Stompro |
miker++ |
| 15:05 |
berick |
/openils/bin/test_json_query |
| 15:05 |
Stompro |
berick++ |
| 15:05 |
* Dyrcona |
was about to say you can "now" in a comparison as is: run_time => { '<' => "now"} |
| 15:08 |
Dyrcona |
Full example: my $query = [{ state => 'pending', run_time => {'<' => 'now'} }, { order_by => { atev => [ qw/run_time add_time/] }, 'join' => 'atevdef' }]; |
| 15:08 |
Dyrcona |
That's used in a CStoreEditor-> search_action_trigger_event() call. |
| 15:09 |
Dyrcona |
I couldn't find any other examples where I used now in a JSON query, sorry. |
| 15:11 |
Dyrcona |
The join is done because there's code after that to limit by granularity if a granularity option is passed to the script, in case you're wondering.... |
| 15:18 |
Stompro |
Dyrcona, thanks, I just need to figure out how to subtract an interval from it.. |
| 15:19 |
miker |
Stompro: basically, just start reading from https://wiki.evergreen-ils.org/doku.php?id=documentation:tutorials:json_query#comparing_to_a_function |
| 15:20 |
Stompro |
Are there any docs on the test_jason_query program. |
| 15:21 |
miker |
there are emails from the long ago, but I don't recall docs |
| 15:21 |
Stompro |
I'll search for those, thanks. |
| 15:25 |
miker |
maybe: {due_date:{'<':['pg_catalog.interval_pl_timestamptz','-14 days','now']}} |
| 15:28 |
miker |
(pg_catalog is where the functions behind the operators live, btw) |
| 15:29 |
miker |
oh, there's pg_catalog.timestamptz_mi_interval. as in: select pg_catalog.timestamptz_mi_interval('now','14 days'); |
| 15:31 |
Stompro |
Woohoo, I finally got some output from the json tester that didn't include "JSON Parser Error" |
| 15:36 |
Stompro |
miker++, your first example seems to generate the correct results. Thanks. And thank you all for clueing me into the json tester. |
| 15:36 |
* berick |
reads up.. |
| 15:36 |
berick |
nice |
| 15:39 |
Dyrcona |
Ah.... Cool trick! |
| 15:39 |
Dyrcona |
miker++ |
| 16:02 |
bshum |
@dessert |
| 16:02 |
* pinesol_green |
grabs some pineapple chocolate things from New Zealand for bshum |
| 16:02 |
bshum |
It's National Dessert Day! :D |
| 16:07 |
Dyrcona |
@dessert [someone] |
| 16:07 |
* pinesol_green |
grabs some Banana Puddin' for pinesol_green |
| 16:07 |
Dyrcona |
heh |
| 16:07 |
bshum |
Slick |
| 16:12 |
kmlussier |
pinesol_green is being a little greedy today. |
| 16:12 |
pinesol_green |
kmlussier: The horror... The horror... |
| 16:12 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 16:12 |
kmlussier |
@dessert [someone] |
| 16:12 |
* pinesol_green |
grabs some Lemon Cupcakes for Dyrcona |
| 16:13 |
* kmlussier |
made peanut butter cookies the other day. Probably should have waited until today. |
| 16:22 |
kmlussier |
@dessert add Chocolate Eclairs |
| 16:22 |
pinesol_green |
kmlussier: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 16:22 |
kmlussier |
@dessert add Chocolate Eclairs |
| 16:22 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #44 added. |
| 16:24 |
kmlussier |
@dessert add Caramel Custard, aka Crème Caramel, aka Flan |
| 16:24 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #45 added. |
| 17:10 |
|
mmorgan left #evergreen |
| 18:03 |
|
bmills joined #evergreen |
