| Time |
Nick |
Message |
| 01:50 |
|
JBoyer_alt joined #evergreen |
| 02:08 |
|
BruceS14 joined #evergreen |
| 03:05 |
|
sjums joined #evergreen |
| 03:17 |
|
Xiti22 joined #evergreen |
| 03:34 |
|
Miklo19 joined #evergreen |
| 03:41 |
|
Smeef6 joined #evergreen |
| 03:42 |
|
Michail1 joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
rlefaive joined #evergreen |
| 07:19 |
|
agoben joined #evergreen |
| 07:41 |
|
bdljohn joined #evergreen |
| 07:44 |
|
JBoyer joined #evergreen |
| 08:12 |
|
collum joined #evergreen |
| 08:51 |
|
Dyrcona joined #evergreen |
| 08:52 |
|
idjit joined #evergreen |
| 08:52 |
|
jvwoolf1 joined #evergreen |
| 09:02 |
|
rlefaive joined #evergreen |
| 09:09 |
|
kmlussier joined #evergreen |
| 09:18 |
|
yboston joined #evergreen |
| 10:06 |
kmlussier |
berick: I have a fresh install with lp1750894-ws-settings-on-server-squash1-grid-limits, but something must be off with the seed data. I'm only getting two entries in config.workstation_setting_type now. eg.search.search_lib and eg.search.pref_lib |
| 10:06 |
berick |
kmlussier: looking... |
| 10:09 |
berick |
rebuilding db |
| 10:09 |
berick |
arg, perm ID conflict |
| 10:09 |
* berick |
fixes |
| 10:14 |
|
Christineb joined #evergreen |
| 10:18 |
berick |
kmlussier: there was also a dupe setting. fixes pushed. confirmed base schema / data installs OK now. |
| 10:18 |
kmlussier |
berick: Great, thanks! |
| 10:18 |
kmlussier |
berick++ |
| 10:20 |
* berick |
should test both versions of the sql |
| 10:20 |
berick |
i did re-run the pgtap test and it's still happy |
| 10:21 |
Dyrcona |
Crazy.... |
| 10:21 |
Dyrcona |
My crazy is a propos something else... :) |
| 10:22 |
kmlussier |
berick: I'm reinstalling the VM, but I realize why you had that dupe setting. I have mentioned that the checkout strict barcode setting hadn't been added. It looks like you added checkin strict barcode instead of checkout. |
| 10:23 |
kmlussier |
s/have/had |
| 10:24 |
berick |
kmlussier: dang. adding checkout version now |
| 10:25 |
* berick |
rebuilds DB |
| 10:27 |
berick |
fix pushed |
| 10:27 |
berick |
build completed |
| 10:28 |
berick |
we now have 4 strict barcode settings |
| 10:28 |
berick |
kmlussier: i'm happy to squash those, but I don't know if it will mess up your testing |
| 10:28 |
kmlussier |
berick++ |
| 10:29 |
kmlussier |
berick: No, it won't mess it up. |
| 10:29 |
JBoyer |
It will be nice to be able to disable all of those at once. The only time we hear about those settings here is when someone accidentally turns one one. (we don't have CODABAR everywhere) |
| 10:29 |
Dyrcona |
git reset --hard <newcommithash> :) |
| 10:29 |
berick |
kmlussier: thanks, will squash |
| 10:30 |
berick |
JBoyer: yeah, was wondering if we really needed such granularity |
| 10:30 |
Dyrcona |
So, my crazy was related to how many times a certain item has shown up in our database via NCIP in the past two years....Maybe someone should buy a copy? |
| 10:30 |
kmlussier |
JBoyer: I think we also hear about them when someone turns them off and then ultimately creates a precat with a single-digit barcode. |
| 10:30 |
Dyrcona |
"3" is a very popular barcode owing to the first digit only being scanned. |
| 10:33 |
Dyrcona |
JBoyer: Related to strict barcode settings, I recently wrote some code as part of anonymization routine to generate fake barcodes for patrons based on the barcode id and home_ou with the last digit being a check digit. |
| 10:33 |
JBoyer |
Maybe somewhere down the line it could be made more generic than just verifying a weird, old checkdigit style. |
| 10:34 |
berick |
squashed today's 3 commits into the previous commit (since most of it was shuffling the same stuff around). force-pushed back to branch. |
| 10:35 |
JBoyer |
Dyrcona, meaning you made it conform to the MSI-Plessy mod 11 checkdigit calculations, or something else? |
| 10:35 |
Dyrcona |
JBoyer: It |
| 10:35 |
Dyrcona |
bleh.... fingers... |
| 10:35 |
berick |
irc.strict.message |
| 10:36 |
Dyrcona |
Luhn algorithm, which IIRC amounts to the same thing. |
| 10:36 |
JBoyer |
berick++ |
| 10:36 |
Dyrcona |
heh |
| 10:36 |
JBoyer |
ah. |
| 10:36 |
kmlussier |
berick++ |
| 10:38 |
Dyrcona |
berick++ # It's Friday! |
| 10:38 |
berick |
;) |
| 10:40 |
Dyrcona |
re: git... I find it amusing how sometimes a pull barfs where a rebase works and vice versa. |
| 11:02 |
jeff |
(easier to just voice everyone than to remember who is identified to services and doesn't need it) |
| 11:03 |
jeff |
(cleared some old/obsolete bans) |
| 11:10 |
kmlussier |
jeff++ |
| 11:16 |
|
yboston joined #evergreen |
| 11:17 |
Dyrcona |
jeff++ |
| 11:18 |
bshum |
jeff++ |
| 11:23 |
jeff |
@channel capabilities list |
| 11:23 |
pinesol_green |
jeff: Error: That configuration variable is not a channel-specific configuration variable. |
| 11:23 |
jeff |
@channel capability list |
| 11:23 |
pinesol_green |
jeff: -halfop -op -protected -voice |
| 11:23 |
jeff |
@channel capability set voice |
| 11:23 |
pinesol_green |
jeff: The operation succeeded. |
| 11:23 |
jeff |
@channel capability list |
| 11:23 |
pinesol_green |
jeff: -halfop -op -protected voice |
| 11:24 |
jeff |
@voice serflog |
| 11:24 |
pinesol_green |
jeff: Error: I need to be at least halfopped to voice someone. |
| 11:24 |
jeff |
hah. |
| 11:24 |
jeff |
@voice serflog |
| 11:25 |
jeff |
okay. in theory anyone in channel should be able to ask pinesol_green to voice anyone else. |
| 11:25 |
jeff |
if you need to voice yourself you need to do it via msg to pinesol_green, since you can't speak in channel. :-) |
| 11:25 |
bshum |
@roulette |
| 11:25 |
pinesol_green |
bshum: *click* |
| 11:25 |
berick |
jeff: cool. what does that mean? :) |
| 11:25 |
jeff |
registering with and setting your irc client to identify to freenode services is still highly recommended. |
| 11:26 |
csharp |
@coin |
| 11:26 |
pinesol_green |
csharp: heads |
| 11:26 |
bshum |
Maybe I should remove @roulette now that pinesol_green has real powers |
| 11:26 |
berick |
heh |
| 11:27 |
Dyrcona |
@dunno |
| 11:27 |
pinesol_green |
Dyrcona: Try running autogen |
| 11:27 |
Dyrcona |
@roulette [random] |
| 11:27 |
pinesol_green |
Dyrcona: Error: The command "random" is available in the LoveHate and Quote plugins. Please specify the plugin whose command you wish to call by using its name as a command before "random". |
| 11:27 |
berick |
@who heard [band] say [dunno] |
| 11:27 |
pinesol_green |
dkyle1 heard Berick's Brain say You keep using that word. I do not think it means what me think it means. |
| 11:28 |
jeff |
currently, as mitigation for the spambots while we wait for freenode to deal with them at the network level, the channel mode +q $~a in this channel means that you must be either identified to freenode services or voiced (+v) in channel to send messages to the channel. |
| 11:28 |
Dyrcona |
People ruin everything. |
| 11:28 |
berick |
jeff: awesome, thanks for admin |
| 11:29 |
csharp |
jeff++ |
| 11:29 |
jeff |
anyone in channel that can already speak should be able to ask pinesol_green to voice anyone else (say, berick) using "@voice berick" in channel or "/msg pinesol_green voice #evergreen berick" |
| 11:30 |
jeff |
you should also be able to voice yourself if you "/msg pinesol_green voice #evergreen" |
| 11:30 |
Dyrcona |
@who granted half-op to pinesol_green |
| 11:30 |
pinesol_green |
drigney granted half-op to pinesol_green. |
| 11:31 |
jeff |
Dyrcona: agreed. |
| 11:32 |
csharp |
berick: running 'npm run test' after pulling in your changes on the DB ws settings branches is failing for me |
| 11:32 |
berick |
wee, thanks csharp, looking |
| 11:32 |
csharp |
berick: https://pastebin.com/Y704FHdV |
| 11:33 |
berick |
the hunt is on.. |
| 11:33 |
csharp |
if it's a "just me" problem, I'll take if from here :-) |
| 11:33 |
berick |
confirmed |
| 11:33 |
berick |
confirmed it's not just you, i mean |
| 11:33 |
Dyrcona |
That looks bad. |
| 11:34 |
jeff |
https://docs.npmjs.com/files/package-lock.json |
| 11:38 |
berick |
found it |
| 11:38 |
berick |
harmless comma that phantomjs dislikes |
| 11:40 |
berick |
fix pushed |
| 11:40 |
jeff |
stil "perhaps unrelated to the current errors", and containing at least one confusing typo (package-log where we meant package-lock), but earlier conversation and something I'm meaning to look into again: http://irc.evergreen-ils.org/evergreen/2018-05-15#i_358782 |
| 11:41 |
jeff |
berick++ |
| 11:41 |
csharp |
berick++ |
| 11:41 |
berick |
berick-- # not catching these earlier |
| 11:42 |
* csharp |
wants to test new angular but it may not end up being today |
| 11:42 |
Dyrcona |
What csharp just said. |
| 11:42 |
berick |
csharp: holler when you do |
| 11:42 |
Dyrcona |
Last time I tried, I upgraded Node and that didn't go so well. |
| 11:42 |
csharp |
libraries are all happy that summer reading is over and are needier again |
| 11:43 |
* berick |
will be porting 1750894 to ang6 soon |
| 11:44 |
kmlussier |
bug 1750894 |
| 11:44 |
pinesol_green |
Launchpad bug 1750894 in Evergreen "Wishlist: Store web staff workstation settings on the server" [Wishlist,New] https://launchpad.net/bugs/1750894 - Assigned to Kathy Lussier (klussier) |
| 11:44 |
berick |
kmlussier: in case you're not following closely, just pushed a unit test fix to the settings branch |
| 11:45 |
kmlussier |
berick: Saw it. I was briefly distracted by alternate name testing, but I'm returning to that branch now. |
| 11:45 |
kmlussier |
So many things to test. |
| 11:46 |
Dyrcona |
kmlussier++ |
| 11:46 |
berick |
kmlussier++ # indeed |
| 11:56 |
csharp |
heh - I've wanted to do that for a long time |
| 11:57 |
csharp |
pinesol: sup? |
| 11:57 |
pinesol |
csharp: <shaggy>We're, like, doomed.</shaggy> |
| 11:58 |
|
jihpringle joined #evergreen |
| 11:58 |
csharp |
@voice jihpringle |
| 11:58 |
pinesol |
csharp: Error: I need to be at least halfopped to voice someone. |
| 11:58 |
csharp |
oops |
| 11:58 |
jeff |
csharp: try again. |
| 11:58 |
csharp |
@voice jihpringle |
| 11:58 |
csharp |
cool |
| 11:59 |
jihpringle |
thanks csharp :) |
| 12:00 |
jeff |
(though jihpringle is identified to services and doesn't need voice, so that's good too) |
| 12:00 |
jeff |
spammers-- |
| 12:00 |
csharp |
srsly |
| 12:02 |
Dyrcona |
@blame spammers for everything |
| 12:02 |
pinesol |
Dyrcona: I know it was you, spammers. You broke Dyrcona's heart. You broke Dyrcona's heart. for everything |
| 12:02 |
Dyrcona |
@blame Monty Python for spam |
| 12:02 |
pinesol |
Dyrcona: Monty Python 's bugfix broke Dyrcona's feature! for spam |
| 12:04 |
bshum |
csharp: Haha, I was just musing about dropping _green from the bot |
| 12:04 |
bshum |
csharp++ # doing things |
| 12:05 |
csharp |
bshum: actually, I think that was jeff |
| 12:05 |
* jeff |
smiles |
| 12:05 |
bshum |
Oh haha, I guess you just said it |
| 12:05 |
csharp |
so at least three of us were on the same page |
| 12:05 |
bshum |
*aloud |
| 12:07 |
csharp |
berick: so I'm saving column/grid configs successfully with the fix for bug 1750894 - is there anything else particular you would want to see a bit of rigor trying out? |
| 12:07 |
pinesol |
Launchpad bug 1750894 in Evergreen "Wishlist: Store web staff workstation settings on the server" [Wishlist,New] https://launchpad.net/bugs/1750894 - Assigned to Kathy Lussier (klussier) |
| 12:08 |
berick |
csharp: main things are existing settings migrate (where available), newly applied settings to go the server as expected, and the UI in general doesn't fall over. |
| 12:10 |
csharp |
ok |
| 12:29 |
kmlussier |
bug 1750894 looks good to me. I can sign off after I get some lunch. |
| 12:29 |
pinesol |
Launchpad bug 1750894 in Evergreen "Wishlist: Store web staff workstation settings on the server" [Wishlist,New] https://launchpad.net/bugs/1750894 - Assigned to Kathy Lussier (klussier) |
| 12:44 |
|
sandbergja joined #evergreen |
| 13:08 |
csharp |
kmlussier: agreed |
| 13:08 |
csharp |
kmlussier++ |
| 13:09 |
csharp |
I didn't really test migration though |
| 13:09 |
csharp |
but if you're good, I'm good :-) |
| 13:09 |
|
jvwoolf1 joined #evergreen |
| 13:11 |
kmlussier |
csharp: Do you want to add a signoff too or should I just merge it? |
| 13:11 |
csharp |
kmlussier: go for it! |
| 13:18 |
JBoyer |
kmlussier++ |
| 13:18 |
JBoyer |
that branch is annoyed with some of our local modifications so I haven |
| 13:18 |
JBoyer |
t been able to load it yet. I'm glad it looks good. |
| 13:20 |
Bmagic |
I'm staring at an opensrf log, attempting to diagnose why lost.auto triggers aren't happening. Found the MarkItemLost log entry which executes create_batch_events() and then logs a dozen "Use of uninitialized value in string" for Trigger.pm line 429 |
| 13:21 |
Bmagic |
which is "next if ($granularity && $def->granularity ne $granularity );" |
| 13:22 |
kmlussier |
Calling 1116 and 1117 |
| 13:22 |
Bmagic |
My first thought was the column granularity in the database contained null values but that is handled in that statement or so one would think |
| 13:23 |
Bmagic |
Does the granularity of the lost.auto ATED need to be exactly the same as the calling ATED? |
| 13:26 |
Dyrcona |
Bmagic: Yes, that is what that line above is saying, or there needs to be no granularity set in the caller. |
| 13:27 |
Bmagic |
darn |
| 13:27 |
berick |
that check confirms the granularity passed to action_trigger_runner.pl matches the event def granularity |
| 13:27 |
Dyrcona |
Bmagic: Is the message you're getting "Use of uninitialized value in string ne"? |
| 13:27 |
Bmagic |
That has to be why it's not creating the ate for my lost.auto's |
| 13:28 |
Bmagic |
It's in in the logs directly following "create_batch_events() successfully created events for def=576 / hook=checkout.due" |
| 13:28 |
Dyrcona |
The event_def has a null granularity, then. |
| 13:30 |
Dyrcona |
You probably want daily. |
| 13:30 |
Bmagic |
hmmm, I found an example of a lost.auto that is working just fine with a different granularity compared with the trigger that Marks Lost |
| 13:31 |
Bmagic |
ah! Probably because there is no granularity on the MarkItemLost ATED |
| 13:32 |
Bmagic |
without a granularity on the MarkItemLost ATED, the create batch events just inserts into ATE for all ATED's lost.auto regardless of granularity? |
| 13:32 |
pinesol |
Showing latest 5 of 11 commits to Evergreen... |
| 13:32 |
pinesol |
[evergreen|Bill Erickson] LP#1750894 Hatch set local storage item thinko - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a61fc24> |
| 13:32 |
pinesol |
[evergreen|Bill Erickson] LP#1750894 Batch settings lookup handles migration - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=29f35dc> |
| 13:32 |
pinesol |
[evergreen|Bill Erickson] LP#1750894 Additional workstation setting types + repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73b7ace> |
| 13:32 |
pinesol |
[evergreen|Bill Erickson] LP#1750894 Remove errant phantomjs-killing comma - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d423090> |
| 13:32 |
pinesol |
[evergreen|Kathy Lussier] LP#1750894: Stamping upgrade script for workstation settings on server - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=beee20c> |
| 13:33 |
Dyrcona |
lost.auto is a hook. |
| 13:34 |
berick |
kmlussier++ |
| 13:35 |
Bmagic |
berick++ |
| 13:35 |
Dyrcona |
If you run action_trigger_runner without --granularity and --granularity-only, I believe it will pick up events with no granularity. |
| 13:36 |
Dyrcona |
lost.auto has no granularity since it is a hook, not an event. It runs when a triggered event that uses it is run. |
| 13:36 |
kmlussier |
berick++ indeed |
| 13:37 |
Bmagic |
Dyrcona: sorry, right it's a hook. The "original" ATED is hook="checkout.due", reactor="MarkItemLost" and the other two are hook="lost.auto" with a different reactor for each. One is Email and the other is processtemplate. The latter two ATED's are not getting used because they do not have the same granularity as the "original" |
| 13:37 |
Dyrcona |
Bmagic: They don't have to have the same granularity as the original. |
| 13:38 |
Bmagic |
if that's true, then I can't figure out why they aren't firing |
| 13:38 |
|
bdljohn joined #evergreen |
| 13:38 |
Bmagic |
This logic "next if ($granularity && $def->granularity ne $granularity );" seems to support the theory that they need to have the same granularity |
| 13:40 |
Dyrcona |
Bmagic: I don't have any context for that line of code, I'd have to look it up, but assuming $granularity is the granularity of the action_trigger_runner, then it's throwing out event that don't match its granularity. |
| 13:40 |
Bmagic |
You're saying that if the cronjob is executed without granularity specified, then it will hit all ATED's regardless of granularity? OK but in my case, I need to specify a different action_trigger_filter |
| 13:40 |
Dyrcona |
Bmagic: So, specify the filter. |
| 13:41 |
Bmagic |
but the filter needs to only be applied to the ATEDs with this special granularity |
| 13:41 |
Bmagic |
:) |
| 13:41 |
Dyrcona |
Having said all that, I see that our mark lost event defs have no granularity as does our lost email triggers. |
| 13:41 |
|
fran_g joined #evergreen |
| 13:41 |
Dyrcona |
We have a granularity for printing lost bills. |
| 13:42 |
Bmagic |
the code seems to process lost.auto ATED's regardless of the lost.auto granularity only when the original ATED doesn't have a granularity |
| 13:43 |
Dyrcona |
lost.auto has no granularity. It is a hook. |
| 13:43 |
Bmagic |
I know, I mean the ATED's that have the hook lost.auto and have a granularity |
| 13:44 |
Dyrcona |
Each event definition is its own thing, though some "depend" on others logically. |
| 13:45 |
Dyrcona |
Are you not running action_trigger_runner with no granularity after running the granularity specific ones? |
| 13:45 |
Bmagic |
I am |
| 13:46 |
Bmagic |
I truely think that my problem is my ATED that executes the MarkItemLost needs to have a granularity so that I can target it special out of the group and apply a special filter which allows the circulations to have stop_fines='LONGOVERDUE' - then launch two more ATED's with lost.auto |
| 13:48 |
Bmagic |
The 2 other ATED's with hook=lost.auto unfortunately need to have a different granularity because (at least in the ProcessTemplate case) there is another perl script that finds the event_output and creates the PDF's for print notices |
| 13:48 |
Dyrcona |
Could be, as I don't know your setup, and I may have misinterpreted your initial request because it seemed to you thought something wasn't happening that should happen. :) |
| 13:49 |
Dyrcona |
Yes, that's how ours works, except our "90 day Overdue Mark Lost" has no granularity. |
| 13:49 |
Bmagic |
yep, I think that's the catch |
| 13:49 |
Dyrcona |
Our print event def has "Daily-Lost-PD" or something. |
| 13:49 |
Dyrcona |
Works fine when you run things in the correct order. :) |
| 13:50 |
Bmagic |
I bet you if you put a granularity on your "90 day Overdue Mark Lost" that's different than your print notices, it won't run the print notice ATED's |
| 13:50 |
Dyrcona |
We're not using LONGOVERDUE, at least I don't think we are using it intentionally. |
| 13:50 |
Dyrcona |
Bmagic: I bet it will, if I also run the granularity for the Mark Lost before running the print notices. :) |
| 13:51 |
Bmagic |
how much you wanna bet? |
| 13:51 |
Dyrcona |
Bmagic: I know it will work because the granularity is already different. |
| 13:52 |
Bmagic |
I thought it was null? |
| 13:52 |
Dyrcona |
Mark Lost has none, the other have a granularity. |
| 13:52 |
Bmagic |
yep, the null value is the exception |
| 13:52 |
Dyrcona |
NULL is different from something. |
| 13:52 |
Bmagic |
the granularity variable needs to be non-null before the if statement can be evaluated |
| 13:53 |
Dyrcona |
What file is that line from? It's not in action_trigger_runner.pl? |
| 13:53 |
Bmagic |
Trigger.pm |
| 13:58 |
Dyrcona |
I see where I misunderstood your situation. |
| 13:58 |
Dyrcona |
So, drop the granularity on Mark lost. |
| 13:59 |
Bmagic |
I would but I can't because this specific MarkItemLost needs to have a special filter to allow for the circulation to have stop_fines='LONGOVERDUE' as well as 'MAX_FINES' |
| 14:00 |
Dyrcona |
Make a new one, then. |
| 14:00 |
Bmagic |
It's a scenario where the library wants checkouts to flow like: checkout->long overdue->lost |
| 14:01 |
Bmagic |
yeah, I am making the lost.auto ATED's to match the granularity of the MarkItemLost |
| 14:01 |
Dyrcona |
A circ can't have two stop_fines, I think you mean or not "as well as." |
| 14:01 |
Bmagic |
but that will break my print notice code |
| 14:01 |
Bmagic |
I do mean or |
| 14:01 |
Dyrcona |
I don't know what your print notice code does, so I can't say. :) |
| 14:02 |
Bmagic |
I am going to see if I can edit my print notice code to allow for the granularity to be something different only when the hook is lost.auto |
| 14:02 |
Dyrcona |
You can always make a new event for the special ones. |
| 14:02 |
Bmagic |
if you're curious https://github.com/mcoia/mobius_evergreen/blob/master/notices/run_notices.pl |
| 14:05 |
|
fco_guel joined #evergreen |
| 14:05 |
|
bts joined #evergreen |
| 14:05 |
|
bts left #evergreen |
| 14:06 |
Bmagic |
I'm thinking of editing the query with something like "or (reactor='ProcessTemplate' and hook='lost.auto')" |
| 14:08 |
fco_guel |
Hi all, Is there any way to could complete report outputs in EG?, I created a new report, but it is still on Pending Items, How Could I see the report in the completed items list? |
| 14:08 |
Bmagic |
fco_guel: do you have Clark Kent running? |
| 14:08 |
fco_guel |
yes, it is running |
| 14:08 |
fco_guel |
because i can see other reports outputs |
| 14:08 |
Bmagic |
what's it up to? (ps aux|grep Clark) |
| 14:09 |
fco_guel |
opensrf 20003 0.0 0.0 226684 59728 ? Ss 12:13 0:01 Clark Kent, waiting for trouble opensrf 21092 0.0 0.0 12732 2236 pts/0 S+ 13:09 0:00 grep Clark |
| 14:12 |
Dyrcona |
Bmagic: Does your Trigger::Reactor::MarkItemLost->handler do anything with granularit? Mine doesn't. |
| 14:13 |
Bmagic |
fco_guel: Try this query: select count(*) from reporter.schedule where start_time is not null and complete_time is null |
| 14:14 |
Bmagic |
Dyrcona: it doesn't, however, I believe the sub create_batch_events from Trigger.pm is responsible for creating rows in ATE |
| 14:15 |
Dyrcona |
fco_guel: Try this: select * from reporter.currently_running; |
| 14:15 |
Dyrcona |
If that lists anything, you have reports that died and are not running but that prevent Clark from doing any new ones. |
| 14:16 |
Bmagic |
ha! nice DB view |
| 14:16 |
Bmagic |
Dyrcona++ |
| 14:17 |
Bmagic |
Dyrcona++ # for putting up with me all the time |
| 14:17 |
Dyrcona |
I'll paste a SQL to clean them up. |
| 14:18 |
Dyrcona |
Bmagic: granularity should be undef or NULL if I'm reading it correctly, when the autocreate is called by the markitemlost handler. |
| 14:18 |
fco_guel |
yes, the currently running sql displays 1 record |
| 14:19 |
Bmagic |
fco_guel: I suppose you have Clark kent limited to running one report at a time? -c switch |
| 14:19 |
* Dyrcona |
was going to ask about the parallel setting in opensrf.xml for reporter. |
| 14:20 |
fco_guel |
how can i change that to could more than 1 report? |
| 14:21 |
Bmagic |
your real problem is the report that never completed |
| 14:21 |
Dyrcona |
fco_guel: To get rid of the "ghost" report: https://pastebin.com/Bwg1tUgk |
| 14:22 |
Bmagic |
a secondary issue is that Clark kent only runs one at a time |
| 14:22 |
Dyrcona |
And, I don't remember if csharp or JBoyer gave me that query or something like it before. |
| 14:22 |
Bmagic |
depending on the power of your hardware, you might only want to run one at a time |
| 14:24 |
Dyrcona |
To increase the number of reports that can run at once, you need to edit opensrf.xml |
| 14:24 |
Dyrcona |
There's a <reporter> tag/section. |
| 14:25 |
Dyrcona |
It has a <parallel>1</parallel> child tag. |
| 14:25 |
Dyrcona |
Change the 1 to some higher number. I'd start with 2 or 3 if you don't have a separate database for reports. |
| 14:27 |
Dyrcona |
You will need to restart the opensrf.settings and open-ils.reporter services after making that change. |
| 14:28 |
fco_guel |
perfect, an to could delete the pending report? |
| 14:28 |
Dyrcona |
fco_guel: You could, but it isn't necessary. |
| 14:29 |
Dyrcona |
Or wait, do you mean from reporter.pending_reports? You can't delete from there, it's a view. |
| 14:29 |
Dyrcona |
Grr. reporter.running_reports, I meant. |
| 14:31 |
|
kmlussier joined #evergreen |
| 14:31 |
Dyrcona |
heh.... |
| 14:31 |
Dyrcona |
reporter.currently_running.... :) |
| 14:36 |
fco_guel |
Dyrcona: I already run the command, Do I need to do any additional activity? Or just restart clarck kent? |
| 14:37 |
Dyrcona |
fco_guel: Just restart Clark. |
| 14:37 |
Dyrcona |
Shouldn't need to do anything else. |
| 14:52 |
* miker |
was about to go looking at 1750894 ... but NEVERMIND ;) |
| 14:52 |
miker |
berick++ |
| 14:52 |
miker |
kmlussier++ |
| 14:52 |
miker |
csharp++ |
| 14:54 |
|
mdriscoll joined #evergreen |
| 14:55 |
JBoyer |
berick, if you have time, I was curious what the rationale was for mutual exclusivity between workstation/user but fallthrough for org/workstation. I would think that org->workstation->user fallthrough would make the most sense? |
| 15:00 |
berick |
but sometimes org -> user -> workstation might make more sense. |
| 15:01 |
jeff |
berick: had a question for you on bug 1684970 -- no rush |
| 15:01 |
pinesol |
Launchpad bug 1684970 in OpenSRF "Proxy setup masks client IP needed by osrf-http-translator" [Medium,Confirmed] https://launchpad.net/bugs/1684970 |
| 15:01 |
berick |
jeff: basically, didn't want to get into building precedence for each setting type, so I punted. |
| 15:01 |
berick |
oope, JBoyer |
| 15:01 |
berick |
he, le oope |
| 15:01 |
* jeff |
dodges the misdirected tab completion |
| 15:02 |
csharp |
@band add Le Oope |
| 15:02 |
pinesol |
csharp: Band 'Le Oope' added to list |
| 15:02 |
JBoyer |
makes sense. It can always be added later if the additional flexibility(/complexity) becomes that desirable. |
| 15:02 |
berick |
csharp: a side project for Stereolab, surely |
| 15:02 |
JBoyer |
berick++ # because I forgot earlier :D |
| 15:02 |
csharp |
berick: obviously |
| 15:02 |
berick |
JBoyer: exactly |
| 15:03 |
csharp |
@dunno add uh huh.. please tell me more about that |
| 15:03 |
pinesol |
csharp: The operation succeeded. Dunno #59 added. |
| 15:04 |
berick |
jeff: sup? |
| 15:04 |
|
sandbergja joined #evergreen |
| 15:05 |
jeff |
berick: see my comment. looking for a concise test case for what you encountered that disqualified mod_remoteip as an option. mod_rpaf upstream seems defunct. |
| 15:05 |
jeff |
(it's still packaged, but it's starting to smell) |
| 15:06 |
berick |
jeff: ugh, well, remoteip didn't update the value in request_rec->connection->client_ip when I tested it. |
| 15:06 |
berick |
used by the translator C code |
| 15:06 |
miker |
berick: to clarify from your email, when you say "org setting" in the "Admins" section, are you referring to YAOUSen? and the fallthrough is in the direction of "look up a missing user setting, get the YAOUS", but not the other way (ever), right? |
| 15:06 |
berick |
miker: yes to YAOUSen (heh) |
| 15:07 |
berick |
and yes, if a user/ws setting type does not exist, see if an org setting type does and use its value instead |
| 15:07 |
berick |
applying a value to an org setting is not currently support, will require new UI bits for that |
| 15:08 |
berick |
w/ perm checks, of course |
| 15:08 |
jeff |
@voice sandbergja |
| 15:08 |
jeff |
@voice fco_guel kmlussier mdriscoll |
| 15:08 |
miker |
that, like Galadrial, is both beautiful and terrible ;) ... thanks |
| 15:09 |
miker |
(that's for berick, not @voice'ing) |
| 15:09 |
fco_guel |
Bmagic: Dyrcona , thanks, It worked |
| 15:09 |
berick |
let The Light of Eärendil be your guide |
| 15:10 |
JBoyer |
jeff, bshum, do either of you know if there's a bot plugin that can be used to auto-voice "known" nicks from a list? Seems like that would be simpler than manually voicing people now and then. |
| 15:10 |
berick |
jeff: it's possible that bit works in the latest code, it's been a while |
| 15:11 |
* berick |
will be AFK for a bit |
| 15:12 |
jeff |
JBoyer: nothing that i'm able to spend time on. we've just passed 12 hours since last spam attempt in here, so i'm likely to remove the mitigation shortly. |
| 15:13 |
JBoyer |
Sounds good. |
| 15:13 |
JBoyer |
jeff++ |
| 15:17 |
|
mdriscoll joined #evergreen |
| 15:18 |
|
mdriscoll left #evergreen |
| 15:51 |
|
sandbergja joined #evergreen |
| 15:52 |
jeff |
(In the possibly misguided hope that the spam has tapered off enough) |
| 15:58 |
|
abowling joined #evergreen |
| 15:58 |
|
abowling left #evergreen |
| 15:59 |
|
abowling joined #evergreen |
| 16:07 |
|
abowling joined #evergreen |
| 16:39 |
|
khuckins joined #evergreen |
| 17:20 |
|
khuckins_ joined #evergreen |
| 17:43 |
|
khuckins joined #evergreen |
| 18:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:40 |
|
balrog27 joined #evergreen |
| 18:54 |
|
Freejack19 joined #evergreen |
| 19:05 |
bshum |
Well, that's not a good sign jeff |
| 22:30 |
|
lunaaa joined #evergreen |
| 23:12 |
jeff |
*sigh* |
| 23:32 |
|
aykut22 joined #evergreen |
