| Time |
Nick |
Message |
| 00:18 |
|
dpearl joined #evergreen |
| 01:48 |
|
Ovius joined #evergreen |
| 04:39 |
|
huhlig1 joined #evergreen |
| 05:25 |
|
prettymuchbryce5 joined #evergreen |
| 05:28 |
|
AC`97_ joined #evergreen |
| 05:38 |
|
gsams joined #evergreen |
| 05:52 |
|
stoner190 joined #evergreen |
| 06:10 |
|
L0j1k1 joined #evergreen |
| 06:13 |
|
knolle14 joined #evergreen |
| 06:18 |
|
deltab3 joined #evergreen |
| 06:32 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:48 |
|
JBoyer joined #evergreen |
| 06:55 |
|
bs27 joined #evergreen |
| 07:04 |
|
agoben joined #evergreen |
| 07:04 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
kashike1 joined #evergreen |
| 07:53 |
|
n-st24 joined #evergreen |
| 07:53 |
|
collum joined #evergreen |
| 08:41 |
|
Dyrcona joined #evergreen |
| 08:56 |
|
bos20k joined #evergreen |
| 09:02 |
|
mmorgan joined #evergreen |
| 09:11 |
|
yboston joined #evergreen |
| 09:18 |
|
kmlussier joined #evergreen |
| 09:35 |
|
jvwoolf joined #evergreen |
| 09:39 |
|
khuckins joined #evergreen |
| 09:39 |
|
rlefaive joined #evergreen |
| 09:48 |
|
yboston joined #evergreen |
| 09:49 |
Dyrcona |
"Curiouser and curiouser," said Alice. |
| 09:53 |
|
rlefaive joined #evergreen |
| 09:59 |
jeff |
Now that we can, let's try this: setting channel +s ("secret") may make it less visible to bots if they don't already have the channel's existence cached. |
| 10:01 |
|
rlefaive joined #evergreen |
| 10:04 |
|
Immune joined #evergreen |
| 10:05 |
|
cyberlard20 joined #evergreen |
| 10:27 |
|
trqx5 joined #evergreen |
| 10:30 |
|
rlefaive joined #evergreen |
| 10:52 |
Bmagic |
Has anyone tackled creating a report that shows a patron's hold queue position? |
| 10:52 |
Dyrcona |
No, because the hold queue position is a lie. |
| 10:52 |
Bmagic |
right! |
| 10:53 |
Dyrcona |
It's just an approximation, based on when there hold was placed. |
| 10:53 |
Dyrcona |
You could be last and owing to circumstances have your hold filled next. |
| 10:55 |
Dyrcona |
The only time it represents reality is if you turn on FIFO holds, and you don't want to do that in a consortium with delivery. |
| 10:56 |
Bmagic |
Right |
| 10:56 |
Bmagic |
The queue position is "calculated" within any interface that it's showed? |
| 10:56 |
Bmagic |
I just want to make sure I say the right thing "The reporter engine cannot show queue position" |
| 10:57 |
Dyrcona |
Yeah, there's nothing in the database that stores it. |
| 10:59 |
Dyrcona |
Nothing in the db appears to calculate it, either. |
| 10:59 |
* Dyrcona |
gets grumpy when staff and patrons try to second guess the software. |
| 11:00 |
Bmagic |
Oh man, tell me about it |
| 11:00 |
Dyrcona |
My recommendation is just don't show patrons the queue position, but no one listens to me on that. |
| 11:00 |
Dyrcona |
"It's a service and our patrons want to know." |
| 11:00 |
Dyrcona |
"It's a lie and a disservice." |
| 11:00 |
Dyrcona |
"But....service!" |
| 11:00 |
Bmagic |
I've had that same conversation many times |
| 11:00 |
* Dyrcona |
loses. :) |
| 11:01 |
mmorgan |
Is queue position strictly based chronologically on request_time? |
| 11:01 |
Bmagic |
with pickup_lib mixed in |
| 11:01 |
Dyrcona |
I'd have to find teh code. |
| 11:01 |
Bmagic |
and about a dozen other factors |
| 11:02 |
berick |
Circ/Holds.pm retrieve_hold_queue_status_impl() |
| 11:03 |
* Dyrcona |
goes back to potentially breaking old invoices for a member library. :) |
| 11:03 |
Dyrcona |
They asked me to close their old invoices.... |
| 11:03 |
Bmagic |
Good luck! |
| 11:08 |
Dyrcona |
So, having looked at the function, thanks berick, it is as simple as I remember. |
| 11:08 |
Dyrcona |
Hold queue is basically the order the holds were placed, with cut in line taken into account. |
| 11:10 |
Dyrcona |
With some extra code to estimate the wait time if the setting is turned on. |
| 11:11 |
berick |
now that reporter.hold_request_record is materialized (and much faster) it can be a useful in approximating queue position as well, since it tells you every hold that targets a bib, regardless of hold type. |
| 11:11 |
berick |
you still have to apply the cut_in_line, filter fulfilled holds, etc. but it makes the initial data collection simple |
| 11:12 |
Dyrcona |
Shh! They'll ask Bmagic to do that in a report. |
| 11:12 |
Dyrcona |
;0 |
| 11:12 |
berick |
oops, i mean, can't be done! |
| 11:13 |
Bmagic |
wait |
| 11:13 |
Dyrcona |
It's definitely not something you just add in the reporter and pick a field. |
| 11:13 |
Bmagic |
I almost finished this email but you're saying we could* make something close? |
| 11:13 |
Dyrcona |
With lots of aggregates and joins and such, yeah. |
| 11:14 |
Dyrcona |
But, anyway...breaking acquisitions.... |
| 11:15 |
Bmagic |
they want a report for all unfulfilled holds: Patron A,Title, Position. Then next row, Patron B, Title, Position |
| 11:16 |
* Dyrcona |
isn't exactly sure how reporter.hold_request_record makes that any easier. |
| 11:16 |
Dyrcona |
Bmagic, you'd basically have to reproduce the Perl function that berick pointed out earlier in the database. |
| 11:17 |
Bmagic |
yeah, I'm not seeing the light |
| 11:17 |
Dyrcona |
So, the short answer is "No, it can't show the queue position." |
| 11:18 |
Bmagic |
Final answer! |
| 11:18 |
Dyrcona |
The long answer is, "It can with lots of tricky futzing that's apt to be wronger than the Perl." |
| 11:18 |
Bmagic |
wronger |
| 11:18 |
Dyrcona |
Yes... :) |
| 11:18 |
Bmagic |
I love it |
| 11:18 |
* mmorgan |
wonders if strict chronological position would suffice for Bmagic's report. |
| 11:19 |
berick |
Bmagic: I think I have something you can use.. |
| 11:19 |
Bmagic |
berick: in the reporter? |
| 11:19 |
* Dyrcona |
gives berick the "side eye." :) |
| 11:20 |
pastebot |
"berick" at 64.57.241.14 pasted "hold queue position" (22 lines) at http://paste.evergreen-ils.org/13936 |
| 11:20 |
Dyrcona |
If I tried it in the reporter, I'd get it wrong, and it would run for 10 days. :) |
| 11:20 |
berick |
if you added that function (or made it a view?) you could call it from reporter |
| 11:21 |
Bmagic |
sheesh |
| 11:21 |
Bmagic |
Maybe I need to poll the user base for "how useful this is" |
| 11:22 |
Bmagic |
<magic>ROW_NUMBER()</magic> |
| 11:23 |
Bmagic |
I'll bake that in after I edit Hatch for Dymo /me ducks |
| 11:23 |
Dyrcona |
I think you could add a variable to function and increment it for each row. |
| 11:24 |
Dyrcona |
Oh, never mind me.... I'm just begin silly. :) |
| 11:24 |
Bmagic |
berick: That function is very clever |
| 11:24 |
Dyrcona |
Right, where was I... :) |
| 11:25 |
mmorgan |
Dyrcona: Breaking acquisitions :) |
| 11:25 |
Dyrcona |
mmorgan++ Thanks! |
| 11:25 |
Bmagic |
lol |
| 11:26 |
berick |
Bmagic: we're using it locally. (I didn't just make it up on the spot). i made it to resolve some load issues (biblicommons requests that data a lot...) |
| 11:27 |
berick |
now that the table is materialized, the query is super fast |
| 11:27 |
Bmagic |
ah, well, thanks! I filed it away under "Rainy day" |
| 11:28 |
Bmagic |
moar coffee |
| 11:30 |
Dyrcona |
@coffee Bmagic |
| 11:30 |
* pinesol |
brews and pours a cup of El Salvador La Montana Pacamara, and sends it sliding down the bar to Bmagic |
| 11:31 |
Bmagic |
Hmmmmm doughnuts |
| 11:31 |
Dyrcona |
So, that's what's Pacman is doing.... :) |
| 11:31 |
Dyrcona |
I have an acq question, and it's probably dumb, but here goes. |
| 11:31 |
Bmagic |
it's the El Salvador again! I think that's the candidate for our pinesol_green coffee party: https://www.coffeereview.com/review/el-salvador-la-montana-pacamara/ |
| 11:32 |
Dyrcona |
There's no way to mark a debit as specifically spent, right. |
| 11:32 |
miker |
Bmagic: there's logic that, at capture time, gives the actual queue position based on best hold sort order, but it's copy-oriented and the result is based on where the copy is physically scanned, and not something one could turn into a performant view nor cache (every hold that every copy could fill ... and out of date after every capture). there's simply too much real-time context input required to make the calculation across all holds. the most |
| 11:32 |
miker |
correct answer is "the system follows the rules, and the order is *correct per those rules" (*excepting bugs, and we're not currently aware of any) |
| 11:33 |
Dyrcona |
If encumbrance is true and the invoice is closed, that indicates the spentness of the debit? |
| 11:33 |
Bmagic |
miker: I made an attempt to explain it to the staff. I like the way you put it better than the way I put it! Hats off to you sir. |
| 11:33 |
miker |
I've just been beating that horse carcass longer than you ;) |
| 11:33 |
Dyrcona |
:) |
| 11:34 |
Bmagic |
Can't be much of a carcass left |
| 11:34 |
berick |
heh |
| 11:34 |
Dyrcona |
You'd be surprised.... |
| 11:34 |
miker |
Dyrcona: I was just typing that... |
| 11:34 |
Dyrcona |
:) |
| 11:34 |
Bmagic |
Dyrcona: sorry, invoice is closed.... |
| 11:35 |
Dyrcona |
Bmagic: I don't know, either. This is the language I was given. |
| 11:36 |
Dyrcona |
"Please update all open [library] invoices created before 7/1/2018 to closed and update any encumbered fund debits attached to the invoices to spent." |
| 11:36 |
|
rlefaive joined #evergreen |
| 11:36 |
Dyrcona |
I know less about acq than holds. :) |
| 11:37 |
Dyrcona |
I guess closed is "complete = TRUE" in the db. |
| 11:38 |
miker |
berick: is that queue position function fast? if so, it might be worth using in the hold UI speedup branch... |
| 11:40 |
berick |
miker: yes, much faster than the hold copy map lookups |
| 11:41 |
Bmagic |
Dyrcona: I had a question about this some time back, and yes, I believe the system changes from "encumbered" (in the interface) to "spent" when acq.fund_debit -> acq.invoice_entry ->amount_paid is set during the receiving process? |
| 11:41 |
berick |
that are in the queue pos API |
| 11:41 |
miker |
berick: hrm... but it won't get us wait time -- that's dependent on the number of copies involved |
| 11:41 |
Dyrcona |
Bmagic: Thanks! I'll look into that. |
| 11:42 |
berick |
miker: true |
| 11:42 |
Bmagic |
Dyrcona: berick helped me |
| 11:43 |
miker |
might still be worth it to drop wait time. anyone using that in the wild? (I haven't found any sites with the circ mod or org settings in a quick scan) |
| 11:43 |
Bmagic |
or maybe when rows in acq.invoice_item show up matching fund_debit |
| 11:46 |
|
yboston joined #evergreen |
| 11:49 |
berick |
apparently we're not using wait time. |
| 11:52 |
Dyrcona |
IIRC, wait time doesn't change the queue position. It's just estimated based on settings. |
| 11:58 |
miker |
Dyrcona: correct, based on number of copies that could fill your hold, the holds in front of you, and settings |
| 12:06 |
jeff |
*headdesk* |
| 12:07 |
mmorgan |
:-X |
| 12:08 |
jeff |
fixing. |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:14 |
Dyrcona |
Must be Monday. :) |
| 12:16 |
|
mhayward joined #evergreen |
| 12:18 |
|
Odd_ joined #evergreen |
| 12:37 |
|
jeff_ joined #evergreen |
| 12:38 |
|
jeff_ joined #evergreen |
| 13:00 |
|
bos20k_ joined #evergreen |
| 13:18 |
|
aabbee joined #evergreen |
| 13:37 |
|
khuckins_ joined #evergreen |
| 13:45 |
|
orliesaurus6 joined #evergreen |
| 13:58 |
|
yboston joined #evergreen |
| 14:19 |
|
exio43 joined #evergreen |
| 14:25 |
|
jvwoolf joined #evergreen |
| 14:30 |
|
jvwoolf left #evergreen |
| 14:31 |
|
jvwoolf joined #evergreen |
| 14:32 |
|
bos20k joined #evergreen |
| 14:32 |
pinesol |
[evergreen|Bill Erickson] LP#1718032 Patron merge honors group perms; no self-merge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bf0a3fd> |
| 14:33 |
|
jvwoolf left #evergreen |
| 14:34 |
|
jvwoolf joined #evergreen |
| 14:36 |
|
rlefaive joined #evergreen |
| 15:07 |
|
yboston joined #evergreen |
| 15:17 |
|
troy___ joined #evergreen |
| 15:17 |
|
khuckins joined #evergreen |
| 16:19 |
|
rlefaive joined #evergreen |
| 16:28 |
Bmagic |
Anyone have a list of things to look out for in the osrfsys.log ? |
| 16:29 |
Bmagic |
"NOT CONNECTED" is all I got so far. |
| 17:01 |
|
rlefaive joined #evergreen |
| 17:02 |
jeff |
So, back in 2013 a well-meaning individual set up a bot in #evergreen to echo tweets to this channel around the time of the annual conference. The bot was unintentionally relaying some spammy content, and a rule was set in place to quiet that bot. Unfortunately, this also prevented the bot's owner from communicating with the channel. The rule is no longer needed, and I'm removing it. |
| 17:07 |
Bmagic |
jeff++ |
| 17:07 |
|
mmorgan left #evergreen |
| 17:16 |
|
jvwoolf left #evergreen |
| 17:23 |
|
Xlbrag_ joined #evergreen |
| 17:32 |
|
ccallahan27 joined #evergreen |
| 17:33 |
jeff |
Not sure how I've gone this far without having encountered systemd killing Apache due to RemoveIPC=yes (and opensrf's uid being outside the system range), but here we are. |
| 17:33 |
jeff |
And I'm glad it was on a test system. :-) |
| 17:35 |
jeff |
(systemd killing postgres I'm familiar with, and remember looking into in detail a while back) |
| 17:55 |
csharp |
Bmagic: do you have it all in one file, or do you use http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/examples/evergreen-rsyslog.conf;h=ba25cea727c4aadead5635197f86040392c5ecf2;hb=HEAD to filter from rsyslog? |
| 17:56 |
csharp |
jeff++ # channel wrangler |
| 17:59 |
jeff |
Thanks. Wish it was less necessary. :P |
| 18:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:47 |
|
rlefaive joined #evergreen |
| 19:25 |
|
bjs11 joined #evergreen |
| 20:01 |
|
bdljohn joined #evergreen |
| 20:42 |
|
Guest28124 joined #evergreen |
| 21:04 |
|
JBoyer joined #evergreen |
| 21:04 |
|
yar joined #evergreen |
| 21:09 |
|
yar__ joined #evergreen |
| 21:12 |
|
PrettyKittie26 joined #evergreen |
| 22:17 |
|
liguo joined #evergreen |
| 22:27 |
|
^Phantom^16 joined #evergreen |
| 23:08 |
|
siniStar joined #evergreen |
