| Time |
Nick |
Message |
| 06:30 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:05 |
|
jvwoolf joined #evergreen |
| 07:06 |
|
jvwoolf left #evergreen |
| 07:35 |
|
agoben joined #evergreen |
| 07:39 |
|
rlefaive joined #evergreen |
| 08:16 |
* csharp |
is intrigued by jeffdavis's comment on bug 1727557 |
| 08:16 |
pinesol_green |
Launchpad bug 1727557 in Evergreen "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] https://launchpad.net/bugs/1727557 |
| 08:17 |
csharp |
so I started looking at the lovefield.js spec and I don't think we can specify the bundledmode pragma without some redesign because we're building the schema dynamically (https://github.com/google/lovefield/blob/master/docs/spec/01_schema.md#lovefield-specification) |
| 08:18 |
csharp |
rather than statically, then compiling with SPAC: https://github.com/google/lovefield/blob/master/docs/spec/07_spac.md |
| 08:19 |
csharp |
with the latter option, the schema is defined in YAML, then the code is automatically generated from that |
| 08:19 |
csharp |
and the YAML schema definition allows pragma: |
| 08:19 |
* csharp |
should probably comment on the bug with this |
| 08:22 |
|
rjackson_isl joined #evergreen |
| 08:28 |
|
collum joined #evergreen |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:49 |
|
kmlussier joined #evergreen |
| 08:53 |
|
Dyrcona joined #evergreen |
| 08:59 |
|
bos20k joined #evergreen |
| 09:08 |
csharp |
anybody else out there hearing about Verizon (vtext.com) users not receiving SMS messages? |
| 09:08 |
* csharp |
found this: https://stackoverflow.com/questions/38552125/my-email-to-text-sent-to-vtext-com-stopped-working |
| 09:09 |
csharp |
and it looks like they're moving to a monetized SMS subscription system for "corporate" senders to 100+ subscribers: https://www.verizonwireless.com/support/enterprise-messaging-faqs/ |
| 09:14 |
|
jvwoolf joined #evergreen |
| 09:18 |
|
Christineb joined #evergreen |
| 09:29 |
mmorgan |
csharp: We've had intermittent reports of patrons not receiving text messages. Checking email logs shows us the message was delivered - but we can't tell what happened after that. |
| 09:29 |
mmorgan |
Not always Verizon users. |
| 09:31 |
|
bos20k joined #evergreen |
| 09:32 |
|
yboston joined #evergreen |
| 09:47 |
csharp |
mmorgan: thanks |
| 10:02 |
|
remingtron_ joined #evergreen |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:03 |
|
terran joined #evergreen |
| 10:06 |
|
dbwells joined #evergreen |
| 10:08 |
|
remingtron_ joined #evergreen |
| 10:14 |
jeff |
csharp: no known issues with Verizon here. we're using Twilio, though... |
| 10:15 |
* bshum |
liked Twilio |
| 10:17 |
jeff |
csharp: on Thursday there was an incident report of duplicate deliveries to Verizon customers -- they gave the all clear a little under three hours later. We received no reports of it from patrons that I was made aware of. |
| 10:18 |
csharp |
jeff: thanks |
| 10:24 |
terran |
Building power outage! Yay! |
| 10:30 |
|
dbwells_ joined #evergreen |
| 10:30 |
|
remingtron joined #evergreen |
| 10:33 |
|
dbwells__ joined #evergreen |
| 10:35 |
collum |
csharp: No one has reported anything pertaining to Verizon. But I just checked with a staff member who uses Verizon. She said she has received 1 text message for her last 4 holds. |
| 10:36 |
|
remingtron_ joined #evergreen |
| 10:38 |
csharp |
collum: good to know - thanks |
| 10:51 |
Dyrcona |
Having a live USB stick comes in handy sometimes. |
| 10:56 |
Dyrcona |
zfs++ |
| 11:08 |
|
mllewellyn joined #evergreen |
| 11:09 |
|
mmorgan joined #evergreen |
| 12:02 |
|
beanjammin joined #evergreen |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:25 |
|
yboston joined #evergreen |
| 12:26 |
|
khuckins joined #evergreen |
| 13:16 |
|
terran joined #evergreen |
| 13:47 |
|
mmorgan1 joined #evergreen |
| 13:57 |
|
mmorgan joined #evergreen |
| 14:20 |
kmlussier |
jeffdavis: I haven't looked at a server with the ebook api enabled in a while. Do you know if bug 1677813 continues to be a problem in 3.0+? I was thinking the added features for 3.0 may have resulted in a working download link. |
| 14:20 |
pinesol_green |
Launchpad bug 1677813 in Evergreen "Ebook API: OverDrive download link non-functional in My Account" [Undecided,New] https://launchpad.net/bugs/1677813 |
| 14:28 |
jeffdavis |
kmlussier: that one is 2.12 specific |
| 14:29 |
kmlussier |
jeffdavis: OK, I'm going to set that one to Won't Fix then since Wednesday is our last 2.12 maintenance release. |
| 14:35 |
Dyrcona |
Heh. I'd like to see any of it work, but alas.... |
| 14:36 |
Dyrcona |
Testing is not going well. |
| 14:51 |
jeffdavis |
Dyrcona: are you willing/able to try testing against their production environment? I found their integration environment annoying to deal with - getting auth and endpoints straight, different records and record IDs... |
| 14:52 |
Dyrcona |
They tell me to work with their integration environment. I'm getting a 404 when looking up the test library, so it's on them, now. |
| 14:53 |
Dyrcona |
I'm willing to just turn it on and go, but they won't do that until it has passed their tests in the integration environment. |
| 15:20 |
Dyrcona |
I apparently broke my output folders just by updating the shared and shared_with values, or does Clark need to be running to see output? |
| 15:21 |
Dyrcona |
Don't worry it's a test database. ;) |
| 15:38 |
kmlussier |
Dyrcona: Clark needs to be running in my experience. |
| 15:50 |
|
yboston joined #evergreen |
| 15:50 |
Dyrcona |
Well, I'm still not seeing any report output. |
| 15:51 |
|
khuckins joined #evergreen |
| 15:54 |
|
rlpipeep joined #evergreen |
| 16:00 |
Bmagic |
Is there a reason that acq would remove the encumbrances from a PO after a single invoice has been processed? And not finalized? |
| 16:06 |
berick |
Bmagic: as in, set encumbrance=false or delete the fund debits? |
| 16:06 |
Bmagic |
delete the fund debits |
| 16:06 |
Bmagic |
it's a blanket po if that matters |
| 16:10 |
berick |
a quick review suggests fund debits are only deleted when invoice_items or po_items are deleted or when lineitems or POs are canceled |
| 16:11 |
Bmagic |
hmm, I wonder if the create_time has something to do with it |
| 16:12 |
Bmagic |
I am finding that the two manually created charges are timestamped after the debits in select * from acq.fund_debit where fund=xxx order by create_time |
| 16:12 |
|
mllewellyn1 joined #evergreen |
| 16:23 |
|
dpearl joined #evergreen |
| 16:24 |
|
yboston joined #evergreen |
| 16:25 |
Bmagic |
berick: more on this, running through the routine on a test machine. I create a dummy PO, add two charges attached to the same fund (materials and tax) - after I activate the PO, I see the rows in acq.fund_debit with encumberance='t' |
| 16:25 |
Bmagic |
which is (I think) correct |
| 16:25 |
Bmagic |
that is to say, I think that's what the system is supposed to do |
| 16:26 |
Bmagic |
now, the next step is to create an invoice, and chip away at each of those charges with an invoie |
| 16:27 |
|
mmorgan1 joined #evergreen |
| 16:28 |
Bmagic |
This is when things get weird, instead of adding rows to acq.fund_debit, it replaces the rows with the invoice values that I just entered. Is that right? |
| 16:30 |
Bmagic |
I am finding the rows in acq.po_item instead (the amounts that were previously in acq.fund_debit) |
| 16:36 |
kmlussier |
Are there really LP bugs on losing local storage settings when clearing cache / rebooting? I don't think I've seen anything on that. |
| 16:36 |
berick |
Bmagic: i'm totally lost in where you are. can you describe a simple step-by-step to create the issue? |
| 16:36 |
kmlussier |
Also, Several functions require being applied twice before the the function is performed. |
| 16:39 |
berick |
kmlussier: not aware of any such bugs, with the possible excecption of people conflating cache-cleraing with all-browse-data-clearing |
| 16:55 |
Bmagic |
berick: sorry - sure - Create PO -> Add charge (x2) -> Activate. Now the rows are in acq.fund_debit equal to the two charges |
| 16:57 |
Bmagic |
Now: Create Invoice -> enter a smaller amount of each of the charges into amount billed. The paid values are automatically populated. Then click "close" - now the rows in fund_debit with the amounts from the charges are gone (or replaced) with the amounts entered in the invoice |
| 17:00 |
Bmagic |
I didn't check after phase one if there were already rows in acq.po_item. I am running through it again and I'll check that |
| 17:08 |
berick |
Bmagic: when I do the same using a blanket charge type and creating 1 PO charge, after I create the invoice, I get a new run in fund_debit linked to the invoice_item, and I still have the old row in fund_debit w/ the original amount linked to the po_item. |
| 17:08 |
Bmagic |
ok, yeah, after activation, there are rows in acq.fund_debit AND acq.po_item |
| 17:08 |
|
mmorgan1 left #evergreen |
| 17:09 |
Bmagic |
I'll take a look at the logs and see what it's doing when I add the invoice. Whatever it's doing, it's removing the two rows in acq.fund_debit which makes it report a total encumbered=0 |
| 17:12 |
|
jvwoolf left #evergreen |
| 17:13 |
Bmagic |
berick: I have it in the logs acq.fund_debit.update id=1619434. It is clearly updating the fund_debit rows that were previously set encumbered='t'. now it's calling |
| 17:13 |
Bmagic |
fund=6334 origin_amount=50 origin_currency_type=USD amount=50 encumbrance=f debit_type=direct_charge create_time=2018-03-19T17:07:14-0400 invoice_entry= isnew= ischanged= isdeleted= |
| 17:15 |
Bmagic |
the amount on the original row was 508.50. So it overwrote the row with an amount of 50, and changed the encumbrance value to false |
| 17:19 |
berick |
my last comment was slightly off re; the original debig |
| 17:19 |
Bmagic |
ha! And get this, the next invoice I created on the same PO did the same thing! I overwrote the same two rows with the values from the second invoice bill amounts |
| 17:19 |
Bmagic |
It* overwrote |
| 17:20 |
berick |
Bmagic: so for blanket orders, there's a "root" debit, any other debits applied to same po_item result in a payment and a subtraction of the same amount from the "root" debit. |
| 17:20 |
berick |
its origin_amount remains the same, but it's amount is subtracted to reflect all linked payments |
| 17:21 |
Bmagic |
so it should be overwriting those same two rows in acq.fund_debit? |
| 17:21 |
berick |
yes, the original debits are modified with each blanket payment |
| 17:21 |
Bmagic |
The problem that I am trying to solve is that after the first invoice is processed - the PO reports encumberances = 0 |
| 17:22 |
berick |
values decreased equal to the amount paid w/ each addition debit added |
| 17:24 |
berick |
Bmagic: that I can't explain. in the test I just did w/ a $25 charge and a $10 payment, the PO shows $15 encumbered. |
| 17:25 |
berick |
Bmagic: to be clear, you didn't check the "finalize" box in the invoice? |
| 17:25 |
Bmagic |
where does it get the data to decide how much is emcumbered? |
| 17:25 |
Bmagic |
I made the assumption that it was from fund_debit where encumbered='t' |
| 17:26 |
berick |
Bmagic: the original/root debit from the po_item tells you how much is left enucmbered |
| 17:26 |
berick |
which again should match the original charge, minus any invoiced payments |
| 17:26 |
Bmagic |
invoice_payment? |
| 17:26 |
berick |
well, payments applied in an invoice |
| 17:27 |
Bmagic |
sorry, lol, that's not a table |
| 17:27 |
berick |
fund_debits linked to acq.invoice_items |
| 17:29 |
Bmagic |
when creating the invoice, I shouldn't expect more rows to be added to fund_debits? Furthermore, the rows that were put there when the PO was activated should just have their amounts subtracted from. For example 500 in fund_debit should be come 450 after an invoice payment of 50? |
| 17:30 |
berick |
for blanket charges, a payment in an invoice does create a new fund_debit to track the partial payment amount. at the same time, the partial payment amount is subtracted from the original debit. |
| 17:31 |
berick |
start with a debit of 500, pay 50, end up with a new debit of $50 and the original debit amount dropping to $450. |
| 17:31 |
Bmagic |
the original amount is stored in po_item? |
| 17:31 |
berick |
and $450 encumbered, and $50 paid |
| 17:31 |
berick |
Bmagic: yes |
| 17:32 |
berick |
the fund_debit linked to the original po_item is the source debit for the blanket order. |
| 17:32 |
berick |
it retains the origin_amount (original amount encumbered) and the 'amount' current amount encumbered |
| 17:32 |
Bmagic |
something is malfunctioning here because I am getting 0 encumbered once I create the first invoice for the PO and only pay 50 of 500 |
| 17:33 |
berick |
Bmagic: you didn't answer my question before.. are you clicking the "finalize" checkbox in the invoice page? |
| 17:33 |
Bmagic |
oh, sorry, no, I am not clicking that |
| 17:33 |
Bmagic |
I am clicking on "close" |
| 17:33 |
berick |
ok, good, because that would cause what you are seeing. |
| 17:33 |
berick |
"close" is fine |
| 17:34 |
Bmagic |
right, I figured. Which makes me wonder if it's getting the signal to finalize without me clicking that button |
| 17:34 |
berick |
and also, i assume you are not clicking the "finalize blanket order" on the PO page? |
| 17:34 |
Bmagic |
right, no |
| 17:34 |
berick |
k |
| 17:34 |
berick |
Bmagic: and you're positive the charge type has "blanket=true" ? |
| 17:35 |
Bmagic |
which table? |
| 17:35 |
berick |
acq.invoice_item_type |
| 17:35 |
berick |
(misnomer, they are used for po_item's too) |
| 17:36 |
Bmagic |
no, blanket = false |
| 17:36 |
berick |
that's your problem then |
| 17:36 |
Bmagic |
for the two charges that I put ont he invoice |
| 17:37 |
Bmagic |
oh, well, user error? |
| 17:37 |
berick |
if the goal is to make multiple payments for a single po_item, it has to be a blanket charge type |
| 17:37 |
berick |
otherwise it's just a thing that's paid for once. |
| 17:37 |
Bmagic |
oh boy, thanks! I am still learning this acq schema (obviously) |
| 17:37 |
Bmagic |
berick++ |
| 17:38 |
berick |
yep. /me is still re-learning |
| 17:38 |
Bmagic |
berick++ # thanks again, much needed karma for the serious amount of time you spend with me |
| 17:51 |
Bmagic |
berick: is there an issue with receiving invoices going forward on a PO that was setup with non-blanket charges? |
| 17:53 |
berick |
well you can only pay for (invoice) a po_item once if it's non-blanket. if the PO has other stuff (lineitems) that still need to be paid for, you should be able to continue adding invoices to cover those |
| 17:54 |
Bmagic |
hmmmm, it seems that the system allows for creating more invoices on PO's that are 100% non-blanket |
| 17:54 |
berick |
i'm not saying there are no bugs, just speaking generically |
| 17:55 |
Bmagic |
the staff made a mistake when defining charges for a PO and did not choose a charge type that is blanket when they meant to. Now, we have an activated PO with several invoices coming in..... |
| 17:56 |
Bmagic |
I am starting to understand now why rows are added to invoice_item that refer to the same row id in fund_debit |
| 17:57 |
Bmagic |
perhaps this is a bug? |
| 17:58 |
berick |
hm, it does sound like something the system should take some measures to prevent. |
| 17:59 |
Bmagic |
AZEEEZ! LIGHT! |
| 18:00 |
* berick |
steps away |
| 18:00 |
Bmagic |
https://www.youtube.com/watch?v=mvwd13F_1Gs |
| 18:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 18:47 |
|
Dyrcona joined #evergreen |
| 21:54 |
|
mllewellyn joined #evergreen |
