| Time |
Nick |
Message |
| 01:58 |
|
RBecker joined #evergreen |
| 04:32 |
|
mrisher joined #evergreen |
| 05:57 |
|
mrisher joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:51 |
|
mrisher joined #evergreen |
| 07:22 |
|
rjackson_isl_hom joined #evergreen |
| 07:23 |
|
Dyrcona joined #evergreen |
| 08:26 |
|
rfrasur joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:39 |
|
jvwoolf joined #evergreen |
| 09:00 |
|
stephengwills joined #evergreen |
| 09:05 |
rjackson_isl_hom |
Running into a selfcheck issue at a library trying to use the Get Receipt and Finish option. That never works for them, but the Quick Receipt and Continue does |
| 09:05 |
rjackson_isl_hom |
Has anyone run into thisand if so any workarounds? |
| 09:42 |
mmorgan |
rjackson_isl_hom: Is this the built in selfcheck? Just tested ours on a training server and Get Receipt and Finish worked. In what way does it not work? Does it just silently fail? |
| 09:43 |
rjackson_isl_hom |
according to the reporting library yes - just fails to print |
| 09:43 |
rjackson_isl_hom |
likewise tried locally on test server with success from home - printing to a pdf since I have no real printer |
| 09:44 |
rjackson_isl_hom |
and yes to the built in self check for Evergreen |
| 09:47 |
mmorgan |
rjackson_isl_hom: The selfcheck receipts are action triggers. Could the problem be with the trigger? |
| 09:47 |
rjackson_isl_hom |
are they defined with a default and then possibly one per branch if so desired? |
| 09:50 |
Dyrcona |
It's sad that consider 8 "not connected to the network" errors in the past half hour to be normal. |
| 09:50 |
mmorgan |
rjackson_isl_hom: Yes, that's how ours are set up. One for the consortium, and custom ones per branch if desired. Also, there are different action triggers for checkout, items out, holds, etc. |
| 09:51 |
rjackson_isl_hom |
mmorgan++ - more digging... |
| 09:52 |
csharp |
rjackson_isl_hom: you might learn something from the web console (including link to our docs you can push to your staff): https://pines.georgialibraries.org/dokuwiki/doku.php?id=admin:workstations:troubleshooting#retrieve_console_messages |
| 09:54 |
rjackson_isl_hom |
csharp++ mmorgan++ |
| 10:04 |
|
Cocopuff2018 joined #evergreen |
| 10:19 |
Dyrcona |
Just had conflict markers on a cherry-pick that make no sense. |
| 10:45 |
csharp |
it get's really fun if you miss a conflict and then see the conflict markers in the file when resolving subsequent conflicts :-) |
| 10:52 |
Dyrcona |
FYI I was making this branch: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lp1879983_curbside_pickup_pr_rel_3_5_2 |
| 10:55 |
Dyrcona |
I'm using that as a basis for an upgrade branch for one of our test VMs and our training server. |
| 10:58 |
stephengwills |
I’m trying to write an angular component to pull metadata from an union catalog api and display it in the staff client. the service shows the data arriving but the component doesn’t mange to put it in the template. I’d appreciate a little coaching on what i’m doing wrong. |
| 10:58 |
pastebot |
"stephengwills" at 168.25.130.30 pasted "post external api issue" (144 lines) at http://paste.evergreen-ils.org/10076 |
| 10:59 |
|
collum joined #evergreen |
| 11:01 |
pastebot |
"Bmagic" at 168.25.130.30 pasted "New EDI Order pusher bug" (13 lines) at http://paste.evergreen-ils.org/10077 |
| 11:02 |
Bmagic |
berick: We are trying to remove the old EDI pusher code in favor of the new one. It seems to me that there is still an outstanding issue with the new one which makes adopting it rough. The main thing is that it WILL send old orders still if the PO's are "on-order" and do not have and EDI message associated. The pasted query above finds those (I think) |
| 11:03 |
Bmagic |
I had two thoughts on that. 1. I could insert rows into acq.edi_message with a message_type of 'ORDERS' for all of the current "on-order" PO's that don't have an ORDERS row. |
| 11:04 |
Bmagic |
or 2. I could update the state of the PO to something other than "on-order" |
| 11:05 |
Bmagic |
option 2 could be a bad thing for fresh PO's (orders that are less than 6 months old) - option #1 seems to be the most safe. One thing that comes to mind is that not all of the PO's are associated with a Provider that has EDI assigned. In those cases, EDI doesn't apply anyway. However, there is a slight bug with this scenario: |
| 11:06 |
Bmagic |
Provider has been used for years, with thousands of orders. That provider has never had EDI. Then, one day, we add EDI to it. The pusher code would send the "backlog" of EDI to the provider. Bad. |
| 11:08 |
Bmagic |
IMO, there needs to be a new mechanism. A flag of some sort. That is recorded onto the PO when it's activated. Like a boolean "ready_for_EDI". The old method basically had that, by virtue of inserting rows into action_trigger.event |
| 11:17 |
berick |
Bmagic: hm, yeah, not cool. |
| 11:17 |
berick |
i could imagine another option where we add an edi_start_date column to acq.provider |
| 11:18 |
Bmagic |
that might work too, though the boolean flag on the PO gives us admins a bit of control over (re)sending |
| 11:22 |
berick |
thinking.. so all orders that are already activated (and have no edi messages attached) would be stamped as edi_ready=false |
| 11:22 |
Bmagic |
yeah, I was thinking that could be the default setting on the column |
| 11:22 |
berick |
going forward, when an order is activated if it looks like edi should work, stamp it as edi_ready=true |
| 11:22 |
Bmagic |
right |
| 11:23 |
Bmagic |
and the edi_order_pusher.pl would switch the flag back once it was finished with it |
| 11:24 |
berick |
ok so use the flag instead of the presence of a linked edi-order-message as the indicator to the order pusher that a PO needs a new new order message to be sent? |
| 11:24 |
Bmagic |
the select criteria could still incorporate "retry" on acq.edi_message |
| 11:25 |
stephengwills |
i got it |
| 11:25 |
stephengwills |
case problem in the model |
| 11:25 |
Bmagic |
it could be a bit more strict and require that there {NOT be ORDERS row, AND edi_ready=true} |
| 11:25 |
stephengwills |
sorry to waste anyones time. |
| 11:26 |
berick |
in that case we may want to leve flag alone once it's set |
| 11:26 |
berick |
to indicate the original disposition of the order |
| 11:27 |
Bmagic |
yeah, there we go. I like that even better. It means "this PO was type EDI when it was activated" |
| 11:28 |
Bmagic |
in which case, we might make that boolean more like a text column, where we could handle more than two "methods of delivery" |
| 11:29 |
berick |
i could see that |
| 11:29 |
Bmagic |
who knows, someday someone will think of EDIv2 |
| 11:30 |
Bmagic |
column name "delivery_method" |
| 11:30 |
Bmagic |
allowed values {'edi','manual'} |
| 11:30 |
berick |
.. Electric Boogaloo |
| 11:30 |
Bmagic |
haha, yeah |
| 11:31 |
Bmagic |
in the meantime, for now, is my best option (above) #1? |
| 11:31 |
|
ml9l joined #evergreen |
| 11:34 |
berick |
Bmagic: that or you could create a new provider |
| 11:34 |
berick |
make the existing provider non-EDI and make the new one EDI-capable, and move the newere orders to the new provider |
| 11:35 |
Bmagic |
In this case, it's PO's on providers who use JEDI, that have seriously old PO's (probably from migrations) -> new EDI pusher |
| 11:36 |
Bmagic |
the pastebin query above finds those offenders |
| 11:39 |
berick |
Bmagic: that query isn't limiting to EDI-capable providers |
| 11:39 |
Bmagic |
I'm aware |
| 11:40 |
Bmagic |
covering ALL basis |
| 11:40 |
berick |
gotcha |
| 11:41 |
Bmagic |
I can't think of a downside to inserting dummy rows into acq.edi_message |
| 11:41 |
berick |
me either, should be fine |
| 11:41 |
Bmagic |
groovy! Thanks, that's what I'll do. I'll make a LP bug for the aformentioned stuff |
| 11:42 |
berick |
now i'm curious if we have any. glad you found the issue! |
| 11:43 |
berick |
yeah, we have a few |
| 11:46 |
Bmagic |
I would guess most people do. Those that have been using Evergreen acq for a few years |
| 11:57 |
Bmagic |
berick: bug 1911786 |
| 11:57 |
pinesol |
Launchpad bug 1911786 in Evergreen "EDI Order Pusher needs tighter control over PO selection" [Undecided,New] https://launchpad.net/bugs/1911786 |
| 12:19 |
|
jihpringle92 joined #evergreen |
| 14:01 |
|
sandbergja joined #evergreen |
| 16:30 |
|
laurie joined #evergreen |
| 17:21 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:05 |
|
Christineb joined #evergreen |
| 19:05 |
|
troy__ joined #evergreen |
| 19:05 |
|
jeffdavis joined #evergreen |
| 19:05 |
|
eby joined #evergreen |
| 19:06 |
|
gryffonophoneme joined #evergreen |
| 19:06 |
|
lisacarlucci joined #evergreen |
| 19:06 |
|
phasefx joined #evergreen |
| 19:06 |
|
abneiman joined #evergreen |
| 19:06 |
|
miker joined #evergreen |
| 19:06 |
|
jweston joined #evergreen |
| 19:09 |
|
gryffonophenon joined #evergreen |
| 20:18 |
|
stephengwills left #evergreen |
| 20:53 |
|
sandbergja joined #evergreen |
| 21:44 |
|
dbwells_ joined #evergreen |
| 22:12 |
|
gryffonophenon joined #evergreen |
| 22:14 |
|
gryffonophenon joined #evergreen |
| 22:15 |
|
gryffonophenon joined #evergreen |
| 22:52 |
|
gryffonophenon joined #evergreen |
| 23:03 |
|
sandbergja joined #evergreen |
