| 02:16 |
|
eady joined #evergreen |
| 05:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:03 |
|
gsams joined #evergreen |
| 07:42 |
|
ericar joined #evergreen |
| 07:47 |
|
graced joined #evergreen |
| 07:58 |
|
mrpeters joined #evergreen |
| 08:11 |
|
Dyrcona joined #evergreen |
| 08:21 |
jeff |
hah. thought i was seeing something Really Odd. |
| 08:22 |
jeff |
enabled SIP msg64_hold_datatype = barcode, did some testing with (a possibly hacked up copy of) tsbere's PHP SIP2 client. requested Hold and UnavailableHolds summary types in a patron information message. |
| 08:23 |
jeff |
the only item barcodes i was seeing in the response were not items i had holds on... but they were items that i would not be able to renew because someone ELSE had a hold on them. |
| 08:23 |
jeff |
This seemed like a Really Odd failure method until I realized that something was amiss and that the details I was getting were overdue items (which just so happened to be overdue because they had not been able to be renewed, etc) |
| 08:24 |
jeff |
Anyway, all better. |
| 08:24 |
jeff |
And if I didn't break it in the first place, I'll pass on a patch to tsbere. :-) |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:41 |
|
mrpeters joined #evergreen |
| 08:49 |
|
akilsdonk joined #evergreen |
| 12:37 |
jeff |
Yup. |
| 12:37 |
jeff |
bug 1013263 |
| 12:37 |
pinesol_green |
Launchpad bug 1013263 in Evergreen "Support SIP payment type 02 - "credit card"" (affected: 1, heat: 6) [Wishlist,Fix released] https://launchpad.net/bugs/1013263 |
| 12:39 |
jeff |
i wrote, you tested and signed off, lebbeous committed since neither you nor i could push to master at that point in time. :-) |
| 12:39 |
jeff |
I seem to recall it was only a few lines of code. |
| 12:57 |
Dyrcona |
Oh, three years ago... No wonder I don't remember. :) |
| 13:00 |
kmlussier |
Funny...I tend to recall bugs from 3 years ago better than I remember ones from a month ago. |
| 13:04 |
jboyer-isl |
So, about pgTAP tests; are we assuming the use of pg_prove, or should test scripts include all of the \pset and \set boilerplate? Only pg_prove is referenced in the documentation but most of our tests have all of the boilerplate, so... |
| 13:05 |
jboyer-isl |
I'd like to dump the lines we don't need, unless there was a decision that we do need them. |
| 13:06 |
|
Christineb joined #evergreen |
| 13:10 |
RoganH |
I need to invent a SIP wheel of doom so I can spin it each day and see what I think SIP will do today. |
| 13:15 |
jboyer-isl |
RoganH: My favorite experience was when a PC time management company wrote their own SIP communication library that would recognize field codes ANYWHERE. Made capitalized addresses much more "exciting" because it would also crash when it didn't understand what it was getting. |
| 13:19 |
|
gsams joined #evergreen |
| 13:20 |
tsbere |
They insisted that I couldn't use a repeating field for what I was using it for because the standard didn't *do* that. Then I pointed them at several in the standards doc they were using... |
| 13:23 |
jboyer-isl |
Although, come to think of it my toy code didn't take that into account properly either. At least I wasn't trying to charge anyone to use it. |
| 13:24 |
jeff |
so: tips of the day... a basic AAA membership card behaves enough like a Visa card for smoke testing credit card payments at a self-pay kiosk |
| 13:24 |
miker |
jeff: nice |
| 13:24 |
jeff |
and tip 2: if you have someone remoting into a kiosk to work on it and you want the kiosk obviously out of service with screen obscured, grab your nearest clean library T-shirt |
| 13:25 |
jboyer-isl |
jeff++ # lifehacks |
| 09:17 |
pinesol_green |
Launchpad bug 1479107 in Evergreen "Replace manual void option with an "adjust to zero" option" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479107 |
| 09:19 |
kmlussier |
For bug 1479110, I would be curious to know if others agree with our assessment of how the settings should interact with each other. |
| 09:19 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 09:24 |
dbwells |
kmlussier: If we model it straight after the void interface code, it should be pretty simple. I don't think it is worth delaying the alpha for, though. I think the alpha is a litmus test to see if we're way off track, which means undone stuff is a given. |
| 09:25 |
dbwells |
kmlussier: I could add with a high degree of confidence that it should take less time than the original bug. |
| 09:25 |
* dbwells |
ducks |
| 09:33 |
jeff |
and... now you've jinxed it. |
| 09:35 |
|
yboston joined #evergreen |
| 09:58 |
kmlussier |
I'm inclined to agree with Dyrcona on the alpha delay if it's something that can be done in a reasonable amount of time, just because it would be nice to have it in as good shape as possible for the litmus test. |
| 09:59 |
kmlussier |
But, as bshum said, Dyrcona is our fearless leader. |
| 10:01 |
kmlussier |
Of course, part of me is also thinking of all the documentation I have to write and wanting to get started on it as soon as possible. |
| 10:02 |
Dyrcona |
Well, you could get started on the documentation. |
| 10:03 |
Dyrcona |
I find it is sometimes better to write the documentation first, and then write the code so it works according to the documentation. ;) |
| 10:03 |
kmlussier |
Actually, that was an idea raised at the Google doc sprint. Maybe I should start doing it for all of MassLNC's development projects. :) |
| 10:31 |
jeff |
mrpeters: check the value of ingest.reingest.force_on_same_marc in config.internal_flag? |
| 10:32 |
jeff |
mrpeters: still, 12 hours is a bit much to reingest 6k bres unless you're on really underpowered hardware. |
| 10:32 |
jboyer-isl |
mrpeters: Even if they are reingested that sounds like an enormous amount of time. Are things otherwise ok with this installation? Otherwise, jeff is right, that flag being set should be the only reason for a reingest if you don't touch the marc field. |
| 10:33 |
mrpeters |
yeah, its a test server, but comparable hardware to production |
| 10:33 |
jboyer-isl |
Stock postgresql.conf or edited? |
| 10:33 |
jeff |
mrpeters: did you do the updates in individual transactions? if not, is there any other activity on the system? have you checked for locking issues? |
| 10:33 |
jeff |
mrpeters: what does postgres think is happening with that query, and any other queries? |
| 10:40 |
mrpeters |
i will need to reingest eventually, because i will also be changing the marc with REGEXP_REPLACE but i hadn't even gotten to that point in the process yet, but, now i see a lot of hung up crap in the db that may take care of things |
| 10:41 |
Dyrcona |
mrpeters: I'd suggest possibly doing whatever you're doing via Perl. I find it much easier to manipulate MARC in Perl than directly in the database. |
| 10:41 |
|
jboyer-isl joined #evergreen |
| 10:41 |
phasefx |
didn't see it in channel this morning (net-split?), but there's a new failure at http://testing.evergreen-ils.org/~live/ re: perl live tests for negative balances |
| 10:42 |
mrpeters |
gotta stick with what i know, for now, Dyrcona |
| 10:42 |
Dyrcona |
pfft. I'm always keen to learn new things. :) |
| 10:43 |
Dyrcona |
But, I get it if you don't think you have the time. |
| 10:45 |
mrpeters |
yeah, time is the issue...and it's just adding a 856$9 to existing records, and regex_replace has never failed me in the past |
| 10:45 |
jeff |
Dyrcona: with ingest.reingest.force_on_same_marc set to true, UPDATE biblio.record_entry SET id = id WHERE id = 1; will cause a reingest of bre id 1. |
| 10:45 |
dbwells |
phasefx: thanks. Looks like two problems. One, do_checkin_override didn't make it into TestUtils, so it was probably missing from the branch. Two, we need to decide how to handle the pre-test SQL. I'll push something in for #1, but am not sure about #2. |
| 10:46 |
mrpeters |
turning off that flag will be key, i think -- i can then build a script to reingest just the records that changed |
| 10:46 |
mrpeters |
system isnt in use, so no harm in having that flag off while i update the few bibs |
| 10:47 |
jboyer-isl |
mrpeters: that flag should be set to false already, you really don't want edits that don't touch the marc to cause a full reingest all the time. You don't have to do anything special to cause a reingest of records whose marc you're editing. |
| 10:48 |
mrpeters |
although, i think its better than the old production server |
| 10:49 |
mrpeters |
gonna give it a whirl on the new hardware |
| 10:49 |
Dyrcona |
jeff: I guess I imagined the trigger checked more than it does. :) |
| 10:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Add missing util function for tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=437550e> |
| 11:11 |
|
Dyrcona1 joined #evergreen |
| 11:15 |
Dyrcona |
wifi-- |
| 11:35 |
|
bmills joined #evergreen |
| 11:36 |
kmlussier |
So I don't know if we should wait to merge them. |
| 11:39 |
Dyrcona |
We probably should wait. |
| 11:45 |
|
Christineb joined #evergreen |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Move negative balance test xacts into sample data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a6c040> |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Load negative balance test transactions in load_all.sql - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b842239> |
| 11:55 |
|
bmills joined #evergreen |
| 11:56 |
dbwells |
tests should be happier now; we'll see! |
| 11:57 |
jeff |
dbwells++ |
| 11:58 |
kmlussier |
dbwells++ |
| 12:56 |
Dyrcona |
dbwells++ |
| 14:37 |
kmlussier |
:( |
| 14:53 |
|
vlewis_ joined #evergreen |
| 14:56 |
|
vlewis__ joined #evergreen |
| 15:09 |
mrpeters |
follow up from earlier Re: bib source updates -- ran fine once i cleared out some queries that had hung in this particular test server -- ran in a matter of a couple minutes like I would have expected. |
| 15:11 |
Dyrcona |
mrpeters++ |
| 15:15 |
mrpeters |
for the logs, in case anyone ever needs to add 856$9 tags to e-resource bib records, this works nicely |
| 15:15 |
mrpeters |
UPDATE biblio.record_entry SET marc = REGEXP_REPLACE(marc, $$(<datafield tag="856" ind1="." ind2=".">)(.*?)(</datafield>)$$, $$\1<subfield code="9">SHORTNAME</subfield>\2</datafield>$$, 'g') WHERE id=foo; |
| 16:36 |
* jeffdavis |
goes ahead and does both |
| 16:42 |
kmlussier |
Sorry, I was working on something else. The settings go changed sometime around when comment 28 was added to the bug (see 3a). https://bugs.launchpad.net/evergreen/+bug/1198465/comments/28 |
| 16:42 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Fix committed] |
| 16:43 |
kmlussier |
But I also recall only setting the interval in my original testing. |
| 16:43 |
kmlussier |
I'm fine with whatever the community decides is more intuitive, but in discussions with the team here, there was general consensus that most people would think that, once people set prohibit to true, they would think it would be prohibited in all cases. |
| 16:45 |
kmlussier |
At the same time, in our environments, there are only a few individuals who would be allowed to touch those settings, so it's not as big of an issue as it would be if it were something most end users would be adjusting on a regular basis. |
| 16:56 |
|
vlewis joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
dbwells |
yay |
| 17:20 |
bshum |
dbwells++ |
| 17:21 |
|
vlewis_ joined #evergreen |
| 12:07 |
gsams |
jwoodard: Turns out it was nevery turned on afterall because I was afraid it would get used without everyone knowing about it |
| 12:09 |
gsams |
kmlussier: I read the new features docs everytime a release is done and I still miss/forget features exist |
| 12:12 |
kmlussier |
gsams: One of the reasons I like working on the release notes so much is because it keeps me aware of all the new things we're getting. :) |
| 12:13 |
jwoodard |
gsams I turned it on for our library to test it out upon learning that it existed. It is a neat feature that I plan on implementing. |
| 12:13 |
kmlussier |
phasefx: I have no opinion on bug 1478299. I'm fine with your solution if you want to merge it. |
| 12:13 |
pinesol_green |
Launchpad bug 1478299 in Evergreen "Fix hold permit test" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1478299 |
| 12:14 |
jwoodard |
Our library services a large area so a feature like this is very helpful. |
| 12:14 |
kmlussier |
phasefx: Or do you need a signoff for it? |
| 12:16 |
gsams |
jwoodard: I'm going to flip the switch for the whole group |
| 12:41 |
gsams |
jwoodard: I turned your link on for the registration |
| 12:58 |
jwoodard |
gsams: Thank you! I shot you an email about adding stuff to the page. |
| 12:59 |
bshum |
kmlussier: phasefx: I'm leaning towards his solution being generally more predictable too. I wasn't sure how the copy was chosen, since the IDs are generated somewhat randomly? |
| 13:02 |
kmlussier |
bshum: OK, well, like I said, I'm fine with it if somebody wants to merge it so that our tests can be happy again. |
| 13:14 |
|
akilsdonk_ joined #evergreen |
| 13:30 |
bshum |
~search_path |
| 13:30 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 14:34 |
bshum |
Where _bott_ solved the null card problem a different way by having that method skip over any deleted users. |
| 14:34 |
bshum |
I think we should incorporate both fixes for a complete solution. |
| 14:34 |
bshum |
I'll try and mix-match everything into one LP with a proper pullrequest branch in a few moments. |
| 14:38 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1478299: fix location for asset used in test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=001bb57> |
| 14:45 |
bshum |
_bott_++ |
| 15:04 |
|
ericar_ joined #evergreen |
| 15:08 |
|
jlitrell joined #evergreen |
| 16:26 |
jboyer-isl |
:Q |
| 16:27 |
|
mrpeters joined #evergreen |
| 16:27 |
bshum |
Calling 0921 |
| 16:34 |
pinesol_green |
Showing latest 5 of 18 commits to Evergreen... |
| 16:34 |
pinesol_green |
[evergreen|Remington Steed] LP 1198465: Initial tests for conditional negative balances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=336f8a6> |
| 16:34 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Make conditional negative balances test sql re-runnable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=14836cc> |
| 16:34 |
pinesol_green |
[evergreen|Remington Steed] LP 1198465: More tests for conditional negative balances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cde1573> |
| 16:35 |
pinesol_green |
[evergreen|Kathy Lussier] LP 1198465: Adapt some language in the negative balance branch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5ee86b> |
| 16:35 |
pinesol_green |
[evergreen|Ben Shum] LP#1198465: Stamping upgrade script for conditional negative balance - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ea55537> |
| 16:36 |
kmlussier |
I never thought I would see the day... |
| 16:36 |
mmorgan |
Woo-hoo!!! |
| 16:37 |
* dbwells |
feels a disturbance in the Force |
| 16:38 |
kmlussier |
Dyrcona: Well, I obviously am not going to give karma to myself! :) |
| 16:38 |
mmorgan |
dbwells: ...as if millions of negative balances suddently cried out in terror and were suddenly silenced. ;-) |
| 16:39 |
dbwells |
mmorgan: that's right :) |
| 16:40 |
kmlussier |
Also, mmorgan++ for doing a fair share of the testing. |
| 16:41 |
kmlussier |
Should I file a follow-up LP bug on the manual adjustments we discussed last week? |
| 16:42 |
dbwells |
remingtron++ # he deserves a little extra, those pesky tests ended up being 1700+ lines of code (repetitive, yes, but still!) |
| 16:42 |
kmlussier |
bshum++ for writing my release note entries for me. |
| 16:43 |
kmlussier |
Looks like it's a karma party day. :) |
| 16:43 |
bshum |
remingtron++ dbwells++ Dyrcona++ kmlussier++ |
| 16:53 |
pinesol_green |
[evergreen|Ben Shum] LP#1454879: Release notes for Account Expiration Date in OPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c6a5404> |
| 16:53 |
bshum |
And also, probably backport. |
| 16:53 |
bshum |
Cause it looks ready to go |
| 16:57 |
pinesol_green |
[evergreen|Mike Rylander] LP#1465385: Fix some syntax issues with make_release - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c05aeb2> |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:02 |
kmlussier |
hmmm |
| 17:04 |
|
edoceo joined #evergreen |
| 17:04 |
kmlussier |
Looks like it's unrelated to new copy locations this time around. |
| 00:36 |
|
eady joined #evergreen |
| 04:38 |
bshum |
kmlussier: Going to test https://bugs.launchpad.net/evergreen/+bug/1198465 later today, got it put together on our test server. |
| 04:38 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Confirmed] - Assigned to Dan Wells (dbw2) |
| 04:38 |
bshum |
Just one minor note though, one of the library settings in the upgrade script has a typo in it. "overde" instead of "overdue" |
| 05:04 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:19 |
|
Bmagic_ joined #evergreen |
| 07:47 |
|
ericar joined #evergreen |
| 07:59 |
|
rjackson_isl joined #evergreen |
| 13:40 |
csharp |
hmm - having an acq issue where my "acq admin" user can't see/interact with the list of providers (Admin -> Server Administration -> Acquisitions -> Providers) |
| 13:40 |
csharp |
as admin, I'm able to see them |
| 13:41 |
kmlussier |
csharp: Has your acq admin user been able to see them in the past? |
| 13:41 |
* csharp |
continues to look in the postgres logs for clues |
| 13:41 |
csharp |
kmlussier: I don't think so |
| 13:42 |
csharp |
the user in question has all of the *_PROVIDER perms assigned at the System level, and the providers are owned by the library system in question |
| 13:42 |
csharp |
(system, not branch) |
| 13:44 |
csharp |
I can also see that the SQL queries are being performed for the providers, but they aren't displaying |
| 13:44 |
csharp |
the user passes all the permission tests I can see being performed in the logs |
| 13:44 |
kmlussier |
This reminds me of an old bug that was fixed a long time ago. |
| 13:45 |
kmlussier |
bug 731510 |
| 13:45 |
pinesol_green |
Launchpad bug 731510 in Evergreen master "Acquisitions - Unable to view providers" (affected: 2, heat: 12) [Medium,Fix released] https://launchpad.net/bugs/731510 - Assigned to Mike Rylander (mrylander) |
| 13:45 |
kmlussier |
csharp: I can't imagine it's the same thing, but if you page through the interface, do you see the providers? |
| 13:48 |
csharp |
kmlussier: nope :-( |
| 13:49 |
kmlussier |
csharp: And the library selector on that page is the same as the OU that owns the providers? Sorry to ask obvious questions. |
| 13:50 |
csharp |
yes, that's right |
| 13:51 |
csharp |
one possible clue (that could be a red herring), the JS console shows "TypeError: item is null" |
| 13:52 |
csharp |
when I look at Open-ILS/web/js/ui/default/acq/financial/view_provider.js, I see the term "item" used - I'm assuming that's what's being referred to in the JS error |
| 13:57 |
csharp |
also 'request open-ils.acq open-ils.acq.provider.org.retrieve <authtoken>' shows the expected list via srfsh |
| 13:57 |
csharp |
which is what is called by that JS library |
| 13:58 |
csharp |
again, if I'm admin, I can see everything as expected, so it *seems* like this should be perms, but I'm not seeing any messages in the logs |
| 13:59 |
csharp |
and all the perms I do see checked appear to be assigned at the appropriate levels (or I wouldn't expect the srfsh test to work) |
| 14:03 |
berick |
csharp: the JS error mentions view_provider.js specifially? |
| 14:03 |
berick |
i think that file might actually be deprecated |
| 14:04 |
berick |
Open-ILS/web/js/ui/default/conify/global/acq/provider.js is loaded by |
| 14:40 |
jeffdavis |
Is that expected behavior? If not, how would you normally expect to prevent it in a load-balanced environment? |
| 14:41 |
bshum |
berick: gmcharlt: For https://bugs.launchpad.net/evergreen/+bug/1394989, we're looking to try implementing the solution that you suggested alternative to mrpeters' patch. If it passes, should we rework that to be a proper git branch and get it submitted towards review and inclusion in a future release? |
| 14:41 |
pinesol_green |
Launchpad bug 1394989 in Evergreen "Collections API users_of_interest can crash on users with null card values" (affected: 1, heat: 6) [Low,Confirmed] - Assigned to Michael Peters (mrpeters) |
| 14:41 |
csharp |
ooh - another point of interest - the problem is *not* happening on our production server, just our acq testing server :-/ |
| 14:41 |
bshum |
mceraso's been poking around at this at Unique's behest and we just found the LP |
| 14:42 |
gmcharlt |
bshum: yes please |
| 14:43 |
mrpeters |
sorry guys, i never caught those comments |
| 14:43 |
bshum |
From the comment, I think we can just grab berick's approach and copy it in, but we'll test and see what blows up :P |
| 14:48 |
miker |
jeffdavis: that load balancing is probably expected, and you probably don't want to prevent it. if the translator is what's initiating it, it's almost certainly because of a stateful connection from the client side, which is required for several interfaces to work correctly. they have to be able to send several messages, possibly through different apache servers, to one opensrf backend. the translator knows how to coordinate that via a memcache blob |
| 14:56 |
jeffdavis |
What we are seeing is that the translator on server A sends an XMPP request to opensrf private.localhost/open-ils.pcrud_drone_server_B, and gets a 503 error in response |
| 15:01 |
miker |
ah, yeah... you'll need to set up real (if internal-only) names and addresses and cross-register services, and set up the <trusted_domains> stuff ... I'll see if there are pointer docs |
| 01:56 |
|
Mark__T joined #evergreen |
| 02:08 |
|
geoffsams joined #evergreen |
| 02:34 |
|
hopkinsju joined #evergreen |
| 05:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:27 |
|
Callender joined #evergreen |
| 07:59 |
|
ericar joined #evergreen |
| 08:22 |
|
Shae joined #evergreen |
| 10:10 |
kmlussier |
berick: If we had a lot of bib records that were appropriate for all of the copy locations you created, I might have felt differently. |
| 10:10 |
kmlussier |
And I do think we need a better set of bib records. But we're not there yet. |
| 10:10 |
berick |
great, my thoughts exactly |
| 10:12 |
kmlussier |
The reason I found the bug was because I had asked jlitrell to look at bug 1340852. Just having any copy location groups in the test data to replicate the bug would have been helpful. |
| 10:12 |
pinesol_green |
Launchpad bug 1340852 in Evergreen "Copy Location Groups search not retaining original search params after searching" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1340852 |
| 10:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1155771 Sample data : copy locations, location groups - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=58aecfd> |
| 10:20 |
pinesol_green |
[evergreen|Bill Erickson] LP#1155771 Copy location sample data additions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=406d79e> |
| 11:08 |
bshum |
kmlussier: Well it could be... I suppose. |
| 11:09 |
bshum |
But it seems more like a "from here forward, this is how it is" kind of new feature to me. |
| 11:09 |
kmlussier |
It feels like new feature to me too. |
| 11:09 |
* bshum |
goes back to merging branches for his test system |
| 11:15 |
|
bmills joined #evergreen |
| 11:17 |
berick |
dbs: FYI it worked w/ 2 changes total: http://pastie.org/10309986 |
| 11:18 |
* berick |
just logged in to his VM catalog w/ a salted/crypted password WOOT |
| 13:05 |
kmlussier |
And working on 2 things at the same time, which is never a good idea |
| 13:05 |
jeff |
I'm still in favor of either "Other" or "General". |
| 13:05 |
mmorgan |
Multitasking is highly overrated ;-) |
| 13:06 |
* gmcharlt |
adds "Multitasking Tax" as a billing type to kmlussier's test database ;) |
| 13:06 |
jeff |
and as a refresher, the last large conversation about this subject that i recall was in January: http://irc.evergreen-ils.org/evergreen/2015-01-08#i_148257 |
| 13:06 |
tsbere |
I don't think we should label it as "Staff" myself as that would imply nothing else ever generating them. Same with "Manual", for that matter. "Other" and "General" would work well for me. |
| 13:06 |
kmlussier |
jeff: Yeah, I revisited that when I came up with the original options. |
| 13:23 |
mrpeters |
few kinks to work out still that jeffdavis has helped me with, but man it has to be nice for the patrons once its running! |
| 13:23 |
jeffdavis |
schan wrote most of the code, I just got it over the finish line - but thanks :) |
| 13:23 |
mrpeters |
schan++++++++++++++++++++++++++ too |
| 13:23 |
* kmlussier |
considers moving overdrive-eg-opac testing up on her priority list |
| 13:24 |
mrpeters |
its pretty awesome, anyone using Overdrive should try it out |
| 13:24 |
mrpeters |
i should make a demo video |
| 13:24 |
kmlussier |
mrpeters: Did it take a lot of work to get it working? |
| 16:49 |
kmlussier |
miker: Enjoy your weekend! |
| 16:51 |
* kmlussier |
disappears in a puff of smoke too. |
| 16:51 |
mmorgan |
Have a good weekend! |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:57 |
phasefx |
good way to end a Friday :) |
| 17:01 |
kmlussier |
phasefx: hmmm...could adding copy locations to the sample data affect the pgtap tests? |
| 17:01 |
* kmlussier |
obviously does not know how to disappear |
| 17:02 |
phasefx |
kmlussier: a lot of those live tests make use of the data, so if the data changes, the tests can break. This particular test expected a hold to be permited, but it was not based on a location.holdable flag |
| 17:07 |
|
mmorgan left #evergreen |
| 17:13 |
phasefx |
kmlussier: so the test makes use of item CONC51000640, and the copy location for that item changed from Stacks to Reserves (holdable = f) |
| 17:14 |
phasefx |
easy fix, at least |
| 17:14 |
* phasefx |
out, have a good weekend |
| 17:14 |
kmlussier |
phasefx: You too! |
| 19:23 |
|
bmills joined #evergreen |
| 19:50 |
|
bmills1 joined #evergreen |
| 01:16 |
|
collum joined #evergreen |
| 02:16 |
|
eady joined #evergreen |
| 02:19 |
|
jonadab_znc joined #evergreen |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:44 |
|
ericar joined #evergreen |
| 07:46 |
|
sandbergja2 joined #evergreen |
| 08:07 |
|
jboyer-isl joined #evergreen |
| 11:07 |
mmorgan |
:-D |
| 11:07 |
bshum |
kmlussier: miker: Certainly worth a shot anyways :) |
| 11:08 |
kmlussier |
Ah, yes. The serials template issue. |
| 11:08 |
bshum |
Our problem solving predated copy location groups, and we don't use them anywhere. Yet. |
| 11:08 |
bshum |
Could see how hard it is to make some groups though on a test server to illustrate the idea anyways. |
| 11:08 |
kmlussier |
bshum: I think the one problem with copy location groups is that you need to remember to add any new copy locations to the groups. |
| 11:09 |
bshum |
kmlussier: Yeah we already get fun with that whenever people forget to add new copy locations to the filder group for KPAC. :) |
| 11:09 |
bshum |
"Why doesn't my new kid's book show up in KPAC search?" Because nobody added it to the list of searchable locations... |
| 11:24 |
jeff |
yeah, in reality it was a small set of commits to look over, and it was a missing END :-) |
| 11:27 |
|
Christineb joined #evergreen |
| 11:38 |
miker |
jeff: bisect via %][% ;) |
| 11:54 |
* kmlussier |
discovers bug 1155771 two years late and realizes it would be a very handy thing to see on her test system right now. |
| 11:54 |
pinesol_green |
Launchpad bug 1155771 in Evergreen "Add copy locations, groups (more?) to sample data" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1155771 |
| 11:54 |
|
bmills joined #evergreen |
| 11:59 |
bshum |
kmlussier: Never too late... |
| 13:23 |
bshum |
So i think you're missing something else more major. |
| 13:23 |
bshum |
DPearl: You installed OpenSRF right? |
| 13:27 |
DPearl |
bshum: OpenSRF is in and running. |
| 13:37 |
jeffdavis |
kmlussier: I think we ran into that bug during our upgrade testing, give me a minute to try and dig up our fix |
| 13:41 |
kmlussier |
Thanks jeffdavis! |
| 13:46 |
bshum |
Hmm |
| 13:46 |
bshum |
cat.sip_field() is null |
| 13:47 |
kmlussier |
jeffdavis++ |
| 13:48 |
kmlussier |
I'll get it loaded on a VM and hopefully get a signoff on it today. |
| 13:48 |
kmlussier |
bshum: It's strange, though. Looking at the history of the file, it hasn't been modified since 2012. I wonder why it suddenly became a problem in 2.8. |
| 13:48 |
* bshum |
is testing it too; but can push kmlussier's signoff version when you've tested too |
| 13:48 |
jeffdavis |
Yeah, I never figured out why it wasn't a problem before. |
| 13:49 |
bshum |
Looks good to me. |
| 13:49 |
bshum |
jeffdavis++ |
| 13:51 |
kmlussier |
I don't know what point release they're at. |
| 13:51 |
bshum |
Okay, well then I won't backport unnecessarily |
| 13:52 |
* kmlussier |
could always bring up 2.7 on a VM just to be sure, but thinks we're probably okay there. |
| 13:52 |
bshum |
If you get to test it later, just add a note if we need to backport it further. |
| 13:52 |
bshum |
I'll leave it be for now. |
| 13:57 |
pinesol_green |
[evergreen|Jeff Davis] LP#1477677 - fix JS TypeError that prevents stat cats from displaying in stat cat editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b5a0a74> |
| 14:01 |
jeff |
the marc_xml that /opac/myopac/circs has access to does not contain <attributes>, so displaying format (short of falling back to LDR/06) is not possible |
| 14:18 |
kmlussier |
jeffdavis++ bshum++ #I love it when bugs are fixed on the day they're reported! |
| 14:59 |
jeff |
yep. exactly that. |
| 15:01 |
|
jlitrell joined #evergreen |
| 15:02 |
jeff |
0865 only upgraded holdable_formats WHERE hold_type = 'M' AND fulfillment_time IS NULL |
| 15:05 |
kmlussier |
I just realized berick didn't have a pullrequest on the branch that adds copy locations to the sample data, but I signed off on it anyway because I do think it's useful to have on a test system. |
| 15:05 |
berick |
kmlussier++ |
| 15:06 |
berick |
it was only missing the pullreq becuase i have vague plans to do more with it. it was certainly pull-able |
| 15:06 |
berick |
s/have/had/ |
| 15:43 |
jeff |
csharp++ |
| 15:49 |
jeff |
ah, because we're locally keying off of subjects and such also. |
| 15:57 |
dbs |
csharp++ |
| 16:26 |
jeff |
hrm. also breaks on values like {"0":[{"_attr":"item_type","_val":"a"},{"_attr":"item_type","_val":"t"}],"1":"","2":[{"_attr":"item_lang","_val":"eng"}]} |
| 16:26 |
jeff |
due to the "1":"" |
| 16:27 |
jeff |
note to self: sample/test data needs fulfilled metarecord holds. ;-) |
| 16:34 |
|
bmills joined #evergreen |
| 16:37 |
jeff |
hrm. so 'at--eng' is transformed into '{"0":[{"_attr":"item_type","_val":"a"},{"_attr":"item_type","_val":"t"}],"1":"","2":[{"_attr":"item_lang","_val":"eng"}]}' |
| 16:38 |
jeff |
and that is the most common legacy holdable_formats value in our data |
| 16:43 |
jeff |
the upgrade script didn't generate any values that are invalid json, though... so that's good! :-) |
| 16:48 |
|
buzzy joined #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 18:37 |
|
akilsdonk joined #evergreen |
| 11:57 |
kmlussier |
Yeah, I understand there aren't additional steps. I just know that my three consortia would most likely not give the manual void permission to anyone, and if every other site that prohibits negative balances does the same thing, it may just be extra work, extra options, and extra permissios when we might not need them. |
| 11:58 |
|
mtj_- joined #evergreen |
| 11:59 |
dbwells |
mmorgan: That's correct. |
| 11:59 |
kmlussier |
mmorgan: Yes, and all of most tests showed that the automatic piece was working properly. Of course, I could have missed a test, but I did my best to make it break. :) |
| 12:00 |
kmlussier |
s/most/my |
| 12:00 |
|
Christineb joined #evergreen |
| 12:01 |
dbwells |
We're just trying to figure out how to handle the manual void using the interface. At the very least we need the interface to switch terminology, so that the void option goes away and is replaced with a zero option. Otherwise we just accentuate confusion that they are not the same thing. If we just want to start with that, it makes sense to me. |
| 12:02 |
mmorgan |
Ok, thanks. I'm trying to think of a use case where staff manually voiding a partially paid lost item would expect a negative balance for the amount the patron paid. |
| 13:03 |
gmcharlt |
and ditto for bshum |
| 13:03 |
kmlussier |
gmcharlt: Let's assign RoganH with all the tasks. |
| 13:03 |
* rfrasur |
chuckles |
| 13:03 |
gmcharlt |
inevitable joke is inevitable ;) |
| 13:04 |
gmcharlt |
#topic Status updates / past action items |
| 13:04 |
gmcharlt |
#action At long last, the DIG test VM will be up later this afternoon |
| 13:04 |
kmlussier |
Woo hoo! |
| 13:04 |
gmcharlt |
er |
| 13:04 |
kmlussier |
gmcharlt++ |
| 13:05 |
gmcharlt |
#info At long last, the DIG test VM will be up later this afternoon |
| 13:05 |
gmcharlt |
#info A copy of the webserver VM has been created, http://test-www.evergreen-ils.org/ |
| 13:05 |
gmcharlt |
it's been used to test an operating system upgrade to Debian Jessie |
| 13:05 |
gmcharlt |
as well as a software upgrade for the Piwik web analystics package |
| 13:06 |
gmcharlt |
bshum is still poking at Piwik, but we should be able to schedule a production OS upgrade for the main webserver, lupin, soon |
| 13:07 |
gmcharlt |
so, one of the incidental things from that: the Piwik data for the past few years is consuming a fair amount of disk space on lupin |
| 13:07 |
gmcharlt |
and bshum and I have been discussing pruning it down to just keeping the past year of analytics |
| 13:08 |
gmcharlt |
on the basis that it will save disk space, that the web statistics data have not been really used, and if they were looked at, there's little reason to keep more than a year of them |
| 13:08 |
gmcharlt |
any thoughts about that before we commit to that position? |
| 13:08 |
kmlussier |
A year of stats seems reasonable to me. |
| 13:08 |
phasefx |
sounds good to me |
| 13:09 |
rfrasur |
Is someone tracking the web stats offline? |
| 15:49 |
|
jlitrell joined #evergreen |
| 16:52 |
|
buzzy joined #evergreen |
| 17:02 |
|
buzzy joined #evergreen |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:22 |
|
mmorgan left #evergreen |
| 17:51 |
|
bmills joined #evergreen |
| 17:56 |
|
buzzy joined #evergreen |
| 03:45 |
|
Christineb_away joined #evergreen |
| 04:09 |
|
collinanderson joined #evergreen |
| 04:17 |
|
sbrylander joined #evergreen |
| 04:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:12 |
|
sarabee joined #evergreen |
| 05:45 |
|
sarabee joined #evergreen |
| 07:51 |
|
ericar joined #evergreen |
| 10:42 |
|
kmlussier joined #evergreen |
| 10:42 |
|
mceraso joined #evergreen |
| 10:42 |
|
bshum joined #evergreen |
| 10:42 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 10:44 |
|
RoganH joined #evergreen |
| 10:48 |
|
jboyer_isl joined #evergreen |
| 10:52 |
|
jboyer-isl joined #evergreen |
| 11:11 |
|
kmlussier joined #evergreen |
| 11:11 |
|
mceraso joined #evergreen |
| 11:11 |
|
bshum joined #evergreen |
| 11:11 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 11:40 |
Bmagic |
welcome bshum |
| 11:45 |
phasefx |
bshum Bmagic, b excellent to one another <air guitar> |
| 11:45 |
Bmagic |
ha |
| 15:41 |
jboyer-isl |
Oops, 2. (one has 2 subfields) |
| 15:53 |
bshum |
berick++ # bug 1476370, the second half is something I was starting to look at once, cause the timeout thing is happening to us a lot lately. |
| 15:53 |
pinesol_green |
Launchpad bug 1476370 in Evergreen "Selfcheck warn on patron auto-logout, reset activity timer on checkout" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1476370 - Assigned to Bill Erickson (berick) |
| 15:53 |
bshum |
berick: We'll be glad to test whatever you come up with as you work on it. |
| 15:54 |
berick |
bshum: awesome, thanks. |
| 15:54 |
berick |
glad we're not the only ones |
| 15:55 |
berick |
not that I wish pain on others.. you know what I mean ;) |
| 02:11 |
|
Mark__T joined #evergreen |
| 02:51 |
|
jeff_ joined #evergreen |
| 04:23 |
|
Callender joined #evergreen |
| 05:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:41 |
|
mrpeters joined #evergreen |
| 07:49 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
rjackson_isl joined #evergreen |
| 09:27 |
RoganH |
I haven't had to clean up dog accidents in a while but we get a new foster dog today so that'll probably change. |
| 09:28 |
|
yboston joined #evergreen |
| 09:28 |
Bmagic |
ldw: acq.fund_allocation has 2 rows for the fund in question. The first row was the addition of the moneys. The second is the negative amount to balance it to 0. |
| 09:29 |
RoganH |
Quick opinion question. bshum and I were chatting at ALA and he opinioned that pgtap tests for has_table and has_view tests would be good to have. Drudgery to write but good to have. I'd be willing to write them if they'd be useful. |
| 09:30 |
Bmagic |
ldw: I deleted the row that was added after the rollover. Specifically, I just changed the fund id number to point to this years fund instead of last years fund. I realize that perhaps there are some database triggers that need to fire, and I just changed the ID, perhaps they didnt fire |
| 09:37 |
csharp |
RoganH: can you easily summarize what they do? or is that a job for the Goog? ;-) |
| 09:38 |
jboyer-isl |
RoganH: That does sound useful in a “You have a sane database, you’re off to a good start” kind of way. It shouldn’t be too difficult to build, a couple carefully constructed queries from INFORMATION_SCHEMA and you’re halfway there. |
| 09:39 |
csharp |
okay, so they just check for whether the table/view exists then? |
| 09:39 |
csharp |
if so, yeah |
| 09:39 |
jboyer-isl |
I can’t remember if pgtap has something like has_index, but that would also be a big help for those of us with long upgrade histories. (hi csharp!) |
| 09:40 |
csharp |
I still occasionally find a missing table or index from the 1.6 - 2.1 upgrade we did over three years ago, so yeah, I'd like that sort of test :-) |
| 09:41 |
csharp |
jboyer-isl: exactly ;-) |
| 09:41 |
RoganH |
csharp: basically they verify that the tables and views that should be there are |
| 09:41 |
RoganH |
jboyer-isl: exactly |
| 09:42 |
RoganH |
jobyser-isl: yep, it has has_index |
| 09:42 |
RoganH |
I'd be willing to write the has_index tests too |
| 09:49 |
csharp |
RoganH++ |
| 09:49 |
kmlussier |
RoganH++ |
| 09:49 |
jboyer-isl |
RoganH++ |
| 10:04 |
jboyer-isl |
It may help to use tables_are rather than has_table, that way you can verify whole schema at a time rather than each table individually. |
| 10:05 |
jboyer-isl |
There are also indexes_are and schema_are, etc. |
| 10:05 |
jboyer-isl |
Arr! |
| 10:05 |
RoganH |
jobyer-isl: The downside of using _are is that if people have added extra tables it will trigger that as a fail on the test. |
| 10:06 |
RoganH |
jobyer-isl: so I was thinking of doing both so that if one passes and the other fails you know it's only because of the added tables/views/whatever. |
| 10:06 |
jboyer-isl |
Oh, I might have misread then, I thought it only complained about missing, but that makes sense. |
| 10:06 |
RoganH |
jboyer-isl: my apologies for butchering 'boyer' twice in a row! |
| 10:07 |
RoganH |
jboyer-isl: let me check, maybe I'm wrong |
| 10:07 |
jboyer-isl |
You should hear how some other people have tried to spell it over the years. “Is that wirh a “W”? how many “Y”’s, etc.) |
| 10:07 |
RoganH |
jboyer-isl: I get it with Rogan a lot though you wouldn't think it's that hard to pronounce or spell |
| 10:10 |
RoganH |
jobyer-ils: yeah, the _are functions check to see if there are extra tables/views/whatever and fail the test then |
| 10:10 |
RoganH |
So I lean to including both for more granularity of testing. |
| 10:11 |
RoganH |
Once I've pulled the tables/views/whatever out of information_schema it won't be that big a deal to do both |
| 10:11 |
jboyer-isl |
Yeah, I should have read more closely. In that case I’d be hesitant to use the _are functions because I’m always wary of “it’s ok if X fails” and the like. (Now, I also think anyone adding any tables should do it in a separate schema like local. or similar, but I don’t want to argue about it) |
| 10:12 |
jboyer-isl |
Also, in the “correct” case it’s testing a bunch of stuff twice which I’m also not a big fan of. |
| 10:12 |
RoganH |
jboyer-isl: I can see it both ways. Maybe add the _are tests in a separate subfolder under /t |
| 10:13 |
jboyer-isl |
It’s up to you. More files to maintain = more potential for drift though. |
| 10:13 |
tsbere |
RoganH: Are you doing things by hand? |
| 10:14 |
jboyer-isl |
(It’s tempting to only use _are and badger people into accepting my local. notion, but then schema_are complains and it’s all in shambles now.) |
| 10:14 |
RoganH |
RoganH: not really, most of it is pulling it out of information schema and then having some scripts construct it though I go through and check them. |
| 10:14 |
RoganH |
why am I replying to myself? I'm feeling very self referential. |
| 10:15 |
tsbere |
RoganH: I just seem to recall we already have a script pulling things out of information schema for tests, wasn't sure if you were just adding to that script or not |
| 10:16 |
jeff |
adding new tables in a distinct schema is often good, but I'm pretty sure we have some schemas where local tables are not uncommon -- such as people who audit more tables than are audited in a stock system. |
| 10:16 |
RoganH |
jeff: that was my concern, and one reason I wanted a conversation about it. my first instinct was to say that _are is bad because it will generate errors and then confuse people. Then another part of me wants the granularity. |
| 10:17 |
RoganH |
I think the _are tests can be good but maybe shouldn't be in /t. |
| 10:18 |
RoganH |
Anyway, I'll proceed with tidying up the has_ tests and worry about are_ tests another day. |
| 10:19 |
|
collum joined #evergreen |
| 10:21 |
bshum |
kmlussier: I noticed that problem with the IRC log site after the reboot, but I hadn't quite figured it out yet. |
| 10:21 |
bshum |
Using the full URL for the index will give you the page though: http://irc.evergreen-ils.org/evergreen |
| 14:18 |
yboston |
of course swap out phones for whatever technology you prefer |
| 14:19 |
rfrasur |
Let's revisit it. I will say that I'm not a big fan of phone meetings just because I process information visually and because of recordability issues. |
| 14:19 |
rfrasur |
Oh, okay, lol. |
| 14:19 |
tspindler |
fyi, if we want to test it out, C/W MARS has a go to webinar account to accomodate up to 100 |
| 14:19 |
montgoc1 |
I enjoyed the last phone meeting and it is nice to hear voices once in a while. |
| 14:19 |
rfrasur |
tspindler++ |
| 14:19 |
yboston |
tspindler: would you like to set up a test a few motnhs from now? |
| 14:19 |
abneiman |
I've expressed my preference before about phone meetings, in the sense that I feel they facilitate more conversation. |
| 14:19 |
tspindler |
yboston: yes I can |
| 14:19 |
abneiman |
However I understand the need to balance that with openness, convenience, etc. |
| 14:23 |
tspindler |
yboston: I could set up a session with go to webinar sometime (not as a meeting) but anyone can then participate and see how it works |
| 14:23 |
csharp |
we can research it |
| 14:23 |
sherbertbc |
rfrasur: agree on 4 months to revisit |
| 14:23 |
yboston |
so team has volunteered his system, would somebody like to volunteer to test out using Google Hangout? |
| 14:24 |
yboston |
sorry Tim not team |
| 14:24 |
csharp |
the only downside is that it requires a google account to access it, and (theoretically) some may object to that being a barrier to participation |
| 14:24 |
rfrasur |
Well, we tested that already for the meet and greet. |
| 14:25 |
rfrasur |
But, I can test a Google On Air Hangout, if that's what you mean. |
| 14:25 |
csharp |
we have a Chrome for meetings box at GPLS that is severely underutilized |
| 14:25 |
csharp |
I'll investigate that |
| 14:25 |
yboston |
so 4 months from now is November, we can just shoot to try a meeting with either technology by then |
| 14:25 |
yboston |
sorry, just trying to come up with actionable items |
| 14:25 |
rfrasur |
csharp++ #I don't know anything about that. Sounds interesting. |
| 14:26 |
tspindler |
yboston: I'll announce a test meeting in the next 2 months to use our GoToWebinar so we can test it and invite other members of the Evergreen community to join if they want. |
| 14:26 |
yboston |
OK |
| 14:27 |
yboston |
#action tspindler will announce a test meeting in the next 2 months to use our GoToWebinar so we can test it and invite other members of the Evergreen community to join if they want. |
| 14:28 |
yboston |
#idea use non IRC meetigns when there are topics where IRC might not feel like the best medium |
| 14:28 |
tspindler |
yboston: do you have any theoretical situations where this is the case? |
| 14:28 |
yboston |
#idea if using Google Hangouts, use the "on air" feature to allow others to watch/listen |
| 14:29 |
csharp |
yeah, I think if we meet the criteria of 1) openness to non-board attendees and 2) recording for posterity, I think that would fly with most people |
| 02:10 |
|
TaraC joined #evergreen |
| 04:28 |
|
_robbat2|irssi joined #evergreen |
| 04:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:34 |
|
Mark__T joined #evergreen |
| 07:44 |
|
rjackson_isl joined #evergreen |
| 07:48 |
|
jboyer-isl joined #evergreen |
| 10:54 |
csharp |
well, they can for us, so I'm trying to rule out the possibility that this is an EG bug or something in our setup |
| 10:54 |
* bshum |
can double check |
| 10:54 |
csharp |
bshum++ #thanks! |
| 10:56 |
bshum |
csharp: When I use an expired staff account, I can still log into the staff client with it. |
| 10:56 |
bshum |
That's fun. |
| 10:56 |
bshum |
At least on one of my master test servers. |
| 10:56 |
csharp |
excellent - it's not just me! |
| 10:57 |
bshum |
So I presume that qualifies your 2.7+ |
| 10:57 |
csharp |
@bugforeveryoneorjustme.com |
| 12:56 |
bshum |
mmorgan++ # That sounds like it could be a culprit... |
| 13:07 |
jeffdavis |
It's a good suggestion, but the session itself seems fine. With these steps: (1) login, (2) pull authtoken for login from logs, (3) attempt offline circ upload and get the NO_SESSION error, (4) do 'request open-ils.auth open-ils.auth.session.retrieve "AUTHTOKEN"' via srfsh and I can retrieve the session. |
| 13:08 |
jeffdavis |
Sorry for the incoherent grammar :) |
| 13:12 |
jeff |
jeffdavis: check your offline-config.pl to ensure that it is valid and correct, not pointing to an old opensrf_core.xml? |
| 13:14 |
jeff |
jeffdavis: i would expect things to fail before that error if you had a missing config, but if the config is valid, but for testing and not production, or similar... the memcached instance isn't going to have your session token. |
| 13:16 |
berick |
and make sure you don't see this near the top offline.pl: |
| 13:16 |
berick |
do '##CONFIG##/offline-config.pl'; |
| 13:17 |
berick |
##CONFIG## is replaced during build |
| 14:05 |
jeffdavis |
dbwells: Yes, I am seeing "No user in the cache exists with key oils_auth_" (i.e. with ses missing) after clicking "Upload" |
| 14:22 |
|
ningalls joined #evergreen |
| 14:23 |
dbwells |
jeffdavis: This might be an odd question, but what do you see for the offline GET requests in the Apache access log? Is 'ses' missing there, too? (If not, maybe this is a quirk with the Apache config.) |
| 14:24 |
jeffdavis |
ses is present and correct on the GET requests. |
| 14:29 |
jeffdavis |
hm, no, I take it back. When I click Upload, there is a GET /cgi-bin/offline/offline.pl which is missing cgi params, although they are present for other requests to offline.pl |
| 14:33 |
jeffdavis |
When it works on a test server, I see GET requests to upload_xacts.xhtml and upload_xacts.js, then POST /cgi-bin/offline/offline.pl, then GET /cgi-bin/offline/offline.pl with cgi params. |
| 14:33 |
jeffdavis |
When it fails in production, I don't see the post, and the subsequent GET /cgi-bin/offline/offline.pl is missing CGI params. |
| 14:40 |
Bmagic |
csharp: more on the invoces: We send a purchase order for a specific provider+vendorcode. The EDI goes to Baker and Taylor with that embedded. The invoice that we get back does not contain the specific vendorcode and therefore it's up to Evergreen to decide which to link. |
| 14:41 |
|
RoganH joined #evergreen |
| 14:42 |
Bmagic |
csharp: presumably Evergreen has all of the information in order to link it back to correct vendor code because the invoice mentions the PO number. And the PO has the vendorcode. But on my server, it's linking it back to a different vendorcode that seemly random |
| 00:30 |
|
bmills joined #evergreen |
| 01:28 |
|
Mark__T joined #evergreen |
| 02:17 |
|
bmills joined #evergreen |
| 04:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:16 |
|
rlefaive joined #evergreen |
| 07:32 |
jeff |
@coffee everyone |
| 09:33 |
* Dyrcona |
taps foot in annoyance. |
| 09:44 |
|
rlefaive joined #evergreen |
| 09:56 |
|
remingtron joined #evergreen |
| 10:09 |
jboyer-isl |
Dyrcona: for simple tests, you could consider using the Evergreen migration tools to just pull out one or two of your libs data for quicker restores. (depending on your wait time, that is.) |
| 10:09 |
Dyrcona |
jboyer-isl: But, we use this database for training library staff, so it is nice to have it up to date with production from time to time anyway. |
| 10:10 |
jboyer-isl |
Oh yeah, you did mention it was a training system. I was thinking just a quick test server setup. |
| 10:12 |
|
mllewellyn joined #evergreen |
| 10:35 |
Dyrcona |
heh. After you login, you get a message that you may need a special password, i.e. different from the production server. |
| 10:38 |
Dyrcona |
And LookupUser works, so I s'pose the configuration is correct. |
| 10:49 |
kmlussier |
Dyrcona: Good luck with the testing. I hope it goes well! |
| 10:50 |
Dyrcona |
kmlussier: Thank you. I hope it doesn't eat up the whole of my "vacation." |
| 10:50 |
kmlussier |
Dyrcona: I hope not either. |
| 11:02 |
|
rlefaive joined #evergreen |
| 11:57 |
berick |
jboyer-isl: yep |
| 11:58 |
jboyer-isl |
Ah. I wasn't interested enough to look into it and we pull sip logs out by machine name now. |
| 11:58 |
jboyer-isl |
Fixing the actual issue would be nice though. |
| 11:59 |
berick |
yeah, it was always just a minor annoyance for me, until recently when we migrated to ubuntu (which included all kinds of packaage updates, etc.) the PID was no longer appearing in the SIP syslog output |
| 12:00 |
berick |
which makes tracking conversations practically impossible |
| 12:00 |
berick |
SIP enables the syslog pid format, but opensrf does not, so it was getting clobbered |
| 12:01 |
berick |
testing my patch now on our test sip server fixes both issues (format and destination) |
| 12:05 |
berick |
now just need to teach SIP to read syslog_facility from oils_sip.xml instead of hard coding it |
| 12:06 |
jboyer-isl |
berick++ |
| 12:06 |
jboyer-isl |
Getting things done over there. |
| 12:14 |
dbs |
berick++ |
| 13:22 |
|
ericar_ joined #evergreen |
| 14:11 |
|
nuentoter joined #evergreen |
| 14:12 |
nuentoter |
quick question, anyone running ubuntu and evergreen on a vmware/virtualbox? |
| 14:13 |
bshum |
nuentoter: for testing, virtualbox, sure. |
| 14:13 |
bshum |
For production? No. |
| 14:13 |
nuentoter |
ok thats what i wanted to know ty very much sir |
| 14:13 |
bshum |
We do use other virtualization for applications |
| 14:13 |
bshum |
Err, okay then. |
| 11:49 |
|
bmills joined #evergreen |
| 12:05 |
|
buzzy joined #evergreen |
| 12:07 |
|
mmorgan1 joined #evergreen |
| 12:19 |
kmlussier |
Sigh...apparently I already had a set of negative balance use cases posted at http://wiki.evergreen-ils.org/doku.php?id=scratchpad:negative_balances that are not the same as the test cases I shared last week, but are similar enough that I probably didn't need to create 2 pages. |
| 12:20 |
kmlussier |
I don't even remember writing up those notes. |
| 12:20 |
bshum |
kmlussier: Good times :) |
| 12:22 |
kmlussier |
The first page actually has a lot more differences in how libraries might configure their settings, but I can't say I tested all those scenarios. http://wiki.evergreen-ils.org/doku.php?id=qa:billing_test_cases is an accurate reflection of what I tested. |
| 12:23 |
|
mmorgan1 joined #evergreen |
| 12:31 |
Dyrcona |
Too many settings, says the guy who usually solves problems by coding a new setting or three. |
| 12:33 |
bshum |
YAOUS+- |
| 13:30 |
Dyrcona |
RoganH++ |
| 13:30 |
RoganH |
rfrasur: myself included |
| 13:31 |
rfrasur |
and the blissfulness of youth....and the fact that good days are WAY longer when you're young (someday that'll be quantifiable without a whole lot of calculus) |
| 13:31 |
kmlussier |
Hmmm...In Firefox, if I try to access the web client login screen on either webby or on Dyrcona's test server, I get a blank screen below the navigation menu. In Chrome, I can pull up the login page properly on webby, but not on Dyrcona's server. |
| 13:31 |
jeff |
though i'm amused that my environment is resulting in bullets that look like <B7> in my pager... |
| 13:31 |
kmlussier |
Does anyone else have trouble getting to a login page on webby? |
| 13:32 |
jeff |
kmlussier: webby's cert seems to have expired 2015-06-27 |
| 17:01 |
kmlussier |
The "Require at least one address for Patron Registration" OU setting appears to work when doing a new patron registration. It prevents you from clicking the x that removes the address fields from the patron registration form. |
| 17:01 |
kmlussier |
However, when you edit a patron record, there is nothing that stops you from removing all addresses from that record. |
| 17:01 |
kmlussier |
Is that expected behavior? |
| 17:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:02 |
kmlussier |
I'll leave you all to ponder that question while I sit in afternoon rush hour traffic. :) |
| 17:03 |
|
bmills joined #evergreen |
| 17:11 |
jwoodard |
My Evergreen question for the day. I am trying to create a Copy Location. I have created it but it is not showing up. |
| 19:34 |
kmlussier |
miker: Ah, ok. Gotcha! |
| 21:13 |
|
jlitrell joined #evergreen |
| 21:23 |
|
gsams joined #evergreen |
| 22:26 |
|
mmorgan1 joined #evergreen |
| 22:36 |
|
finnx left #evergreen |
| 22:37 |
|
finnx joined #evergreen |
