| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 05:50 |
|
bshum joined #evergreen |
| 07:08 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1654534: Prevent loop that occurs when staff us 'place another hold' link - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cc481b0> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
agoben joined #evergreen |
| 07:27 |
|
kmlussier joined #evergreen |
| 07:40 |
|
Callender joined #evergreen |
| 07:42 |
bshum |
@later tell gmcharlt Was talking to kmlussier and wanted to inquire about doing a POT sync and PO sync for master to get new strings into play and also updated files for Arabic for testing. As buildmaster 2.12, checking with you as well, but I don't see any harm in doing more i18n sync-ups. Opinion? |
| 07:42 |
pinesol_green |
bshum: The operation succeeded. |
| 07:47 |
bshum |
That may or may not affect any decision or changes necessary for 2.11 support for Spanish actually. Before the next POT, if we do any PO sync we can probably still safely backport them before any string updates in templates for master take effect. |
| 07:47 |
bshum |
If we want to, it's our last chance to do any PO sync from LP translations before we do a POT sync for new template strings drift. |
| 09:58 |
berick |
csharp: what are you trying to do? |
| 09:59 |
Dyrcona |
berick: He's trying to build hatch. |
| 10:00 |
|
mmorgan1 joined #evergreen |
| 10:00 |
berick |
well, more to point, csharp if you're just testing Windows for now, you don't have to compile. the libs are included in the insatller I posted on the ticket. if you want to build and/or run on linux, then carry on :) |
| 10:01 |
berick |
also the -Xdiags:verbose can be removed if it's causing problems. it's just for debugging. it's never cause probs for me, though, in either flavor of jdk |
| 10:02 |
Dyrcona |
berick: Am I right that hatch requires JavaFX for printing? |
| 10:02 |
berick |
csharp: oh, and you should be able to compile without X, but not run it |
| 10:02 |
berick |
Dyrcona: yes, openjfx is required on linux |
| 10:19 |
JBoyer |
Yeah. |
| 10:19 |
kmlussier |
copy_counts.tt2 shows up in the record detail page, right? |
| 10:20 |
kmlussier |
No, you said search results. Let me check there. |
| 10:20 |
csharp |
we usually keep our test server at the previous version for a few weeks post upgrade exactly for "it did X before the upgrade" issues |
| 10:22 |
kmlussier |
On 2.10, it is included Lost (and I assume missing) in the Y of x of Y accounts when logged into the staff client. |
| 10:22 |
JBoyer |
csharp, that's not a bad idea (provided thing are caught in time... we're a a month and a half out now.) |
| 10:22 |
JBoyer |
Ah. |
| 12:23 |
kmlussier |
If you hadn't found those already. |
| 12:24 |
mmorgan |
kmlussier is reading my mind :) |
| 12:24 |
mmorgan |
kmlussier++ |
| 12:24 |
* kmlussier |
runs out to buy lunch for the three family members who spent the morning shoveling snow while I tested code inside a warm house. |
| 12:25 |
sandbergja |
Hey everyone! I have a student here who will be helping out with the DIG hackaway next week. Who's the best person to get her an account on the wiki? |
| 12:26 |
|
jihpringle joined #evergreen |
| 12:29 |
sandbergja |
Is anybody still checking the docs evergreen-ils.org email account? |
| 13:06 |
kmlussier |
I see a lot of outdated info there. |
| 13:06 |
* bshum |
misses anoop :( |
| 13:07 |
bshum |
But as far as wiki admins go, there are lots of them in this room, myself included |
| 13:19 |
kmlussier |
berick: OK, finally getting to this party. I'm going through install steps again. Last week, I recall you asked about an evergreen directory, which I did not have. |
| 13:20 |
kmlussier |
I see making this directory is part of the optional Test Hatch steps. So should I consider that a non-optional step? |
| 13:21 |
berick |
kmlussier: the directory should be created by hatch when needed to store data |
| 13:21 |
berick |
but for now I would go ahead and create it and run the hatch test |
| 13:21 |
berick |
just to rule that out |
| 13:21 |
kmlussier |
ok, will do |
| 13:22 |
berick |
when the hatch test succeeds, btw, it just looks like a bunch of log entries |
| 13:22 |
berick |
it's not super friendly. the messages should not look like errors, though |
| 13:22 |
gmcharlt_ |
sandbergja: currently Yamil, rsouliere, phasefx, me, sdineen |
| 13:22 |
gmcharlt_ |
sandbergja: fair to assume that you'd like to be added? |
| 13:23 |
|
gmcharlt joined #evergreen |
| 13:28 |
sandbergja |
Okay! I see them now! |
| 13:29 |
jihpringle |
gmcharlt_: can you remove sdineen as an admin from that list? She isn't really involved in DIG anymore |
| 13:29 |
jihpringle |
sandbergja: if you want someone from the the BC Coop on the admin list I'm happy to be added |
| 13:30 |
berick |
kmlussier: just tested without manually creating the directory. at first, it showed an error, because the logging could not write to the log file, but then the first time the test tries to store data, it creates the directory (and then the logger is happy). |
| 13:32 |
gmcharlt |
jihpringle: I've removed her |
| 13:32 |
jihpringle |
thanks |
| 13:54 |
csharp |
TIL that you need AngularJS installed to run the web client |
| 13:58 |
berick |
the more you know.. *rainbow swipe* |
| 14:02 |
dbs |
csharp: you need AngularJS installed on your client to run the web client? o.0 |
| 14:05 |
dbs |
As part of Hatch? |
| 14:07 |
csharp |
dbs: no - I just realized that my test box didn't have it installed :-) |
| 14:07 |
csharp |
Hatch just needs java |
| 14:07 |
csharp |
and Chrome, I guess (at least I'm testing the Chrome(ium) extension) |
| 14:09 |
berick |
csharp: ugh, i think the windows installer only knows about Chrome at the moment. :( IIRC, chromium uses different registrey keys for native messaging |
| 14:09 |
csharp |
yeah - I'm using Chrome on Windows |
| 14:09 |
csharp |
s'okay |
| 14:16 |
bmills |
Bmagic++ lp 1532236 |
| 14:16 |
pinesol_green |
Launchpad bug 1532236 in Evergreen "Evergreen should allow for HTML formatted action trigger emails" [Wishlist,Confirmed] https://launchpad.net/bugs/1532236 |
| 14:17 |
bmills |
libraries are loving being able to include their logo for the new welcome to the library email |
| 14:18 |
kmlussier-clone |
berick: I had trouble running the Hatch test, so I removed the echo off the the beginning of the file and am seeing this - http://pastebin.com/rDKxqXev |
| 14:19 |
kmlussier-clone |
Apologies for the bad line breaks in that paste. |
| 14:19 |
kmlussier-clone |
@blame windows |
| 14:19 |
pinesol_green |
kmlussier-clone: windows 's bugfix broke kmlussier-clone's feature! |
| 14:19 |
csharp |
OMG a clone! |
| 14:21 |
kmlussier-clone |
csharp: Yes, while I work on hatch, kmlussier is working on authority testing. Or maybe she's just drinking coffee. |
| 14:22 |
csharp |
wow - I want one |
| 14:22 |
berick |
kmlussier-clone: ok, it's referencing a bad Java path |
| 14:22 |
csharp |
those movies never end well, though, so maybe not :-/ |
| 14:23 |
berick |
kmlussier-clone: do you have a directory C:\Program Files\Java ? |
| 14:23 |
berick |
and if so, what's in that directory |
| 14:24 |
kmlussier-clone |
Yes, it has a directory called jre1.8.0_121 |
| 14:24 |
berick |
ok.. you'll need to edit hatch.bat |
| 14:25 |
berick |
and where it says jdk1.8.0_111 replace it with jre1.8.0_121 (near the top) |
| 14:25 |
berick |
note to self: just use whatever java is in the path on windows |
| 14:26 |
berick |
those environment variables were useful for testing, but now they're just getting in the way |
| 14:26 |
csharp |
Hatch is Available ! |
| 14:26 |
berick |
csharp++ # woohoo |
| 14:26 |
berick |
csharp: can you see printers in the printer admin? |
| 14:29 |
berick |
csharp: ignore that |
| 14:29 |
kmlussier-clone |
csharp: Broken, as in screens aren't loading? |
| 14:30 |
csharp |
kmlussier-clone: correct |
| 14:30 |
berick |
csharp: ok, can you try the hatch test please? |
| 14:30 |
berick |
from the command line |
| 14:30 |
kmlussier-clone |
csharp: Yeah, that's what happened when I tried last week. I haven't gotten that far yet today. |
| 14:30 |
csharp |
sure |
| 14:31 |
berick |
i bet you're having the same issue as kmlussier-clone , bad java path |
| 14:32 |
* berick |
tries a test w/ no hard-coded paths.. |
| 14:33 |
csharp |
yep, I can see the path is wrong |
| 14:35 |
berick |
ok, cool, works fine without the hard-coded paths |
| 14:35 |
* berick |
pushes to repo |
| 14:38 |
csharp |
yep - it works fine after changing the path |
| 14:38 |
csharp |
I don't have any printers available to this VM, so I'll have to test for real next week |
| 14:39 |
berick |
csharp: can you try the 'copy settings to hatch' button in the hatch UI? |
| 14:39 |
* berick |
just pushed this BTW http://git.evergreen-ils.org/?p=working/Hatch.git;a=commitdiff;h=720d7579a661dbca8a41bff0275f6df5edd24b51 |
| 14:39 |
csharp |
Settings successfully migrated |
| 14:41 |
* berick |
suddenly feels less alone in the world |
| 14:41 |
csharp |
we're right behind you.. well several miles back, but you get the idea ;-) |
| 14:54 |
JBoyer |
csharp, Quick note since I just noticed "I don't have any printers available in this VM.": Last I knew Windows will let you add a "Generic Plain Text" printer connected to the LPT port which doesn't actually require it to be available or connected. |
| 14:55 |
JBoyer |
Doesn't allow you to really test printing, but it will get you the Printer Properties dialog if that's what you want to test in Hatch. |
| 14:58 |
csharp |
I'll try that |
| 14:58 |
csharp |
after I'm sure this works on Windows, Linux is next |
| 15:04 |
csharp |
the PDF printer works |
| 01:54 |
|
Callender_ joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:06 |
|
genpaku joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
agoben joined #evergreen |
| 09:07 |
rhamby |
@weather 30046 |
| 09:07 |
pinesol_green |
rhamby: Lawrenceville, GA :: Partly Cloudy :: 43F/6C | Wind Chill: 34F/1C | Thursday: Mostly sunny and windy. High 49F. Winds NW at 20 to 30 mph. Thursday Night: Clear skies. Low 28F. Winds NW at 10 to 15 mph. | Updated: 12m ago |
| 09:08 |
rhamby |
kmlussier: not today and probably not tomorrow but next week I'm going to force myself to deal with some outreach stuff. how is next week looking for me bothering you? |
| 09:17 |
kmlussier |
rhamby: Well, it is feature freeze at the end of next week, so I'll be doing a lot of testing. But I should be around. |
| 09:18 |
rhamby |
kmlussier: I don't know how much I'll need to bug you but I'll probably at least want to bounce a few ideas off you |
| 09:19 |
|
maryj joined #evergreen |
| 09:21 |
kmlussier |
Dyrcona: So I should hold off on bug 1005040 until the issue you mentioned in comment 11 is addressed? |
| 10:41 |
pinesol_green |
[opensrf|Galen Charlton] LP#1652122: fix infinite recursion in opensrf.system.method.all - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=bd5fc63> |
| 10:42 |
Dyrcona |
And, I'll pickup that one, too. :) |
| 10:48 |
Dyrcona |
miker: Yep. Looks like that one fixes that. |
| 10:48 |
miker |
cool, thanks for testing. have time to sign off, etc? |
| 10:50 |
Dyrcona |
Yeah, I was just looking at the code before signing off. Should I just push it to master? |
| 10:56 |
miker |
let me make sure of that... |
| 10:57 |
miker |
yes, I think so for now |
| 11:49 |
|
brahmina joined #evergreen |
| 12:03 |
|
sandbergja joined #evergreen |
| 12:06 |
|
bmills joined #evergreen |
| 12:09 |
* csharp |
builds a Windows 10 workstation to start testing hatch |
| 12:18 |
berick |
csharp++ # i'm around if hit any snags. since so few have tread there, i'm guessing you will. |
| 12:19 |
* berick |
is reminded of a docs change he meant to make after kmlussier's testing last week.. |
| 12:19 |
berick |
oh right the permission granting |
| 12:22 |
* berick |
pushed the doc update |
| 12:23 |
csharp |
berick: thanks |
| 12:23 |
|
jihpringle joined #evergreen |
| 12:29 |
kmlussier |
berick: I'll check that out as soon as I get back to testing hatch. Thanks! |
| 12:30 |
berick |
kmlussier: cool, i believe your past that step, btw, so my doc change probably won't have any effect your testing. |
| 12:30 |
berick |
unless you start over |
| 12:30 |
kmlussier |
berick: I was thinking of starting over. |
| 12:31 |
* berick |
nods |
| 12:42 |
|
jihpringle joined #evergreen |
| 15:56 |
berick |
Dyrcona: indeed, and the Actions drop-down above the grid |
| 15:57 |
Dyrcona |
Oh. Missed the Actions drop down, 'cause I think it is all the way to the left in XUL, but I might be wrong. |
| 16:02 |
Dyrcona |
So, I have half of a fix. More work required. |
| 16:04 |
pinesol_green |
Showing latest 5 of 17 commits to Evergreen... |
| 16:04 |
pinesol_green |
[evergreen|Mike Rylander] LP1281280: Allow test script to run without a full installation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9a03ed4> |
| 16:04 |
pinesol_green |
[evergreen|Mike Rylander] LP#1005040: Styling cleanup for filter display - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f12cc28> |
| 16:04 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1005040: Release notes entry for advanced search limiter improvements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=32d9fd0> |
| 16:04 |
pinesol_green |
[evergreen|Mike Rylander] Adjust comment about apostrophes in opensearch code. This is a marker for future work. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=38ca8cc> |
| 16:04 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1005040: Stamping upgrade script for realign search layers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c9afb45> |
| 16:16 |
Dyrcona |
Right click is now acting weird on me. It's taking me to Item Status as if I'd left clicked. |
| 16:16 |
Dyrcona |
The menu pops up and then I end up at Item Status. |
| 16:17 |
* Dyrcona |
blames low RAM and/or Firefox. |
| 16:56 |
|
bmills joined #evergreen |
| 16:58 |
kmlussier |
Ok, so if I'm on the Harry Potter record, it will provide a link to any editions that match particular formats. When it lists the 'book' format, it's based on the icon_format definition. |
| 16:59 |
kmlussier |
But when you click the link, it's limiting to search_format='book', which is defined entirely differently from the icon format, so you get a different number of results than you expected. |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
kmlussier |
We know both need to be based on the same record attribute so that the counts match up correctly, but we were just looking for direction on which one should be used. |
| 17:02 |
kmlussier |
I think Bmagic saw a benefit to re-using the code that was being used for icon formats, but then that means we would be filtering by icon_format when clicking the link. This works, but some might find it strange to limit based on icon format. |
| 17:04 |
Dyrcona |
icon_format makes sense because it often corresponds to what people think of as item types. |
| 17:05 |
JBoyer |
I didn't think icon_format had Filter set to True, but it does so I suppose that should work out fine. |
| 17:10 |
kmlussier |
Yes, I did some testing with icon_format and had no trouble filtering the results that way. |
| 17:10 |
* miker |
reads up |
| 17:12 |
|
mmorgan left #evergreen |
| 17:15 |
miker |
is it too much to have a new YAOUS that defines how a site wants to divide up their MR types? |
| 04:40 |
|
ldw_ joined #evergreen |
| 04:40 |
|
phasefx__ joined #evergreen |
| 04:40 |
|
jeffdavi1 joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
tspindler joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
kmlussier joined #evergreen |
| 12:28 |
berick |
csharp: excellent |
| 12:29 |
csharp |
berick++ |
| 12:29 |
csharp |
this was totally worth your time :-) |
| 12:30 |
berick |
csharp++ # testing machine |
| 12:30 |
csharp |
pines++ # the ultimate test case |
| 12:30 |
berick |
seriously |
| 12:30 |
berick |
the reference install of evergreen |
| 12:39 |
Dyrcona |
csharp++ berick++ |
| 15:39 |
Dyrcona |
Well, last time I cleared cache it was on a drone server because it was acting "weird" compared to the others, so I thought I'd see what happened after I cleared it. |
| 15:39 |
Dyrcona |
It went right on being weird. |
| 15:45 |
Dyrcona |
Meh. I have like 3.7GB "available." The VM is configured for 4GB, but it really won't use more than 1-2GB once it is actually running. |
| 16:10 |
Dyrcona |
Oh well. Doesn't look like I'll get to test that branch today. |
| 16:16 |
|
brahmina joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:10 |
Bmagic |
csharp: kmlussier: bug 1508208 is pretty much the same as 1416438 or at least (most likely) has the same root issue |
| 17:10 |
pinesol_green |
Launchpad bug 1508208 in Evergreen "Checkin age based hold protected item may not fill fillable holds" [Undecided,New] https://launchpad.net/bugs/1508208 |
| 17:31 |
pinesol_green |
Launchpad bug 1416438 in Evergreen "slow hold placement on titles with many copies" [Undecided,Confirmed] https://launchpad.net/bugs/1416438 |
| 17:32 |
Bmagic |
sweet! |
| 17:50 |
csharp |
well, I can definitely say that the example bib I cited in that ticket taking 15+ seconds took < 1 second with the new targeter + latest patches |
| 17:51 |
berick |
and to be fair, that specific hold may not have taken 15 seconds with the current targeter. so apples/oranges |
| 17:51 |
berick |
unless csharp tested that too |
| 17:55 |
* csharp |
didn't |
| 17:56 |
csharp |
I can say though, that since day one on new hardware (faster processors) and the new hold targeter, we've gotten many positive comments from staff about improved hold placement speed in general |
| 17:57 |
csharp |
I'll do some investigation of old vs. new (though "old" was on older slower HW) |
| 00:34 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1534787 Patron Message Center port - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a6f1a4f> |
| 03:08 |
|
abowling joined #evergreen |
| 05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
bshum |
jetlag-- |
| 07:03 |
bshum |
breakfast++ |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 09:51 |
* pinesol_green |
brews and pours a cup of Ethiopia Yirgacheffe Koke, and sends it sliding down the bar to Bmagic |
| 09:52 |
* Bmagic |
sits up at attention |
| 09:52 |
Bmagic |
Ethiopia knows what they are doing |
| 09:53 |
Dyrcona |
Hmm.. I just setup opensrf on a test VM. Services are up and running, but when I ran srfsh, I got this "Unable to bootstrap client for requests" |
| 09:56 |
Dyrcona |
log says it can't authenticate with jabber... |
| 09:57 |
* csharp |
suspects the ejabberd nightmare he experienced a couple of weeks ago |
| 09:57 |
Dyrcona |
Nope. Simpler than that. |
| 09:57 |
Dyrcona |
I was put the password in for the router user when I wanted the opensrf user's password, in .srfsh.xml. |
| 09:57 |
csharp |
ah |
| 09:58 |
Dyrcona |
And I got 4 for the opensrf.math test, so that works. :) |
| 09:59 |
Dyrcona |
Next, I get to transpose our Apache 2.2 config to Apache 2.4. |
| 10:02 |
* Dyrcona |
is preparing to upgrade to Debian 8. |
| 10:02 |
berick |
csharp: thanks! taking a look |
| 10:49 |
dbs |
JBoyer++ |
| 10:49 |
Dyrcona |
dbs++ |
| 10:50 |
Dyrcona |
JBoyer++ |
| 10:50 |
Dyrcona |
I usually use localhost on my test VMs. |
| 10:50 |
Dyrcona |
I used the FQDN of the local machine in production. |
| 10:51 |
Dyrcona |
So, think I'll switch to localhost. |
| 10:53 |
Dyrcona |
Fun thing: I have 3 config branches: 2.10, 2.11, and master, so that's a couple of git checkout; git cherry-pick to keep them all in sync. |
| 13:22 |
Dyrcona |
And, a search worked. This is promising. :) |
| 13:22 |
|
mllewellyn joined #evergreen |
| 13:29 |
Dyrcona |
All right, I don't know why logger complained like that. |
| 13:30 |
Dyrcona |
Maybe I need the full path? I'll try that after I test a z39.50 search. |
| 13:34 |
|
pgardella joined #evergreen |
| 13:35 |
Dyrcona |
Well, I guess the little machine is struggling. It timed out after 30 seconds. |
| 13:39 |
Dyrcona |
This doesn't look right: "searches":{"author":{"term":"coelho"},"keyword":{"term":"eg."}}, Looks like part of the index name ends up as a search tem. |
| 13:39 |
Dyrcona |
s/tem/term/ |
| 13:41 |
Dyrcona |
That comes from this Z search: find @attr 1=1003 coelho |
| 13:41 |
pgardella |
Good afternoon, everyone! I'm trying to restore a backup of the evergreen database onto another server for testing, and have run into some errors I've not hit before. Namely, functions not existing: |
| 13:41 |
pastebot |
"pgardella" at 64.57.241.14 pasted "missing functions" (8 lines) at http://paste.evergreen-ils.org/45 |
| 13:42 |
pgardella |
this was with a -Fc backup of our live DB |
| 13:43 |
pgardella |
Anyone seen this before? |
| 14:27 |
JBoyer |
I get the same message pgardella was talking about when it tries to restore the indexes. Since the func isn't found the indexes don't exist when the restore complets. |
| 14:27 |
Dyrcona |
Is the unaccent extension in the db create script? I think so, but it might have been missed. |
| 14:28 |
JBoyer |
I've been using a complete dump restore (with -C) for ages, that's breaking. The only time I've ever bothered with pre-creating the db is when I want to restore with a different name. |
| 14:31 |
pgardella |
Latest tests done: With using the examples restores that dyrcona and charp gave me, I get the missing uaccent error and the missing functions. Using the pre-create the DB, I just get those missing functions. (I'm on 2.10.5, by the way.) |
| 14:31 |
Dyrcona |
What Pg version? |
| 14:32 |
pgardella |
I'm going to 9.3 right now, from a 9.1 db |
| 14:32 |
Dyrcona |
OK. My restores are going to 9.5 from 9.2. |
| 15:43 |
Dyrcona |
And, it does appear to affect search results. |
| 15:44 |
JBoyer |
If it didn't that'd practically be a yes to "Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" |
| 15:45 |
dbs |
Flash-- |
| 15:46 |
csharp |
dbs: srsly - apparently Google is kinda testing a flash-free version of play music, but it's not consistently/widely available |
| 15:47 |
csharp |
https://bugzilla.redhat.com/show_bug.cgi?id=1405287 - and then I'll shut up :-) |
| 15:47 |
dbs |
csharp: I think you have to go Chrome if you're doing anything with Flash these days (and yeah I hatesessss the long-standing Flash dependency Google Music has) |
| 15:48 |
dbs |
At least Evergreen doesn't have a Flash dependency. |
| 15:48 |
csharp |
the key word is "YET" |
| 16:41 |
Dyrcona |
I love how some parts of the system are using localtime and others are using UTC. |
| 16:41 |
Dyrcona |
I'm going to add some more info on a bug comment. |
| 16:59 |
Dyrcona |
So, some more digging and it looks like specifying a version=1.2 to SRU is the real issue. |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan1 left #evergreen |
| 17:11 |
Dyrcona |
Well, that's it for today. |
| 17:30 |
|
mllewellyn left #evergreen |
| 17:34 |
|
jvwoolf left #evergreen |
| 18:05 |
csharp |
berick: early testing of your last fixes shows this error: ERROR: cannot pass more than 100 arguments to a function# |
| 18:06 |
csharp |
I can get the full output to you shortly |
| 18:11 |
csharp |
berick: http://pastebin.com/brVt8xrj |
| 18:12 |
berick |
doh! |
| 18:12 |
berick |
ok |
| 18:12 |
berick |
i can fix that, just use an array. |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:15 |
|
NawJo joined #evergreen |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
book` joined #evergreen |
| 07:35 |
bshum |
We'll be putting comments on there and adding links to stuff |
| 07:35 |
NawJo |
Yes! |
| 07:36 |
|
JBoyer joined #evergreen |
| 07:39 |
bshum |
NawJo: Okay, emailed you a reply with some instructions about the DCO. |
| 07:39 |
bshum |
I'll play with the git changes later today, but look forward to testing everything out |
| 07:40 |
NawJo |
thank you a lot! I just received the mail :) |
| 07:41 |
bshum |
NawJo++ |
| 08:29 |
NawJo |
@bshum I've just emailed git admins. requesting the permission to commit to the Evergreen repository :) |
| 13:55 |
Dyrcona |
Rather, git rebase says no changes.... |
| 13:55 |
Dyrcona |
Anyway, git rebase --skip fixes it if you ever run into that. |
| 14:15 |
jeffdavis |
bug 1662297 |
| 14:15 |
pinesol_green |
Launchpad bug 1662297 in Evergreen "Install directory hardcoded in web client build and tests" [Undecided,New] https://launchpad.net/bugs/1662297 |
| 14:17 |
jeffdavis |
^ not sure how critical this is, but it looks like web client won't build out of the box unless you have installed in /openils ? |
| 14:18 |
jeffdavis |
It built for me with "Done, without errors." at the end, but there were warnings related to the above issue and the web client doesn't actually work |
| 14:23 |
gmcharlt |
kmlussier: because of the reingest, I'm not inclined to backport it |
| 16:20 |
|
jvwoolf joined #evergreen |
| 16:36 |
|
mmorgan joined #evergreen |
| 16:44 |
|
rlefaive joined #evergreen |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 18:27 |
|
abneiman_ joined #evergreen |
| 18:46 |
|
ejk joined #evergreen |
| 19:08 |
|
ats-jc joined #evergreen |
| 19:45 |
|
rlefaive joined #evergreen |
| 20:52 |
|
jvwoolf joined #evergreen |
| 22:45 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1537217 Precat Checkout Circ Modifier - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=79fafc2> |
| 01:54 |
|
ATS-JC joined #evergreen |
| 02:04 |
|
gsams_ joined #evergreen |
| 04:09 |
|
abowling joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:29 |
|
rjackson_isl joined #evergreen |
| 07:33 |
|
agoben joined #evergreen |
| 07:53 |
|
kmlussier joined #evergreen |
| 09:46 |
csharp |
kmlussier: I just removed myself - thanks for the poke |
| 09:47 |
kmlussier |
csharp: OK, I think I'm going to apply a 2.12 milestone to that one. See if we can get it in for the upcoming release. |
| 09:47 |
* csharp |
would love to see that feature implemented (though Canceled Transit may remove the urgency for it) |
| 09:49 |
* mmorgan |
would like to see that go in, too, and may try to carve out some time to test it. |
| 09:53 |
csharp |
mmorgan: I intentionally separated out the "Abort -> Cancel" changes into the second commit so they can be tested separately (since they're really not the same issue), just adding context for testing (if you get around tuit) |
| 09:55 |
|
dteston joined #evergreen |
| 09:57 |
mmorgan |
csharp: Gotcha. We love the new status, but would also like to be able to identify the source and destination of the canceled transits when necessary. |
| 10:09 |
* berick |
adds a note to 1347774 |
| 10:16 |
|
ATS-JC joined #evergreen |
| 10:20 |
bshum |
As a general musing... if we were trying to take action on https://bugs.launchpad.net/evergreen/+bug/697926 to change the locale name for ar-AR to ar-JO.... |
| 10:20 |
pinesol_green |
Launchpad bug 697926 in Evergreen "change ar-AR to ar-JO for more accurate locale" [Low,Confirmed] - Assigned to Ben Shum (bshum) |
| 10:20 |
bshum |
I was thinking that we should just be able to rename all the directory and files in git and then sync it back. |
| 10:20 |
bshum |
I don't think there's any way to really test it though, given the limitations of how things sync with Launchpad translations. |
| 10:20 |
bshum |
Anyone object if we just proceed and do cleanup if it goes wrongly? :) |
| 10:21 |
bshum |
(I was thinking to ask the translators to pause their work before the sync so that we make sure to capture all the new strings prior to moving things around) |
| 10:24 |
kmlussier |
bshum: Would all translators need to pause their work or just the person working on the arabic files? |
| 10:25 |
bshum |
kmlussier: I want to say only arabic since that's the one we want to move |
| 10:26 |
bshum |
But this is new to me so I'm not sure :) |
| 14:19 |
berick |
the user no longer has to accept the permissions at run time |
| 14:19 |
* jeff |
defers to berick again |
| 14:19 |
berick |
it happens when the app is installed |
| 14:19 |
kmlussier |
berick: Oh, good. I'll carry on with testing then. |
| 14:19 |
jeff |
i don't like that Hatch gets such permissions, but that might be for another time. |
| 14:19 |
berick |
note to self: fix docs |
| 14:20 |
berick |
jeff: agreed, but at this point, if it works for someone besides me, i'm throwing a party |
| 14:20 |
Dyrcona |
jeff: Everything wants the keys to the kingdom these days. |
| 14:20 |
berick |
kmlussier: consider me on call for your testing :) |
| 14:20 |
kmlussier |
Ooh! A party? |
| 14:20 |
berick |
well, it is friday |
| 14:21 |
berick |
@bartender hatch-testers |
| 14:21 |
* pinesol_green |
fills a pint glass with Magic Hat Hocus Pocus, and sends it sliding down the bar to hatch-testers (http://beeradvocate.com/beer/profile/96/292) |
| 14:35 |
kmlussier |
Not sure I should be testing anything after drinking something called Hocus Pocus. |
| 14:36 |
JBoyer |
*Biipity-Boppity-Broken!* |
| 14:46 |
Dyrcona |
:) |
| 14:52 |
sandbergja |
The DIG meeting will start in about 8 minutes |
| 15:16 |
kmlussier |
But I can give anyone access who needs it too. |
| 15:16 |
kmlussier |
We aren't stingy with WP credentials. :) |
| 15:16 |
rhamby |
yep, both are accurate as well as kmlussier |
| 15:16 |
Christineb |
it is also possible for me to add collaborators on the list so others can add videos - testing required |
| 15:16 |
kmlussier |
Sorry, meant to say I can give access *to anyone* who needs it. |
| 15:17 |
Christineb |
if anyone is interested in being a collaborator let me know and I will email you the invite so we can test it out |
| 15:17 |
remingtron |
rhamby: kmlussier: thanks for confirming |
| 15:17 |
sandbergja |
Anyone up for getting WP credentials and/or adding this link? |
| 15:18 |
Christineb |
I can add it |
| 16:30 |
|
kmlussier joined #evergreen |
| 16:31 |
berick |
windows doesn't like you either |
| 16:31 |
kmlussier |
berick: Sorry, that disconnect was not a response to your question. |
| 16:31 |
berick |
kmlussier: ok, try this please: open a console, then cd C:\\Program Files (x86)\Hatch |
| 16:31 |
berick |
you may have use quotes on the directory names, tab-complete should help |
| 16:32 |
berick |
once your there do: hatch.bat test |
| 16:34 |
berick |
well, probably it's just C:\Program... |
| 16:34 |
berick |
not c:\\ |
| 16:36 |
* berick |
launches a windows vm |
| 16:37 |
kmlussier |
berick: Sorry, distractions. Unfortunately, I'm going to have to look at this Monday morning. |
| 16:37 |
berick |
kmlussier: ok, no worries, I'll be around |
| 16:37 |
kmlussier |
berick: Thanks! And have a nice weekend! |
| 16:37 |
berick |
kmlussier++ |
| 16:38 |
berick |
you too |
| 16:38 |
berick |
csharp: any more hold targeter issues? |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:04 |
jeff |
open-ils.cstore 2017-02-03 16:35:23 [ERR :11276:oils_sql.c:2522:] open-ils.cstore ERROR inserting config::copy_status object using query [INSERT INTO config.copy_status (holdable,id,name,opac_visible,copy_active,restrict_copy_delete,is_available) VALUES (DEFAULT,1,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT);]: 0 ERROR: null value in column "name" violates not-null constraint |
| 17:05 |
* jeff |
compares last success to see which of the 12 are the 3 expected errors. |
| 17:06 |
jeff |
ah, yup. ignore my paste. that's expected. |
| 01:14 |
|
abneiman joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 08:01 |
|
collum joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 10:53 |
jeff |
i think people also have stronger opinions on the per-hold booleans vs the per-hold notification targets. in our environment, we've done away with both. |
| 10:54 |
jeff |
your notification settings at the time that the hold goes available are how you are notified for that hold. |
| 10:54 |
jeff |
(with one or two theoretical corner cases that i've on my list to hunt down) |
| 10:55 |
* berick |
tests the tpac, sees that it forces patrons to use the email on the account and provides no way to change the email value |
| 10:56 |
berick |
that kind of renders the whole feature useless, doesn' it? |
| 10:56 |
jeff |
berick: because there is no per-hold email string, just a bool for yes/no. |
| 10:56 |
jeff |
but unlike email, there are per-hold phone_notify and sms_notify (and sms_carrier) settings. |
| 10:57 |
jeff |
which function as both bool and target, iirc. |
| 12:26 |
|
jvwoolf joined #evergreen |
| 12:32 |
|
bmills joined #evergreen |
| 12:38 |
|
mmorgan joined #evergreen |
| 12:46 |
* mmorgan |
catches up |
| 12:52 |
mmorgan |
jeffdavis: Hard to say if the fix for 1086458 made the problem go away entirely. Many variables changed - OSs, workstation hardware, etc. Have not done another concise test since, but my current unscientific impression is that there are still some 'memory leak' issues related to patron searches. |
| 12:54 |
jeffdavis |
mmorgan: understood, thank you |
| 12:59 |
miker |
csharp: re the desire for "stacked" validators and such from the other day, the module loading logic is built such that if you can toss a perl module anywhere that perl can find it for "use", you can create your own validators (and reactors, etc). So if you created a module called, say, PINES::AT::Validators and in there you had subs (like "sub sms_validate {...}' that pulled in and used stock validators in the order you wanted, and did other |
| 12:59 |
miker |
validations as well, you could configure A/T to use them. Just add a validator module (via staff client config) for, say, PINES::AT::Validators::sms_validate and make use of it |
| 13:37 |
miker |
ah, ok ... NOTHING TO SEE HERE! |
| 13:37 |
JBoyer |
:) |
| 13:40 |
miker |
csharp: huh... well, ws should be the id of the workstation, obv, not a string ... recent changes to the staff client? or missing/local changes to the idl? |
| 13:40 |
JBoyer |
csharp, I suppose it's too much to hope that you're testing some toolbar changes on that install? |
| 13:41 |
csharp |
I rebuilt the staff client just in case it was my older local one |
| 13:41 |
csharp |
if someone can easily confirm that it's happening or not, that would help :-) |
| 13:41 |
csharp |
JBoyer: nope :-/ |
| 16:50 |
berick |
in circ, self->retarget is a list |
| 16:50 |
* berick |
patches |
| 16:57 |
|
khuckins_ joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
berick |
csharp: _bott_: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=320cc9fe56d38c79da2da064a68fec746ae3385e |
| 17:06 |
berick |
pushed to same branch |
| 17:07 |
|
mmorgan left #evergreen |
| 00:28 |
|
dcook joined #evergreen |
| 00:33 |
|
dcook__ joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:46 |
|
genpaku joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:17 |
|
dteston joined #evergreen |
| 11:24 |
pinesol_green |
csharp: Thank you csharp! But our princess is in another castle! |
| 11:24 |
csharp |
@bartender berick |
| 11:24 |
* pinesol_green |
fills a pint glass with Samuel Adams Black Lager, and sends it sliding down the bar to berick (http://beeradvocate.com/beer/profile/35/21300) |
| 11:25 |
berick |
csharp: but did you test it yet? :) |
| 11:25 |
csharp |
doing so now |
| 11:25 |
csharp |
:-) |
| 11:25 |
Dyrcona |
I don't think you have to test that. It will fix the problem. ;) |
| 11:26 |
Dyrcona |
I was ready to commit it after just eyeballing it. :) |
| 11:27 |
* Dyrcona |
wonders what's for lunch. |
| 11:30 |
csharp |
no errors - now going to wait a little while for more events to accumulate and run a bigger batch at once |
| 12:32 |
miker |
csharp: is there an LP bug to attach this to? |
| 12:33 |
miker |
nm, found it |
| 14:55 |
|
mmorgan1 joined #evergreen |
| 15:38 |
csharp |
miker: oops - I left out the "next;" in my git branch - it was added to my local file :-/ |
| 15:41 |
csharp |
miker: I'll test your branch in a bit and let you know how it goes |
| 15:45 |
|
agoben joined #evergreen |
| 15:55 |
|
khuckins_ joined #evergreen |
| 15:59 |
csharp |
miker: so putting aside the functionality of the patch(es), you're saying that it's "wrong" to group on a field that is nullable (in this case, sms_notify on action.hold_request)? I see that all other notices group on usr, but I'm assuming we group on sms_notify since that's a per-hold setting... |
| 16:00 |
csharp |
that is to say, if there's a better way to do this in the first place, I'm game :-) |
| 16:01 |
jeff |
can you articulate why you were grouping by sms_notify and not usr? how do the stock phone / pbx A/T event defs group? |
| 16:02 |
berick |
i'm fairly certain it is because sms_notify is per-hold and not per-user |
| 16:02 |
berick |
(a topic I know jeff loves) |
| 16:38 |
stephengwills |
in my case it appears as if the xact_finish date == the date the item was checked in. the bills are all unpaid. not even partial payments on them |
| 16:51 |
|
mmorgan joined #evergreen |
| 16:56 |
|
khuckins__ joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
mmorgan left #evergreen |
| 17:15 |
jeffdavis |
Are folks around these parts experiencing memory leak issues with the staff client? |
| 17:17 |
jeffdavis |
there are some reports of this kind of thing in bug 1110817 (and in bug 1086458 which was "fixed" circa 2.5) but I'm not sure of prevalence of that kind of issue |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
JBoyer joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 12:27 |
|
jihpringle joined #evergreen |
| 12:33 |
miker |
_bott_: I just marked your bug as private and security related ... as it happens, it's a duplicate of one I entered last week that has patches already :) |
| 12:33 |
_bott_ |
patches would be very welcomed! |
| 12:35 |
miker |
I've attached you to the other bug. I'm going to mark yours as dup and put patches (instead of branch names in a repo you can't get to...) there so you can test 'em |
| 12:36 |
|
genpaku joined #evergreen |
| 12:37 |
|
jihpringle joined #evergreen |
| 12:41 |
|
jvwoolf joined #evergreen |
| 14:17 |
dteston |
berick: So existing salts are pulled from actor.passwd, but new salts are created from that function once per user? |
| 14:21 |
berick |
dteston: existing MD5 hashed passwords [ just MD5('password123') ] are pulled from actor.passwd. all passwords, migrated and new, get new salts from actor.create_salt() |
| 14:22 |
berick |
dteston: see also actor.migrate_passwd() db func |
| 14:22 |
_bott_ |
miker: patches in and brief testing yields positive results |
| 14:27 |
dteston |
berick: post-migration though, the only salt that's used to authenticate my password will be on actor.passwd, right? |
| 14:28 |
berick |
dteston: yes |
| 14:29 |
berick |
it's the only salt, but passwords going forward also do the 2 rounds of md5 hashing |
| 15:25 |
|
gsams joined #evergreen |
| 15:27 |
|
dteston joined #evergreen |
| 16:04 |
|
mmorgan joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:10 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:23 |
Stompro |
mmorgan++ Thanks for the response to my list question! |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:20 |
|
kmlussier joined #evergreen |
| 06:20 |
* kmlussier |
yawns |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 10:01 |
_adb |
yea.. hold is captured, but before 'hold shelf delay status' time has passed |
| 10:02 |
tsbere |
aka, it is in the "on hold shelf" status with a shelf time, but within that delay period? |
| 10:03 |
jeff |
_adb: i thought that that was a known and fixed issue a while back. maybe there's still an open bug and it's not been merged. looking. |
| 10:03 |
_adb |
i think so? the hold shows up in the staff client as "reserved/pending", but i'm not sure what the item status is during this time. i'd have to test. |
| 10:04 |
|
remingtron joined #evergreen |
| 10:04 |
jeff |
bug 1195428 |
| 10:04 |
pinesol_green |
Launchpad bug 1195428 in Evergreen "TPAC reports hold "ready for pickup" before hold_shelf_status_delay expires" [Medium,Confirmed] https://launchpad.net/bugs/1195428 |
| 10:09 |
berick |
jeff: bonus, it's not prompting for any permissions. it almost seems too good to be true, though. |
| 10:10 |
jeff |
that does seem a bit too good to be true... hrm. |
| 10:10 |
_adb |
how long is the timeout before notifications sent and hold is marked as ready for pickup if it's captured as transit? |
| 10:10 |
jeff |
berick: have you tested with a fresh copy of chrome and potentially a fresh google account to confirm that there's nothing going on like "oh, you granted some permissions to this a while ago"? |
| 10:11 |
tsbere |
_adb: You still need to check it in again to end the transit, so "until staff take action, plus whatever is configured then" |
| 10:11 |
jeff |
_adb: depends on a few variables, including how often you run the action trigger script with the granularity in question, and the delay configured in the A/T definition... |
| 10:11 |
_adb |
ah, ok, thank you |
| 10:14 |
|
Dyrcona joined #evergreen |
| 10:15 |
|
bos20k joined #evergreen |
| 10:15 |
|
jvwoolf joined #evergreen |
| 10:16 |
berick |
jeff: i'm going to clean up my test code, get it into the working repo, then try it on a few other machines today. i'll update the bug. other eyes would be awesome, though |
| 10:16 |
berick |
jeff: for now, the fact that you didn't say "that's insane" is what I was looking for ;) |
| 10:17 |
jeff |
it got a raised eyebrow and a "that doesn't sound like it should work", but I'm not planning to make any further assertions without testing. :-) |
| 10:25 |
|
mmorgan1 joined #evergreen |
| 10:32 |
|
Christineb joined #evergreen |
| 10:39 |
|
Callender joined #evergreen |
| 10:51 |
|
mdriscoll joined #evergreen |
| 10:54 |
berick |
jeff: oh, i missed your earlier comment.. when viewing the details of the extension, it does say "Read and change all your data on the websites you visit" -- however, it already said that. |
| 10:55 |
berick |
first test passed, installing under a different "person" in chrome. trying on a different machine now.. |
| 11:07 |
|
sandbergja joined #evergreen |
| 11:08 |
|
dbwells joined #evergreen |
| 11:14 |
|
khuckins joined #evergreen |
| 11:17 |
|
remingtron joined #evergreen |
| 11:17 |
berick |
jeff: fyi, installed on another machine (mac) where i've never installed it before, on a different chrome "person" (not logged into google) and all is well. this is after trimming the manifest even more. http://git.evergreen-ils.org/?p=working/Hatch.git;a=blob;f=extension/app/manifest.json;hb=collab/berick/lp1646166-native-messaging-2.12-omnibus |
| 11:17 |
* berick |
updates lp |
| 11:19 |
jeff |
berick: does the extension still show "Read and change all your data on the websites you visit"? |
| 11:19 |
jeff |
and it didn't display that permission as being granted when the extension was installed? |
| 11:20 |
berick |
jeff: it does display that message when viewing the extension details. it doesn't inform me of that during install, presumably because I'm installing in developer mode. |
| 11:59 |
|
brahmina joined #evergreen |
| 12:01 |
|
bmills1 joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:18 |
kmlussier |
berick++ jeff++ # Continued hatch work and testing. |
| 12:19 |
jeff |
i'm just listening today. :-) |
| 12:20 |
JBoyer |
berick++ |
| 12:21 |
JBoyer |
It sounds like hatch is coming along nicely. I've finally got a notebook running Linux so I'll be able to take part in more testing and so on. (Not putting Java on any machines I actually like, so it's been a no-go at home until now, and work doesn't like it either. :/ ) |
| 12:22 |
jeff |
berick++ indeed |
| 12:32 |
Bmagic |
Is there a way to ask SIP weather a patron can circulate without trying to circulate an item? |
| 12:33 |
Bmagic |
It looks like we are getting 'Y' in the 3rd position on the 64 responses. AKA "64 Y " - which means block right? The problem is, that 'Y' seems to shows up no matter what penalties or no penalties |
| 12:41 |
JBoyer |
I can't tell that it's actually looking at penalties that block CIRC, only that there are some penalties. barring the patron (the checkbox on the Edit screen) or letting them expire are the only sure-fire ways to set that to Y |
| 12:42 |
Bmagic |
thanks for the help, I will keep digging |
| 12:42 |
Bmagic |
$u->standing_penalties and @{$u->standing_penalties} |
| 12:43 |
Bmagic |
If the result of that test is true, then circ is blocked, which results in the first position 'Y' ? |
| 12:44 |
jeff |
might want to start with "why do you think the patron should be blocked?" |
| 12:44 |
JBoyer |
Yes, but I can't tell what that's actually testing. first, that there are standing penalties, but I'm not sure what @{$u->standing_penalties} is actually testing. |
| 12:44 |
Bmagic |
if the penalty they have blocks CIRC |
| 12:45 |
Bmagic |
if you look at the code for renew_ok - $renew_block_penalty = 't' if $_->standing_penalty->block_list =~ /RENEW/; |
| 12:45 |
Bmagic |
probably need something similar in charge_ok ? |
| 12:50 |
Dyrcona |
That check is check that we have something, and that they arrayref has 1 or more memberes. |
| 12:50 |
Dyrcona |
@{[]} is 0 or false in scalar context |
| 12:50 |
pinesol_green |
Dyrcona: Error: "" is not a valid command. |
| 12:52 |
Bmagic |
the test is then "penalties exist and there are more than 0" ? |
| 12:55 |
Dyrcona |
Bmagic: Yeah. |
| 12:55 |
Bmagic |
I'm thinking there needs to be a penalty block check for charge_ok and hold_ok just like renew_ok, do you think? |
| 12:55 |
Dyrcona |
It's done that way to avoid warnings about undefined values. |
| 13:23 |
Bmagic |
I suppose I will create a new bug unless you can think of one that is already there ( I really don't want to make a duplicate) |
| 13:25 |
jeff |
either start with a "this might be the same thing" as a comment on that bug, or a new ticket with "this might be a duplicate" and either a new bug can be created or the new bug can be marked as a duplicate if so. |
| 13:25 |
Bmagic |
I would like to mention that our system is not setting that first position 'Y' when they have penalties. Therefore, I can conclude that "$u->standing_penalties and @{$u->standing_penalties}" doesn't seem to be returning correctly |
| 13:25 |
jeff |
i would err on the side of getting a clear explanation of what you found and how you think it should be different into launchpad over worrying about comment vs new bug too much. :-) |
| 13:26 |
jeff |
(i say this because i've let that prevent me from getting info into launchpad before) |
| 13:27 |
jeff |
also helpful is some background on what the actual practical effect of the current behavior is, as not everyone has the same SIP clients to test with, or uses SIP in the same way. |
| 13:36 |
Dyrcona |
In my experience, a number of SIP vendors treat a Y in any field as blocked for everything. |
| 13:36 |
Dyrcona |
It's rare to find one that actually checks the specific field. |
| 13:38 |
Dyrcona |
As for Bmagic's comment about it returning correctly, I'd have to look at the code in question, but when dealing with arraryrefs, that's a common way to check if it has members. |
| 16:23 |
|
rlefaive joined #evergreen |
| 16:52 |
|
khuckins_ joined #evergreen |
| 17:00 |
|
jvwoolf left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:12 |
pinesol_green |
[evergreen|Bill Erickson] LP#1655399 webstaff: User perm editor grantable fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a2e9d7a> |
| 17:30 |
|
khuckins__ joined #evergreen |
| 17:44 |
|
kmlussier joined #evergreen |
| 17:45 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1621947: webstaff address alert functionality - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5a3e0dd> |
| 17:59 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1657466 - Edit Due Date Doesn't Submit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=117d164> |
| 18:03 |
* kmlussier |
just set 2.11.2 and 2.10.9 as milestones and then thought, wait, didn't we just release those? |
| 18:26 |
* kmlussier |
would love to see checkboxes on this page - https://launchpad.net/evergreen/2.11/2.11.2 - with an actions menu to perform batch updates on the bugs. |
| 19:05 |
|
rlefaive joined #evergreen |
| 14:46 |
berick |
lot of people out there using PG 9.5? |
| 14:48 |
Dyrcona |
berick: Considering upgrading to 9.5 from 9.2 next month. |
| 14:49 |
berick |
Dyrcona: good to know. trying to figure out where to upgrade to.. also on 9.2 here. |
| 14:49 |
csharp |
berick: I'm planning to start testing in PINES for 2.12/Labor Day upgrade |
| 14:49 |
berick |
csharp: *nod* |
| 14:49 |
Dyrcona |
berick: I believe NOBLE just upgraded to 9.4. |
| 14:49 |
csharp |
I'm using 9.5 on a standalone EG server for the governor's mansion and I haven't seen problems, but it's a tiny dataset |
| 14:49 |
csharp |
and no transaction load |
| 14:50 |
csharp |
9.4 rox |
| 14:50 |
berick |
i have it on my test vm's. been fine, but yeah, no load |
| 14:51 |
Bmagic |
berick: we are on 9.5 atop 16.04 |
| 14:52 |
berick |
Bmagic: cool, no issues? |
| 14:52 |
csharp |
just pay attention to the posix/THP issue that I hit last year: http://libmail.georgialibraries.org/pipermail/open-ils-general/2016-February/012736.html (plus miker's caveats in that thread) |
| 14:52 |
csharp |
heh |
| 14:53 |
Bmagic |
transparent huge pages are turned off for us as well |
| 14:54 |
Bmagic |
otherwise, we haven't done any of the other things mentioned on that thread from csharp |
| 14:54 |
miker |
basic testing of 9.6 shows it should work fine, too, fwiw. parallel seq scans! tsearch phrases! faster on big boxen! |
| 14:55 |
Bmagic |
parallel seq scans sounds nice! |
| 14:58 |
csharp |
JBoyer: miker: http://pastebin.com/qfL43KAS |
| 14:58 |
* csharp |
transits himself from office to home - will check back from there |
| 14:59 |
kmlussier |
miker or others: Is bug 1485374 something that can be merged rather soonish? It has a signoff from Dyrcona, but when I asked about it at the hack-a-way, my recollection was that it wasn't ready to go in yet. |
| 14:59 |
pinesol_green |
Launchpad bug 1485374 in Evergreen "Use client TZ in the database when supplied to the server" [Wishlist,Confirmed] https://launchpad.net/bugs/1485374 |
| 15:05 |
|
mmorgan1 joined #evergreen |
| 15:06 |
miker |
kmlussier: it looks good to me, and will cause testing :) |
| 15:07 |
miker |
merging will cause testing, I mean |
| 15:07 |
JBoyer |
This isn't necessarily a discussion I'm eager to have now, but has there ever been any discussion of only ever storing UTC in the db and only applying a TZ on the client? |
| 15:14 |
|
maryj joined #evergreen |
| 15:22 |
* csharp |
returns |
| 15:41 |
Dyrcona |
Well, looks like we don't have wunder any more. |
| 16:18 |
|
JBoyer joined #evergreen |
| 16:55 |
|
mmorgan joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan left #evergreen |
| 21:11 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: authority_control_field script --days-back feature - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3b36b46> |
| 23:56 |
|
abowling1 joined #evergreen |
