Time |
Nick |
Message |
00:23 |
|
sandbergja joined #evergreen |
05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:32 |
|
JBoyer_alt joined #evergreen |
06:37 |
|
bos20k joined #evergreen |
06:55 |
|
agoben joined #evergreen |
07:15 |
|
rjackson_isl joined #evergreen |
07:17 |
|
JBoyer joined #evergreen |
07:47 |
|
bdljohn1 joined #evergreen |
07:55 |
|
bdljohn joined #evergreen |
07:56 |
|
bdljohn1 joined #evergreen |
07:57 |
|
bdljohn joined #evergreen |
08:00 |
|
bdljohn1 joined #evergreen |
08:00 |
|
bdljohn1 left #evergreen |
08:09 |
|
bdljohn joined #evergreen |
08:44 |
|
krvmga joined #evergreen |
08:45 |
|
mmorgan joined #evergreen |
08:46 |
|
Dyrcona joined #evergreen |
09:15 |
|
idjit joined #evergreen |
09:30 |
|
yboston joined #evergreen |
09:36 |
csharp |
seeing an issue similar to the one Bmagic reported the other day. In the Organizational Units UI, I click "New Child" to add a branch, it flashes red and nothing happens |
09:36 |
csharp |
XML Parsing Error: no root element found |
09:36 |
csharp |
Location: https://gapines.org/osrf-http-translator |
09:36 |
csharp |
Line Number 1, Column 1: |
09:36 |
csharp |
is the console error - nothing server side that I can see so far |
09:37 |
csharp |
I've uncommented the RemoteIP lines in eg_vhost.conf and enabled the remoteip mod |
09:37 |
csharp |
but no change |
09:41 |
csharp |
https://pastebin.com/MGzUFLph - my configs |
09:41 |
* csharp |
has to run to a meeting at his daughter's school - back later |
09:49 |
|
sandbergja joined #evergreen |
10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merge horizontal; optional holdings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=29882b4> |
10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merge fits container - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2ad575> |
10:03 |
Bmagic |
csharp: Do you have a machine seperate from the production cluster that you can test on? Things started becoming more clear once I did that |
10:03 |
pinesol |
[evergreen|Bill Erickson] LP1739293 Record merged edit-in-place avoid wrap - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df8973b> |
10:13 |
|
Dyrcona joined #evergreen |
10:40 |
csharp |
Bmagic: were you able to resolve your issue? |
10:40 |
Bmagic |
my issue was resolved by uncommenting the remote IP business in eg_vhost.conf |
10:40 |
csharp |
(yes, I do have a couple of production-ish test clusters) |
10:40 |
csharp |
ok cool |
10:41 |
Bmagic |
Not the same as your issue though |
10:41 |
Bmagic |
(We've not tried the org unit editor on our new production environment though, we may have the same issue) |
10:42 |
Bmagic |
berick++ # remote IP |
10:52 |
|
beanjammin joined #evergreen |
11:00 |
csharp |
ran autogen.sh but no help |
11:07 |
JBoyer |
It's not very likely, but something we saw that was similarly odd at one point was a sequence that was "behind" the ids in the database. This usually happened when an incoming migration was assigned this or that id number and then when time to put them into production the ids were inserted with them rather than using the default NEXTVAL()... |
11:07 |
JBoyer |
but you should be able to see duplicate id errors in your db logs if that's happening. |
11:20 |
Bmagic |
csharp: can you insert the row directly? |
11:21 |
Bmagic |
(I've found that the org unit interface is buggy to say the least) |
11:21 |
|
idjit joined #evergreen |
11:32 |
Bmagic |
dbwells: bug 1790896 may not have all the right tags, but it looks like it has a signoff |
11:32 |
pinesol |
Launchpad bug 1790896 in Evergreen "Printing Items out results in console error when Email address is missing" [Undecided,Confirmed] https://launchpad.net/bugs/1790896 |
11:34 |
Bmagic |
Just thought I would bring it up to put it on some radars (not for inclusion in 3.2 necessarily) |
11:34 |
Bmagic |
I'm not super familiar with our launchpad tagging/targeting scheme and for sure never have changed those things personally |
11:40 |
Bmagic |
I can't find the bug report but launchpad could be hiding it. When finalizing the registration from pending users, we receive an error STAGING_USER_STAGE_NOT_FOUND - not a big deal because the data was all saved just fine |
11:41 |
Bmagic |
I think the code is attempting to open the pending registration again after it's been finalized into actor.usr |
11:45 |
Dyrcona |
Ok. Lunch time.... BBIAB. |
11:57 |
|
khuckins_ joined #evergreen |
11:59 |
|
sandbergja joined #evergreen |
12:00 |
miker |
Bmagic: https://bugs.launchpad.net/evergreen/+bug/1765179 |
12:00 |
pinesol |
Launchpad bug 1765179 in Evergreen 3.2 "Web Client: STAGING_USER_STAGE_NOT_FOUND" [Medium,Fix released] |
12:00 |
Bmagic |
haha! I searched for that exactly and no results |
12:01 |
Bmagic |
miker++ |
12:02 |
Bmagic |
maybe because it omits released bugs? |
12:02 |
Bmagic |
All, |
12:03 |
Bmagic |
wrong window |
12:03 |
mmorgan |
Bmagic: To see released bugs in your results, you need to do an Advanced search and include Fix Released. |
12:03 |
Bmagic |
yeah, that's what I was thinking |
12:05 |
|
jihpringle joined #evergreen |
12:31 |
|
RMiller joined #evergreen |
12:32 |
RMiller |
How do I find the int system codes for organizational units and profile types in 3.2? I am trying to migrate patron data as described here: http://docs.evergreen-ils.org/3.2/_migrating_patron_data.html |
12:37 |
|
Dyrcona joined #evergreen |
12:39 |
|
RMiller joined #evergreen |
12:55 |
Dyrcona |
@who takes CC payments in the staff client |
12:55 |
pinesol |
darkdrgn2k3 takes CC payments in the staff client. |
12:55 |
sandbergja |
Rmiller: SELECT name, id FROM actor.org_unit; should do the trick |
12:55 |
sandbergja |
for org units |
12:56 |
sandbergja |
and SELECT name, id FROM permission.grp_tree; -- for the profiles |
12:56 |
sandbergja |
If you have SQL access |
12:58 |
RMiller |
Thank you! |
12:58 |
sandbergja |
RMiller: no problem! FWIW, this can be super helpful for questions like that: http://docs.evergreen-ils.org/3.2_schema/ |
13:00 |
Dyrcona |
I'd do something more complicated for the org_units. |
13:02 |
RMiller |
My org units are really really simple at the moment, so I think this does the trick for now, unless there's something else I should know? |
13:05 |
Dyrcona |
Yeah, I was just testing the SQL before sharing it. The work firewall doesn't always play nice. |
13:05 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Rmiller: Getting org_units that can have users" (5 lines) at http://paste.evergreen-ils.org/10236 |
13:06 |
RMiller |
Oh, gotcha. I can see how that would be handy. |
13:10 |
sandbergja |
Dyrcona++ |
14:13 |
Dyrcona |
berick: Do you think it would be difficult to implement a new billing screen in Angular that would fit in with the current AngularJS client? |
14:14 |
Dyrcona |
I'm asking in the context of looking at Lp 1774892. |
14:14 |
pinesol |
Launchpad bug 1774892 in Evergreen "Wishlist: Upgrade to Stripe v3 (elements)" [High,Confirmed] https://launchpad.net/bugs/1774892 |
14:15 |
* Dyrcona |
has to disappear shortly. |
14:18 |
jeff |
Dyrcona: are you suggesting using Stripe within a staff interface, where staff would key in patron card numbers/etc? |
14:18 |
Dyrcona |
jeff: Well, that's there already. We remove it as an option in our staff client. |
14:19 |
Dyrcona |
Unless I misunderstand what choosing the credit card payment option does. |
14:19 |
jeff |
There's currently a staff interface where you can use Stripe to process a payment? |
14:19 |
Dyrcona |
I don't really know. I don't use the staff client but it looks like yes. |
14:20 |
Dyrcona |
It's not Stripe specific. |
14:20 |
jeff |
If you're wanting to use Stripe for in-person payments, I'm pretty sure you can't/shouldn't use anything other than their (currently invite-only) Terminal offering: https://stripe.com/docs/terminal |
14:21 |
Dyrcona |
Open-ILS/web/js/ui/default/staff/circ/patron/bills.js |
14:21 |
Dyrcona |
OK. I don't disagree. I'm just looking at a "complete" solution. |
14:21 |
jeff |
Ah. Which one? |
14:21 |
Dyrcona |
Which may involve disabling credit card payments if Stripe is the processor. |
14:22 |
Dyrcona |
Stripe Elements as mentioned in the bug above. |
14:22 |
Dyrcona |
It will be relatively easy to do in the OPAC. |
14:22 |
* jeff |
reads bug |
14:22 |
Dyrcona |
The bug is short on details, but I've read the API documentation and been in touch with Stripe support this morning. |
14:25 |
Dyrcona |
If Stripe doesn't want "merchants" touching customer's cards, then that's easy....Just disable credit card payments in the web staff client if Stripe is the processor. |
14:31 |
Dyrcona |
jeff++ For making my work easier. :) |
14:35 |
|
khuckins joined #evergreen |
14:39 |
|
gsams_ joined #evergreen |
14:41 |
* Dyrcona |
ponders just deleting credit card as a payment option in the staff client and being done with it. :) |
15:17 |
jeff |
+1 |
15:26 |
JBoyer |
The current Stripe work is only in the OPAC. If you try to use it at a desk you'll get some random explosion because the backend can't communicate with the Stripe servers given CC numbers and the like. |
15:27 |
|
gsams joined #evergreen |
15:27 |
JBoyer |
We also hard-code the removal of the in-client processor. (and would be delighted to see it disappear as an option, especially if it makes OPAC payments simpler to deal with) |
15:28 |
* JBoyer |
was in meetings for a while or his responses would have been much more timely. :) |
15:34 |
csharp |
@blame add "but I never knew until this day that it was $who all along" |
15:34 |
pinesol |
csharp: The operation succeeded. Blame #30 added. |
15:44 |
|
sandbergja_ joined #evergreen |
15:53 |
Bmagic |
Has anyone else wanted the descriptions in the report template listing to return carriage? We want to break the descriptions up into easier to read sections. AKA \n converted to <br /> |
15:54 |
Bmagic |
You can press the enter button any number of times, but when viewed, it's squashed into a single word-wrapped line |
16:27 |
|
mmorgan left #evergreen |
16:38 |
|
Dyrcona joined #evergreen |
16:41 |
|
yboston joined #evergreen |
16:53 |
gsams |
Bmagic: I'd be all for that. |
16:54 |
Bmagic |
seems like a simple solution |
16:54 |
Bmagic |
replacing \n with <br /> |
17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-14T17:00:39,182624603-0400 -0> |
17:08 |
|
bdljohn left #evergreen |
17:10 |
Dyrcona |
For every problem, there is a solution that is simple, obvious and wrong. :) |
17:17 |
|
AMM_ joined #evergreen |
17:18 |
rhamby |
Dyrcona: It is also true that for every problem there are at least three solutions that are complex and wrong. And I'll be tempted to try at least one of them. |
17:18 |
Dyrcona |
:) |
17:19 |
Dyrcona |
I like "simple, obvious, and wrong...." Has a nice rhythm. :) |
17:19 |
Dyrcona |
Better than the original: "neat, plausible, and wrong." |
17:20 |
Dyrcona |
Complex solutions are invariably wrong in some part... :) |
17:23 |
rhamby |
But to apply occum's chainsaw, sometimes it's the only feasible one (speaking as an ex-goverment employee "standards" caused that quite a bit) |
17:24 |
Dyrcona |
Yeahp. |
17:25 |
miker |
Bmagic: how about just a <pre> tag? (or equiv) |
17:25 |
Bmagic |
yeah! |
17:25 |
miker |
there are others that preserve formatting... but <pre> is the one I'll aways remember |
17:25 |
* miker |
runs away |
17:26 |
Bmagic |
<xmp> maybe? |
17:27 |
Dyrcona |
<?php |
17:27 |
* Dyrcona |
ducks the flying USB sticks. |
17:27 |
Bmagic |
haha |
17:29 |
Dyrcona |
Re <xmp> Note: Do not use this element. |
17:29 |
* Dyrcona |
thinks that applies to <?php also. :) |
17:31 |
Dyrcona |
Bmagic: We can't use xmp because it was removed from the language in HTML5: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/xmp |
17:31 |
Dyrcona |
But, anyway... I didn't come here to talk about that. |
17:32 |
Bmagic |
:) |
17:32 |
Bmagic |
I was working from memory |
17:32 |
Bmagic |
<pre> it is then! |
17:32 |
Bmagic |
gsams: I expect your patch soon |
17:32 |
Dyrcona |
Sure. I had to look it up. I've never used it or seen it used. |
17:33 |
Bmagic |
I've written something using it... er.... probably 15 years ago. Funny how the mind can bring that stuff up |
17:34 |
Bmagic |
pretty sure it functioned just like <pre> |
17:39 |
Dyrcona |
Well, the description says it was close to <pre> but inconsistently implemented. Easiest thing was probably just make it work like pre. |
21:03 |
csharp |
@band add Disgusto Barfo |
21:03 |
pinesol |
csharp: Band 'Disgusto Barfo' added to list |
23:01 |
|
sandbergja joined #evergreen |