| 01:32 |
* bshum |
sighs |
| 01:44 |
bshum |
@later tell dbs I put some thoughts on the bug in reply, but I think we should forward port 2.6.2-2.6.3 to rel_2_7. Master already has it, so the question is changing the assumption that you can upgrade at any point along the 2.6 to 2.7.0, but actually it needs to be 2.6.3-2.7.0 (exactly) |
| 01:44 |
pinesol_green |
bshum: The operation succeeded. |
| 01:45 |
bshum |
Not sure if that's better or worse actually.... version upgrades are such a mess. I'm sorry that I couldn't test it more thoroughly myself. Not being on any particular version is a downside to my own personal testing efforts of these scripts :( |
| 01:46 |
bshum |
dbs++ # actually getting 2.7 tested :) |
| 01:54 |
bshum |
I also updated bug status on bug 800478 (that's 0890) and bug 1189556 (that's 0891) |
| 01:54 |
pinesol_green |
Launchpad bug 800478 in Evergreen "Acquisitions - Funds transfer always transfers entire fund, not specified amount" (affected: 5, heat: 34) [Medium,Confirmed] https://launchpad.net/bugs/800478 |
| 01:54 |
pinesol_green |
Launchpad bug 1189556 in Evergreen "Typo: 'Allows a user to process and verify ULSs'" (affected: 1, heat: 6) [Low,Confirmed] https://launchpad.net/bugs/1189556 |
| 01:54 |
bshum |
We'll have to fix those as well to figure out how to incorporate those upgrade script fixes in the 2.7 series. |
| 01:55 |
bshum |
dbs++ # seriously bummed that 2.7.0's upgrade script is wonky :( |
| 01:55 |
bshum |
bshum-- |
| 01:55 |
bshum |
Oh well. Something to ponder more today while avoiding the snow... |
| 05:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:31 |
paxed |
dbs: i'm going to steal some parts of your intro-to-git - i got tasked to teach git at work ... |
| 05:47 |
|
wsmoak joined #evergreen |
| 06:28 |
|
eeevil joined #evergreen |
| 11:40 |
Dyrcona |
csharp: You got that file from OCLC, or you exported it from Evergreen? |
| 11:41 |
csharp |
exported from Evergreen |
| 11:41 |
Dyrcona |
Never seen those particular errors from an Evergreen export before. |
| 11:41 |
csharp |
and that particular file has already been processed - I was using it as a test case for my perl script |
| 11:41 |
* csharp |
tries another |
| 11:42 |
Dyrcona |
I often have charset conversion errors when they want MARC8 and records with empty fields because of it. |
| 11:42 |
Dyrcona |
I'd ask OCLC if they'd accept MARC21XML. :) |
| 11:43 |
csharp |
maybe I can try MARC::Charset->ignore_errors() |
| 11:43 |
csharp |
ok |
| 11:44 |
Dyrcona |
csharp: All the vendors do. Our tools work. Why should we change them? |
| 11:44 |
bshum |
eeevil++ # fun reading indeed :) |
| 11:44 |
csharp |
well, since my script is theoretically sound, and the files I'm testing with have known issues, I'll try a new export and test on it. |
| 11:44 |
csharp |
Dyrcona: thanks for being a sounding board |
| 11:45 |
csharp |
bshum: after the holiday, I'd love to compare notes with you on the Dell DBs |
| 11:45 |
Dyrcona |
csharp: You might have low ascii in some of your fields. |
| 11:45 |
bshum |
csharp: For sure! I think things have gone much better since we reformatted them (again) and made all the changes to the configs. |
| 11:46 |
Dyrcona |
It's not supposed to be there, but old data could have it. |
| 15:11 |
berick |
hm, right, user.js would need to live in the egCoreMod in that case (instead of egUserMod) |
| 15:27 |
|
artunit_ joined #evergreen |
| 15:51 |
|
Dyrcona joined #evergreen |
| 16:38 |
pinesol_green |
[evergreen|Lynn Floyd] Docs: Update to template receipt docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3c40129> |
| 16:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
|
mmorgan left #evergreen |
| 17:39 |
|
artunit joined #evergreen |
| 18:52 |
|
dcook 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> |
| 05:51 |
|
wsmoak joined #evergreen |
| 05:51 |
|
wsmoak joined #evergreen |
| 06:31 |
|
mtate joined #evergreen |
| 10:43 |
jeff |
(because those do set physical_loc) |
| 10:43 |
Dyrcona |
jeff: Ok. I thought it might be to stop it loading in the library after I asked my question. |
| 10:43 |
|
krvmga joined #evergreen |
| 10:44 |
kmlussier |
eeevil: I was just testing out the code you added for https://bugs.launchpad.net/evergreen/+bug/1367926. |
| 10:44 |
pinesol_green |
Launchpad bug 1367926 in Evergreen "Add support for (nearly) direct access to the full unapi backend" (affected: 1, heat: 6) [Wishlist,New] |
| 10:44 |
kmlussier |
Using the example from your git branch, going to http://mlnc2.mvlcstaff.org/opac/extras/unapi?id=tag::U2@acp/CONC40000537{acn,bre,mra}/-/0/barcode&format=xml seems to work well. |
| 10:45 |
krvmga |
Under what circumstances might a staff client stay logged in, even if the PC is shut down? I had this question and I think the answer is "under no circumstances" but I want to be sure. |
| 13:41 |
dbs |
Ah, ye olde "ERROR: could not find trigger 5235330" at commit time. WUT? |
| 13:42 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1261355 |
| 13:42 |
pinesol_green |
Launchpad bug 1261355 in Evergreen 2.6 "2.4.3-2.5.0-upgrade-db.sql causing "could not find trigger" PostgreSQL error" (affected: 3, heat: 14) [Undecided,Fix released] |
| 13:47 |
csharp |
dbs: in my case, I had to comment out one of the sub-scripts that were apparently colliding and ran it separately - I didn't actually test the patch once I figured out my own hack |
| 13:47 |
csharp |
so csharp-- for not following up :-/ |
| 13:50 |
csharp |
so, I thought I would just throw this out there, to see if anyone is seeing a similar issue... |
| 13:50 |
csharp |
we're getting sporadic reports from libraries (some, but not all) where the staff client white screens when doing patron updates |
| 13:51 |
csharp |
and they get a Windows message that xulrunner has stopped responding |
| 13:51 |
dbs |
csharp: thanks; trying again to see what happens :0 |
| 13:51 |
dbs |
csharp: ugh. not a memory bloat thing? |
| 13:52 |
csharp |
dbs: apparently not. terran and I saw it happen and were able to see the Windows Task Manager at the time |
| 14:45 |
|
ericar joined #evergreen |
| 14:56 |
|
akilsdonk_ joined #evergreen |
| 15:03 |
|
krvmga joined #evergreen |
| 15:07 |
jboyer-isl |
A completely different question: Can anyone tell me when openils_dojo.js is created? I can see where it's defined (openils.profile.js) but not where it's built. |
| 15:07 |
jboyer-isl |
And of course, it doesn't exist on my test server. |
| 15:09 |
gsams |
question for the masses, supposing I'm not interrupting something, I'd like for fine alerts on renewals to only prompt once for the threshold. Is this possible? |
| 15:09 |
gsams |
currently the alert pops up for each item, and when you are talking about 50+ items it can really slow things down. |
| 15:10 |
|
dreuther_ joined #evergreen |
| 15:20 |
Dyrcona |
bshum: If it was minified away, I think the templates, etc. that refer to it should be updated, don't you? |
| 15:20 |
pinesol_green |
Launchpad bug 1076582 in Evergreen "Documentation explaining openils_dojo.js" (affected: 1, heat: 8) [Low,Confirmed] |
| 15:20 |
bshum |
"Secret sauce" |
| 15:20 |
kmlussier |
jihpringle: the patch for bug 1380709 is on mlnc3.mvlcstaff.org whenever you have time to test it. |
| 15:20 |
pinesol_green |
Launchpad bug 1380709 in Evergreen 2.6 "invoice print amounts-per-fund uses wrong value when item price varies" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1380709 |
| 15:20 |
bshum |
It's used in building custom dojo builds |
| 15:20 |
bshum |
We reference it, but it's not built unless you follow those scratchpad notes |
| 15:28 |
bshum |
Good times... |
| 15:29 |
csharp |
jboyer-isl: thanks - sounds like we have the same issue |
| 15:29 |
bshum |
jboyer-isl++ |
| 15:36 |
jihpringle |
kmlussier: thanks, I'll test that patch later today :) |
| 15:49 |
jboyer-isl |
csharp, One more data point, I'm not certain what version PINES is on, but we've been seeing this on 2.5(.2) I can't remember if we were running into it on 2.2. |
| 15:58 |
csharp |
jboyer-isl: yep - we're on 2.5.1+ (which is probably pretty close to 2.5.2 |
| 15:58 |
csharp |
) |
| 16:06 |
dbwells |
If you install from a git checkout, you don't have it. |
| 16:06 |
dbwells |
It isn't actually tied into the install process. |
| 16:07 |
dbwells |
As you noticed it doesn't cause any errors if it isn't there, as Dojo just falls back to the separate file requests. |
| 16:07 |
jboyer-isl |
bshum, dbwells: sorry, I meant I think csharp's issue with the client hogging a core and dying is related to the last time we changed xulrunner. Since my test server builds out of git repos I understand why I don't have those dojo files now. :) |
| 16:08 |
bshum |
Ah, my bad too then. |
| 16:09 |
jboyer-isl |
(I'm working on building them as we speak, however, because I hate 404's and love speed. :) ) |
| 16:10 |
dbwells |
jboyer-isl: If you have any issues with the build, you can also just grab the one we throw in the releases from here: http://evergreen-ils.org/downloads/dojo.tgz |
| 08:51 |
|
jwoodard joined #evergreen |
| 08:52 |
mrpeters |
dbwells++ thank you for the great info last night. so, we have retrieve_all, search_, are there others? any documentation on this I can read? |
| 09:11 |
dbwells |
mrpeters: I'm not sure if there is any thorough documentation for that. A few bits and pieces exist in various tutorials, mostly the work of dbs. |
| 09:12 |
mrpeters |
10-4 yeah, he has lots of great stuff for opensrf |
| 09:12 |
mrpeters |
i think i have this working, about to fire up and test |
| 09:12 |
mrpeters |
i was missing declaring my $auth along with $ident_type |
| 09:13 |
dbwells |
mrpeters: The usual CRUD (create/retrieve/update/delete) commands are all available, as well as search, batch_retrieve, and retrieve_all. |
| 09:13 |
mrpeters |
ok, very cool |
| 09:13 |
mrpeters |
well crap, no dice on the alpha sort |
| 09:57 |
tsbere |
csharp: That sounds about right, but I am not looking at that part of the system right now ;) |
| 09:58 |
mrpeters |
is your concern that it would sort the group headings too, because of the way the tree gets built? |
| 09:58 |
csharp |
tsbere: understood - thanks! |
| 10:00 |
tsbere |
mrpeters: Gimme a sec to test something quick. |
| 10:01 |
tsbere |
mrpeters: Yea, a standard sort kindof ignores the "tree" part of things... |
| 10:02 |
mrpeters |
ok, i think phasefx mentioned that in the bug as a possible side effect |
| 10:03 |
mrpeters |
your sort_ident_type branch works perfect, signoff forthcoming |
| 10:03 |
* bshum |
just realized that once alpha sort for ident_type goes in, he will no longer have "Yes" (id 1) before "No" (id 2) in his patron registration. |
| 12:22 |
mrpeters |
so the error message is even less helpful in current master |
| 12:23 |
mrpeters |
im at http://pastie.org/9732735 now -- which is good, i know my window.alert will work, i just need to move it to a proper location since it shows up on a valid, and invalid au.id right now |
| 12:30 |
tsbere |
mrpeters: What interface are we aiming to return to? |
| 12:30 |
Stompro |
mrpeters: Bug 1124498 - I have this almost tested after adding in the repeat delay bit. An event is generated but stays in collected state, just need to figure out how to get it to move on from there. |
| 12:30 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 4, heat: 30) [Wishlist,In progress] https://launchpad.net/bugs/1124498 - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 12:31 |
tsbere |
mrpeters: I will point out that the "interface" you seem to want (prompt for another ID) isn't actually an "interface" at all... |
| 12:31 |
mrpeters |
tsbere: it is the "Search" > "Retreieve patron by Database ID" |
| 12:36 |
mrpeters |
so wouldnt it be acceptable to bounce you to a window.alert and the portal page for the entry point? |
| 12:36 |
mrpeters |
if invalid |
| 12:36 |
tsbere |
mrpeters: I could argue "send them to patron search instead" but the amount of work to re-make the prompt isn't worth it. :P |
| 12:37 |
mrpeters |
yeah, that would be a fair redirect too. from the way the code looks, i think this might have just been a quick add for someone who was testing something |
| 12:37 |
tsbere |
mrpeters: Basically, "send them to something else, with that something else being uniform across the board" would be fairly easy. Making it know how you got there and sending you back, including to a prompt that isn't even a page, not so much. |
| 12:38 |
tsbere |
mrpeters: Note that the functionality exists (beyond the menu item) for things like "load patron from the hold/circ/whatever" type menus. So whatever is changed needs to take those into account as well, so you can't just make it always prompt for a new ID (or barcode). |
| 12:39 |
tsbere |
Which is why it goes to the main barcode entry box, I think. >_> The menu item causing it to do that is just pre-existing functionality triggering on bad inputs. |
| 13:00 |
Stompro |
kmlussier++ for pointing out the google doc that mmorgan++ created on getting the 30 day pre expire notice working. The Processing Group Context Field needs to be blank, not set to usr. |
| 13:02 |
mrpeters |
oh, nice you guys were able to create that? |
| 13:03 |
mrpeters |
and keep it recurring? |
| 13:07 |
mmorgan |
Stompro: Glad the notes helped! |
| 13:07 |
mmorgan |
we have not yet implemented it, but it worked in testing |
| 13:08 |
mmorgan |
assuming the recurrence will work based upon the interval that now be set in the action trigger. |
| 13:10 |
kmlussier |
mmorgan: What did you set the interval at? I know Stompro asked a question back on what a good interval would be, and I suggested 30 days. |
| 13:10 |
kmlussier |
s/back/a while back |
| 13:13 |
mmorgan |
so I guess that's actually "Event Repeatabilty Delay"? |
| 15:37 |
dbwells |
mrpeters: Thanks for letting me know. I figured you were trying to learn, so I was avoiding looking too deeply into the code. Glad it got worked out. |
| 15:37 |
mrpeters |
i indeed was, i wish i could have figured it out but tsbere saw a faster way and went on and fixed it |
| 15:38 |
mrpeters |
was a good lesson all the way down through the code clear to CDBI perl stuff though |
| 15:38 |
tsbere |
Had I not stumbled on the easy, quick, and correct solution and basically put the right code in place to test if the solution would even work I would have left it more to mrpeters ;) |
| 15:38 |
dbwells |
jboyer-isl: sitem to sunit is one-to-many |
| 15:38 |
mrpeters |
i think your suggestion would have worked for, say a srfsh request of the values |
| 15:38 |
mrpeters |
but i guess that tree unsorts things |
| 17:00 |
mrpeters |
thank you, sincerely, tsbere |
| 17:01 |
tsbere |
mrpeters: (bool op) ? do this if true : do this if false |
| 17:01 |
mrpeters |
got it |
| 17:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:46 |
mrpeters |
great success! high five! tsbere++ berick++ |
| 17:46 |
mrpeters |
will push dee848f HEAD@{0}: commit: Make users_of_interest test for defined actor.usr.card values to working once my SSH keys are updated |
| 18:05 |
|
mnsri joined #evergreen |
| 18:11 |
|
nhilton joined #evergreen |
| 18:13 |
|
dreuther_ joined #evergreen |
| 01:38 |
|
letsgofightdrag1 joined #evergreen |
| 01:54 |
|
letsgofightdrag1 joined #evergreen |
| 02:21 |
|
letsgofightdrag2 joined #evergreen |
| 05:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:34 |
|
wsmoak joined #evergreen |
| 06:34 |
|
wsmoak joined #evergreen |
| 06:35 |
|
eeevil joined #evergreen |
| 11:06 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 4, heat: 30) [Wishlist,In progress] - Assigned to Josh Stompro (u-launchpad-stompro-org) |
| 11:23 |
tsbere |
mrpeters: So, I can stop all but the commonStrings ones (usually), but I at least know what causes them! |
| 11:25 |
tsbere |
mrpeters: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/stop_before_remove stops most of the popups. The last of them appears to be caused by the onunload handlers in the pages or subpages due to them trying to run before the page actually finished loading. |
| 11:46 |
mrpeters |
oh man, nice |
| 11:47 |
mrpeters |
ill test and sign-off then, thanks |
| 11:52 |
mrpeters |
was also looking at 506689 -- but should probably see if the behavior exists in the web client too -- would anyone be willing to insert a non-stock config.ident_type value to one of the web client test servers (Bill - Utility Company), perhaps to test the sort order outside of License, SSN, and Other? |
| 11:52 |
mrpeters |
bug 506689 that is |
| 11:52 |
pinesol_green |
Launchpad bug 506689 in Evergreen "Patrons > Identification Type > (Sort order)" (affected: 1, heat: 8) [Wishlist,Confirmed] https://launchpad.net/bugs/506689 |
| 12:00 |
|
sandbergja joined #evergreen |
| 12:13 |
* tsbere |
is amazed at finding patrons with a "last circ month" in 1992 in the system |
| 13:00 |
dbwells |
Seems like I've been on a bad run lately, so nice to get something working :) |
| 13:33 |
kmlussier |
dbwells: A bad run? I just figured that was the nature of coding. |
| 13:35 |
RoganH |
The fickle finger of fate foretells fortune foul and fair for all. |
| 13:41 |
jboyer-isl |
mmorgan, are you about? I've got a couple questions about your test results re: bug 1210541 |
| 13:41 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 13:43 |
jboyer-isl |
Alas. I'll look into them when I have time to put a good test together. :) |
| 13:43 |
kmlussier |
jboyer-isl: She's around, but away from her desk at the moment. |
| 13:45 |
jboyer-isl |
ok. |
| 13:46 |
mmorgan |
jboyer-isl: be back in a few minutes ... |
| 14:02 |
gsams |
jboyer-isl: In the system I'm seeing max_delay (evergreen staff client call it Max Event Validity Delay. |
| 14:03 |
gsams |
I'm not seeing a minimum, but if it acts as a minimum wait time that would be an appropriate change in my mind. |
| 14:03 |
mmorgan |
jboyer-isl: The deleted locations still appeared in the interfaces where groups and order could be configured. |
| 14:04 |
jboyer-isl |
mmorgan, Ah, ok. Bummer. Back to my testing then. |
| 14:04 |
jboyer-isl |
Thanks! |
| 14:04 |
jboyer-isl |
mmorgan++ |
| 14:04 |
tsbere |
gsams: I would pick something like 12 hours or so. Or 1 hour more than however long from midnight your a/t runners pick up on the events to go out. |
| 14:04 |
mmorgan |
No, thank YOU! |
| 14:04 |
tsbere |
er, 1 hour less |
| 14:46 |
|
_bott_1 joined #evergreen |
| 14:48 |
|
_bott_1 joined #evergreen |
| 15:25 |
mrpeters |
in register_table.tt2 I'm seeing lots of references to fmclass and fmfield -- I'm taking a leap, and assuming those refer to the fm_IDL.xml, correct? |
| 15:34 |
kmlussier |
Doh. I suppose using an LC classification scheme would make it easier to test this LC Call number fix. |
| 15:38 |
|
vlewis_ joined #evergreen |
| 15:47 |
jeff |
mrpeters: *nod* |
| 15:47 |
jeff |
mrpeters: what brings you into the user editor? |
| 16:10 |
mrpeters |
i think, from retrieve_all_config_identification_type, which i beleive is loaded into memory when you login to the staff client |
| 16:12 |
mrpeters |
and now i'm looking at Storage/CDBI/ stuff which is scaring me :P i think i'm going to dig a hole to china! |
| 16:14 |
mrpeters |
http://pastie.org/9730906 feels like the end of the line... |
| 16:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:55 |
|
akilsdonk joined #evergreen |
| 16:56 |
|
mdriscoll left #evergreen |
| 16:59 |
|
nhilton joined #evergreen |
| 09:21 |
pinesol_green |
csharp: The operation succeeded. Quote #98 added. |
| 09:22 |
jboyer-isl |
mmorgan, just wanted to let you know I haven't been ignoring your update to bug 1210541, but I've not had time to investigate/reply. |
| 09:22 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
| 09:23 |
jboyer-isl |
mmorgan++ # for testing it |
| 09:23 |
mmorgan |
jboyer-isl: no problem! I am thrilled to see progress on it! |
| 09:24 |
kmlussier |
jboyer-isl++ mmorgan++ |
| 09:24 |
Dyrcona |
If you search the logs you'll find some brief discussion of how we at MVLC solved some of our issues by increasing the limit on the number of files that our opensrf user can have. |
| 09:39 |
jeff |
> Donna appears to say that she is aware of this problem but has found a dishwasher in the White House kitchen that speaks Botok. Mr. Minaldi speaks Portuguese and so does the dishwasher. So Josh and Toby will be able to converse with Mr. Bambang via English-Portuguese-Botok-Portuguese-English. |
| 09:40 |
bshum |
jeff: That was a good episode. :P |
| 09:40 |
|
mllewellyn joined #evergreen |
| 09:40 |
jeff |
This is the scene from The West Wing that went through my mind this morning as I was describing to a co-worker how I was successful last night in initial testing with getting an outside vendor to verify patrons in our Evergreen system by emulating the III Patron API. |
| 09:42 |
bshum |
Yeah, that sounds about right. |
| 09:48 |
jeff |
There was a moment the other day where I thought the "Why don't we just speak in English" would have been more appropriate, but no. |
| 09:51 |
csharp |
The_West_Wing++ |
| 10:36 |
jeff |
But I think the long term goal would still be to use technologies that are better with regard to being 1) less niche, 2) better experience for patrons and 3) not gaping privacy/security holes |
| 10:37 |
kmlussier |
Dyrcona: Do you still have the fine generator running overnight on your dev server? |
| 10:37 |
Dyrcona |
It should be. |
| 10:37 |
kmlussier |
Dyrcona: OK, I just wanted to check before I got to far in my testing. Thanks! :) |
| 10:37 |
jeff |
the "other things" for the current reality would include divorcing SIP2 credentials from ILS credentials, giving the ability to filter or limit SIP messages and their responses -- essentially a field-level fine-grained control over what a given SIP client can see and do. |
| 10:37 |
kmlussier |
s/to/too |
| 10:38 |
jeff |
that second bit could either be in SIPServer (with or without need for driver support -- probably depending on where you wanted to do your config) or via a SIP proxy, which would be a bit more complex but have wider benefit to those not running SIPServer |
| 11:07 |
Bmagic |
mmorgan: yes..... |
| 11:08 |
bshum |
Bmagic: The thing that bothers me right now is that when I install a fresh Evergreen master / OpenSRF master, I don't see this bug. So it seems sporadic somehow. |
| 11:08 |
bshum |
Meaning not production data, using concerto or whatnot |
| 11:08 |
mmorgan |
we were testing some code and had made changes to the fm_idl. |
| 11:08 |
kmlussier |
Odd, I just tried the Fast Item Add from the MARC editor and had no problems. |
| 11:08 |
mmorgan |
then we could not save changes to items. We reverted the idl and it fixed the problem. |
| 11:08 |
Bmagic |
kmlussier: are you on 2.7+ ? and OpenSRF 2.4+ ? |
| 11:22 |
jeff |
bshum: wait until it's likely everyone's restarted their staff clients. :-) |
| 11:22 |
bshum |
mllewellyn will definitely be happier ;) |
| 11:22 |
bshum |
jeff: Gah, you're right |
| 11:23 |
* kmlussier |
returns to negative balance testing but thanks Bmagic for the distraction. :) |
| 11:23 |
Bmagic |
The stock js files have the path to the server with the generic /server/ and autogen replaces that with whatever you compled with right? |
| 11:23 |
* bshum |
will wait for the weekend then. |
| 11:23 |
mllewellyn |
mllewellyn will be much happier |
| 09:03 |
csharp |
btw, I'm one who would volunteer to help new devs get things up and running, for the record |
| 09:03 |
wsmoak |
I don’t even know how much it would cost (or how it works) but what about some sort of image that runs on Amazon or Google’s things? |
| 09:04 |
wsmoak |
I’d be willing to pay for the server time (vs. running my own server here, which is probably what it would take…) |
| 09:04 |
csharp |
you could definitely run a test server in the cloud, sure |
| 09:04 |
wsmoak |
but I need my very own instance to break and then press a button and re-make |
| 09:05 |
RoganH |
There are a couple of tools floating around for making VMs that you could do development on. |
| 09:05 |
csharp |
you would need maybe 8 - 16 GB of storage, minimum 4 GB RAM, and 2 - 4 processor cords |
| 09:05 |
mrpeters |
VM's and snapshots are the easy reset button :P |
| 09:05 |
RoganH |
csharp: I thought you were going to break out into 80s power cords there for a minute. :) |
| 09:06 |
RoganH |
berick's scripts pop to mind which I've used |
| 09:06 |
RoganH |
tsbere also has a method that I've heard good things about though I haven't tried it myself. I know kmlussier uses it for building VMs for bug testing. |
| 09:06 |
Stompro |
I really liked the Evergreen VM that used to be available.. but I realize that it takes a bit of work to keep it up to date. |
| 09:07 |
wsmoak |
it needs to not be a separate thing that only new devs ever use … or it won’t get maintained |
| 09:07 |
mrpeters |
yeah the vm thing never worked well |
| 09:12 |
|
maryj joined #evergreen |
| 09:12 |
wsmoak |
basically, I do not want to be a sysadmin. I *can* do those things, I have done, but it’s not what I want to spend my time on these days. |
| 09:12 |
RoganH |
Installing Evergreen really isn't that hard, it's just very time consuming and methodical, hence the tools to speed it up. |
| 09:12 |
RoganH |
Note that these are for doing bug testing and development, not building a production environment. |
| 09:12 |
mrpeters |
i'll give you time consuming for sure |
| 09:13 |
mrpeters |
but, to fix bugs, you should be capable of installing OpenSRF/Evergreen |
| 09:13 |
RoganH |
I agree. |
| 09:13 |
mrpeters |
how are you going to fix something you break if you aren't able to do a scratch install, you know? |
| 09:13 |
Stompro |
I hate editing the xml files... the fact that sometimes it's <password> and sometimes its <passwd>. And dealing with all the ejabberd accounts. |
| 09:14 |
mrpeters |
for me, personally, the solution to the time consuming bit is using VMWare (though Virtualbox would work fine too) and using snapshots |
| 09:14 |
RoganH |
I was trying to point out tools that can help with blasting and rebuilding a test build of Evergreen, not saying that they void the need to have the underlying skills. |
| 09:14 |
wsmoak |
:::shrug::: I don’t really want to fix bugs. I want to play with it and write against the api and see how it all works and *then* maybe get more involved. |
| 09:15 |
mrpeters |
no, I agree with you RoganH. Once you can perform the install once, no need to repeat it over and over again (though, it does become like muscle memory to install Evergreen eventually haha) |
| 09:15 |
RoganH |
using Virtual Box snapshots can work most of the time as well though I'd argue sometimes it's good to just be able to do a quick new build from git |
| 09:21 |
wsmoak |
… but that leans a lot on Java’s built-in stuff I know, with the ability to swap out data sources easily |
| 09:21 |
RoganH |
If you're running OSX virtual box is your friend. |
| 09:21 |
mrpeters |
heck yeah it is |
| 09:21 |
csharp |
wsmoak: we do have a test dataset (not automatically installed by the .deb package, fwiw) |
| 09:21 |
RoganH |
You can pay for VMWare (I used to) but Virtual Box has gotten so good in the last few years. |
| 09:22 |
mrpeters |
when i was at ISL my "master" server for submitting new patches, development, etc. was just a virtualbox VM on their OS X server |
| 09:22 |
mrpeters |
csharp: we could make the test data load SO easy. There is a flag now for eg_db_config to load all of that |
| 09:22 |
mrpeters |
i discovered it monday |
| 09:23 |
mrpeters |
--load_all_test or something |
| 09:23 |
mrpeters |
we could add that to our debs pretty easily i think |
| 09:23 |
csharp |
yep |
| 09:24 |
mrpeters |
maybe have it set up so you can do an apt-get install evergreen-ils and apt-get install evergreen-ils-populateddb |
| 09:24 |
csharp |
I wonder if it should be a separate deb, though |
| 10:00 |
jboyer-isl |
mrpeters, Probably a URI if you want to be picky, I can never remember the difference |
| 10:00 |
mrpeters |
heh yeah |
| 10:03 |
Stompro |
Does anyone have a "New Patron Welcome Email" notice that they use? We currently try to email a new customer right away, so that if their email is bad the staff have a chance to fix it while the customer might still be in the building. I just need to figure out if that is possible with action triggers. |
| 10:04 |
mrpeters |
so, if gpls were to host a deb of the current "stable" release with and without test data would the community advertise that as a "quick start" or would that still meet resistance because it doesn't account for installing the software, and could **potentially** cause someone to accidentally upgrade the package when they didn't intend to |
| 10:06 |
Stompro |
mrpeters: I'm pretty new, but I would support that and I would help add it to the community install docs. |
| 10:06 |
kmlussier |
berick++ |
| 10:07 |
Stompro |
mrpeters: would it be Ubuntu only or could Wheezy and Jessie users make use of it? |
| 10:08 |
mrpeters |
we would have to build seperate debs for those, i think |
| 10:08 |
mrpeters |
debian has some slightly different install steps |
| 10:08 |
bshum |
mrpeters: I think that's an interesting offer. Though I'm always curious to see the deb building process you guys have come up with in action. |
| 10:08 |
mrpeters |
I could make a demo video |
| 10:09 |
mrpeters |
i just hate hearing my own voice narrate it....and today is NOT the day to do that....60 degrees to 22 degrees in 12 hours did not help my throat |
| 10:11 |
mrpeters |
there is a little work done (Andy Witter usually handles it) to build any new debs for things that would normally get installed from source (spidermonkey, etc.) but if those don't change much from version to version, its really just grab the tarball and put it in a certain location and then run a script |
| 10:11 |
mrpeters |
you can pick "cluster" or "single server" |
| 10:11 |
mrpeters |
for the repo, its single server |
| 10:12 |
mrpeters |
only half of that I don't have a lot of knowledge on yet is the actual apt archive |
| 10:12 |
mrpeters |
not sure where Andy sticks the built debs up to update the repo |
| 10:13 |
mrpeters |
i just tell him hey, i built the 2.7.1a debs can you update the repo and link him my deb |
| 10:14 |
mrpeters |
one thing that would be cool, and im not sure if it could be done, is to have ALL of the old debs still there too, so you could do say, apt-get install evergreen-ils-2.0.4 and get the 2.0.4 build installed |
| 10:14 |
mrpeters |
wouldn't see many reasons to do that, other than nostalgia or testing "did this act differently before?" but could be handy |
| 10:17 |
bshum |
With deb files, wouldn't the version be part of the package name though? |
| 10:17 |
bshum |
Usually |
| 10:18 |
mrpeters |
yeah, i think traditionally it is |
| 12:43 |
tsbere |
kmlussier: I would argue then that the setting is horribly mis-named, then, because it isn't acting like a copy. |
| 12:44 |
* kmlussier |
notes that all of the examples in the docs at http://docs.evergreen-ils.org/2.7/_cataloging_electronic_resources_8201_8212_8201_finding_them_in_catalog_searches.html#_adding_a_located_uri_to_the_record were working as described back in the summer. |
| 12:44 |
jeff |
are they no longer working as described? |
| 12:44 |
kmlussier |
tsbere: If the subfield 9 is set to the consortium without the setting enabled, then it will show up in searches all the way down the org tree. But if it's set at a system or branch level, it only travels down, not up. |
| 12:45 |
kmlussier |
jeff: I believe they are. I haven't tested it since then. |
| 12:45 |
kmlussier |
tsbere: If you enable the setting, then the resource shows up both up and down the org tree. So if it's owned by a system and you search the consortium, it still shows up. Like copies do. |
| 12:45 |
tsbere |
kmlussier: As far as I know, copies only travel "up", not "down", so if the setting makes them travel *both* ways then URIs aren't acting as copies. |
| 12:46 |
tsbere |
kmlussier: Which would make the setting's name horribly wrong. :P |
| 12:46 |
kmlussier |
tsbere: If your search is scoped to the consortium, you don't see copies owned by a branch? |
| 12:52 |
tsbere |
jeff: I seem to recall it only shows up when scoped to the top of the tree. |
| 12:52 |
* tsbere |
has done stuff like that before |
| 12:54 |
kmlussier |
I guess the specific name of the settings was used to show how enabling it differs from default behavior. The default behavior is what makes the electronic resource show up in searches higher up the org tree. Enabling the settings is what allows it to travel down, as copies do. |
| 12:56 |
tsbere |
kmlussier: My (current) point being that the name and description *don't match what it does* - Copies by default travel "up" the tree, URIs by default travel "down" the tree, that option tells URIs to travel "up AND down" the tree. That is not acting like copies. That is acting like a combination of copies and URIs at the same time. |
| 12:58 |
* tsbere |
is assuming that kmlussier's assertion about things is true, BTW, and has not tested or dug the actual code up at this point |
| 13:00 |
dbwells |
I agree with tsbere that the setting doesn't really do what it claims. Anyone interested in all the various cans of worms should check out ldw's bug #1353643. I suspect the fallout from that will clarify the original setting as well. |
| 13:00 |
pinesol_green |
Launchpad bug 1353643 in Evergreen "URI $9 displayes too many links in TPAC" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1353643 |
| 13:05 |
* eeevil |
is running to a doctor's appointment (already late) but the setting is to make URIs act like copies /in that/ they scope "down". it doesn't remove the "up" scoping, though. electronic resource limiting is about modeling access rights, where the uri owner (and it's subordinates) should have access |
| 14:24 |
kmlussier |
bug 1171984 |
| 14:24 |
pinesol_green |
Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" (affected: 4, heat: 18) [Wishlist,Triaged] https://launchpad.net/bugs/1171984 - Assigned to Liam Whalen (whalen-ld) |
| 14:24 |
kakes |
kmlussier: who do you think is working on the overlay? |
| 14:25 |
kmlussier |
Are there still issues for the LC Call number group once dbwells's code is tested and merged? |
| 14:25 |
Stompro |
gmcharlt: Thanks for reviewing and committing the KPAC setup docs. gmcharlt++ |
| 14:25 |
kmlussier |
Sorry, that's the next agenda item. I withdraw the question. |
| 14:25 |
dbs |
#info dbs = Dan Scott, Laurentian University (with coffee in hand, finally) |
| 14:32 |
yboston |
yes |
| 14:32 |
yboston |
I finally put in a bug for issues searching LC calnumbers in OPAC numeric searches; bug 1389403 |
| 14:32 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:32 |
yboston |
I then added a link inside the bug to some test code that Dan Wells wrote to address the issue. I saw that Kathy tried testing that code during the EG bug squashing day. |
| 14:32 |
yboston |
I still need to query the community to see what other LC call number issues need to be addressed |
| 14:33 |
kmlussier |
I still owe a response to dbwells regarding what we're seeing in the logs. |
| 14:33 |
yboston |
and I made a basic wiki page for this group too |
| 14:33 |
kmlussier |
I think I sent out a query to the Evergreen community. |
| 14:36 |
pinesol_green |
Launchpad bug 1352542 in Evergreen "Printing: LC Call number formatting (2.5.2)" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1352542 |
| 14:37 |
dbs |
dbwells: are we normalizing the incoming call number label? /me isn't seeing that immediately in supercat |
| 14:38 |
remingtron |
dbwells is in a meeting at the moment |
| 14:38 |
yboston |
since we have one definite open bug, and one bug that has a fix awaiting more testing, we can keep the group open for now |
| 14:38 |
kmlussier |
DonB: Since you semi-volunteered up above, is this something you want to work through. At this time, I'm thinking it's primarily about identifying specific issues that are still out there. |
| 14:39 |
yboston |
I am sure there are other bugs I could report if I talk to the cataloger here, though she is on maternity leave right now |
| 14:39 |
* dbs |
sees that that's what the patch from dbwells is trying to do; seems reasonable |
| 14:42 |
pinesol_green |
[evergreen|alzr] LP#1207529: Add /openils assumption note - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e38ec30> |
| 14:42 |
yboston |
you being Kathy |
| 14:42 |
yboston |
we were all new like you once |
| 14:43 |
kmlussier |
#action kmlussier to post testing feedback for dbwells on bug 1389403 |
| 14:43 |
pinesol_green |
Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403 |
| 14:43 |
kmlussier |
Got it. |
| 14:43 |
kmlussier |
Those are all the sub-groups then. |
| 16:01 |
dbs |
jihpringle: cool, thanks -- that's a pretty impressive set |
| 16:06 |
|
jwoodard joined #evergreen |
| 16:33 |
|
mdriscoll left #evergreen |
| 17:05 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
|
mmorgan left #evergreen |
| 17:20 |
|
buzzy joined #evergreen |
| 18:01 |
|
kmlussier joined #evergreen |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:36 |
|
wsmoak joined #evergreen |
| 06:37 |
|
eeevil joined #evergreen |
| 06:37 |
|
mtate joined #evergreen |
| 08:28 |
|
mdriscoll1 joined #evergreen |
| 08:30 |
|
graced joined #evergreen |
| 08:35 |
|
Stompro joined #evergreen |
| 08:37 |
bshum |
Stompro: I'm generally +1 to using the PostgreSQL apt repo and suggesting others to use newer PostgreSQL versions as long as the community users have had enough time to check things are working well. |
| 08:37 |
bshum |
The trick is just getting enough testing done for all the combinations. |
| 08:39 |
bshum |
That said, adding an extra repo might be more work than needed for some folks if the main repository for a given distribution already contains a reasonably new enough version of PostgreSQL. |
| 08:39 |
* bshum |
is of many minds on much of this. |
| 08:42 |
bshum |
Might be a good question to ask during the developer meeting this afternoon... |
| 08:44 |
Stompro |
bshum: Thanks, I'll work on something for the upgrade/install docs. |
| 08:44 |
|
artunit joined #evergreen |
| 08:45 |
|
mmorgan1 left #evergreen |
| 11:34 |
bshum |
Aha, okay |
| 11:34 |
bshum |
So that's why we haven't noticed that issue yet. |
| 11:34 |
bshum |
We're still doing it the old way |
| 11:34 |
mrpeters |
yeah, they both work well, im just more comfortable with this method |
| 11:35 |
mrpeters |
you can get some MONSTER xsl sheets when you're doing test's all throughout them |
| 11:35 |
jboyer-isl |
Ah. mrpeters just wrap that circ.target_copy.call_number.label in helpers.escape_xml() and it will be fine. (but the old notices will stay busted.) |
| 11:35 |
jboyer-isl |
In the A/T template, that is. |
| 11:35 |
mrpeters |
jboyer-isl: oh, sweet...i can do that |
| 14:09 |
bshum |
I know I need more time to digest things on that |
| 14:09 |
* dbs |
disappears to do some hardware stuff, grr |
| 14:10 |
bshum |
Let's defer on that subject till we get some more time to read through and respond to the latest? |
| 14:10 |
kmlussier |
I plan to test it soon, but I haven't had a chance look closely enough to come up with any questions yet. |
| 14:10 |
bshum |
Though I think for the action item, it's settled since it looks like dbwells did update the bug with new details. |
| 14:10 |
bshum |
Next past item |
| 14:10 |
bshum |
#info gmcharlt to release OpenSRF 2.4 when ready |
| 14:44 |
Dyrcona |
It points at something of mine that no longer exists. |
| 14:44 |
kmlussier |
The OPW wiki isn't an ideal place to share these scripts. If we think they might be useful to people, then maybe adding them to the install docs or the readme, as dbs previously suggested, is a good idea. |
| 14:45 |
* Dyrcona |
puts curmudgeon hat on. |
| 14:45 |
Dyrcona |
I think the current installation procedure is a good test for potential developers. |
| 14:46 |
Dyrcona |
If you can't follow a README, do a manuals installation, and troubleshoot issues, you're going to have a very hard time later figuring out why your code broke something. |
| 14:46 |
kmlussier |
Dyrcona: The curmudgeon hat suits you. :) |
| 14:47 |
Stompro |
Dyrcona: I understand your view, but if people give up during the install phase, then there is never the possibility of them contributing at all. |
| 15:10 |
|
Christineb left #evergreen |
| 15:15 |
kmlussier |
krvmga: When I look at http://bark.cwmars.org/eg/opac/record/3254422?query=frozen%20-kjklfjdkaljfd;qtype=title;fg%3Aformat_filters=10;locg=1;expand=marchtml#marchtml, I still see a 246 with Disney Frozen |
| 15:16 |
krvmga |
kmlussier: yes, jschrader added other 246 fields without "Disney" in them |
| 15:17 |
kmlussier |
I would leave one 246 there that just says Frozen as a better test. |
| 15:18 |
bshum |
parts++ |
| 15:18 |
kmlussier |
Heh...I was going to wait until you were on the road to do that. |
| 15:18 |
krvmga |
kmlussier: she's not in the office today. when i see her next, we'll try and see. |
| 16:04 |
|
nhilton joined #evergreen |
| 16:34 |
|
nhilton_ joined #evergreen |
| 16:50 |
|
nhilton joined #evergreen |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:00 |
|
mdriscoll1 left #evergreen |
| 17:02 |
|
mtcarlson joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 00:39 |
|
artunit_ joined #evergreen |
| 02:15 |
|
eby_ joined #evergreen |
| 02:38 |
|
rangi` joined #evergreen |
| 04:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:35 |
|
eeevil joined #evergreen |
| 06:48 |
|
wsmoak joined #evergreen |
| 07:39 |
|
sarabee joined #evergreen |
| 08:55 |
csharp |
yes |
| 08:56 |
csharp |
oops - "yes" was meant for another window ;-) |
| 09:02 |
|
ericar_ joined #evergreen |
| 09:13 |
remingtron |
super old bug 921142 (heat 44!) ready for testing/pushing |
| 09:13 |
pinesol_green |
Launchpad bug 921142 in Evergreen 2.4 "Fixed fields are required to have all positions entered. " (affected: 6, heat: 44) [Medium,Confirmed] https://launchpad.net/bugs/921142 |
| 09:22 |
|
mrpeters joined #evergreen |
| 09:23 |
jeff |
next time, on "this old bug" |
| 11:02 |
|
maryj joined #evergreen |
| 12:41 |
|
nhilton joined #evergreen |
| 12:43 |
|
mrpeters joined #evergreen |
| 13:13 |
csharp |
did anyone ever mirror the old SVN repo site? I'm wondering if some old PINES development is still recoverable |
| 13:15 |
csharp |
specifically, I'm looking for the bad debt interface that was briefly alive on our test server c. 2009 |
| 13:28 |
bshum |
csharp: Yeah I think MVLC has a mirror of the SVN |
| 13:28 |
bshum |
Or a converted git copy anyways |
| 13:28 |
bshum |
But I'm not sure |
| 13:45 |
csharp |
I'm sure I just have a simple config option wrong |
| 13:45 |
csharp |
and I'm doing copy paste coding right now without really knowing the knobs and switches for apache/mod_perl |
| 13:52 |
eeevil |
csharp: that looks fine |
| 13:52 |
csharp |
ok thanks |
| 13:56 |
|
Stompro_home joined #evergreen |
| 14:13 |
csharp |
ah - that's interesting - no interface loads, but if I add anything to the url (e.g. https://test-brick01-head/baddebt/test), I get a downloaded CSV file that says Upload Failure |
| 14:14 |
csharp |
I don't understand enough about perl/CGI to know how to get the show_template subroutine to work |
| 14:21 |
csharp |
okay, so I can see that it at least is running the handler subroutine, but I don't see where show_template is invoked in that |
| 14:23 |
eeevil |
csharp: it seems it's not. http://pastie.org/9712488 should do it. I'll look at the git history right quick |
| 14:25 |
csharp |
eeevil++ # that did it |
| 14:25 |
eeevil |
cool. if you bug it I'll toss up a branch, eh? |
| 14:27 |
csharp |
sure thing |
| 14:28 |
csharp |
well, after I figure out why my test.csv file resulted in "Upload Failure" ;-) |
| 14:28 |
csharp |
ah - yeah, we're suffering bitrot here: Method [open-ils.cstore.direct.money.billable_xact.retrieve] not found for service open-ils.cstore |
| 14:29 |
csharp |
I'll look into it, now that I've got the scent ;-) |
| 14:31 |
jeff |
downtrodden and bitrotten |
| 14:32 |
eeevil |
ah, well, that'd be ungood to continue using in any case. it needs to be moved to pcrud re "no more private services in mod_perl" (but that's a broader project which will likely include IDL changes) |
| 14:32 |
csharp |
oh - ok |
| 15:21 |
hopkinsju |
Pssh. More like Google Earth |
| 15:21 |
bshum |
If my client is any indication |
| 15:21 |
dbs |
csharp: mebbe! |
| 15:22 |
csharp |
I have a crazy ticket in from one of our libraries where the production client is auto-updating itself to the test client version |
| 15:22 |
bshum |
I think there are some fun color/font addons you can use from Firefox to make your staff client more interesting looking :) |
| 15:23 |
csharp |
they swear that they aren't caching anything, but it's happening now when the test server is completely down |
| 15:23 |
dbs |
"evergreen -ProfileManager" to create a new profile maybe |
| 15:23 |
bshum |
It could be a bad upgrade path |
| 15:23 |
bshum |
Or cross-shared hostname/versions between your test and production environments. |
| 15:23 |
csharp |
I've tried to recreate the issue with no success |
| 15:23 |
bshum |
Like go to the test server to get your updates |
| 15:23 |
hopkinsju |
Do you have the test client build on the production server by mistake? |
| 15:23 |
csharp |
autoupdate host on the production clients is next.gapines.org... oh |
| 15:23 |
bshum |
Or like the test server client was installed with the same path as production |
| 15:24 |
csharp |
s/production clients/test clients/g |
| 15:24 |
csharp |
I wonder if they've been using test clients from last year's upgrade with the next.gapines.org path this whole time |
| 15:25 |
bshum |
Could be |
| 15:25 |
csharp |
huh - that's a distinct possibility |
| 15:25 |
csharp |
I only have random screenshots |
| 15:25 |
* bshum |
loves the time that a library was using the test server hostname as production for a few days before we noticed things seemed... wrong. |
| 15:26 |
csharp |
OMG, that's happened to us too |
| 15:26 |
bshum |
That's why I have completely different stamping now for our test group and production groups. |
| 15:26 |
csharp |
I thought about that, but I didn't want to create a stumbling block for testing |
| 15:26 |
* bshum |
wants more Evergreen staff client logo colors. |
| 15:26 |
bshum |
Red and orange/yellow aren't enough! |
| 15:27 |
bshum |
But yeah |
| 15:27 |
bshum |
I use rigbeta for my test server clients |
| 15:27 |
bshum |
And rigrelease for my regular production ones |
| 15:28 |
bshum |
So any red icon'd staff client for us is a test one |
| 15:28 |
bshum |
And orange/yellow = production |
| 15:28 |
bshum |
But as you say, we don't have nearly as much end-user library testing as we'd perhaps wish for. |
| 15:29 |
csharp |
we use the red icon for testing too |
| 15:30 |
jeff |
one of our "test before upgrade" setups had a garish yellow background in many staff (especially circ-related) interfaces to avoid the "oops, did production work in test env" situation. |
| 15:30 |
jeff |
but it would be nice to have support for that baked in, maybe as a new feature in the web client. |
| 15:31 |
jeff |
pre-login/post-login message / banner / popup, banner across the entire top of the page, or some combination of those things. |
| 15:33 |
bshum |
Hmm |
| 15:33 |
bshum |
I don't see why not |
| 15:35 |
csharp |
we used to use the "reddish" opac theme on our test server, but that didn't help from the client |
| 15:35 |
bshum |
Oh that's a throwback to the old days :) |
| 15:35 |
bshum |
I guess those files still exist. We need to finish ripping all that out sometime... |
| 15:36 |
csharp |
so theoretically, if the client has next.gapines.org in its autoupdate.js file, it might grab those update files even if it's logging into gapines.org? |
| 15:37 |
csharp |
well, the next server hasn't been updated since last year |
| 15:37 |
bshum |
Since that's where it'd check towards |
| 15:37 |
bshum |
Not the hostname you enter |
| 15:37 |
csharp |
right |
| 15:37 |
csharp |
okay - this is making more sense now |
| 15:39 |
csharp |
it never occurred to me that staff would be using test clients in production without realizing it |
| 15:39 |
csharp |
but we've never disallowed them in production either (via symlink) |
| 15:40 |
bshum |
Indeed. |
| 16:33 |
* jeff |
laughs at himself |
| 16:37 |
|
kmlussier joined #evergreen |
| 16:38 |
kmlussier |
dbwells++ |
| 16:39 |
kmlussier |
I'll try to fit in testing the new Negative Balance branch as soon as I can. |
| 16:39 |
* kmlussier |
disappears again. |
| 16:43 |
jeff |
mumble mumble billing mumble mumble |
| 16:43 |
jeff |
mous and mus can differ when there are closed xacts with non-zero balance_owed. |
| 16:44 |
jeff |
and the number of users where SUM(mmbxs.balance_owed) <> mous.balance_owed is different from the number of distinct users where mmbxs.xact_finish IS NOT NULL AND mmbxs.balance_owed <> 0 |
