| 01:32 |
|
Mark__T joined #evergreen |
| 01:35 |
|
gdunbar joined #evergreen |
| 05:11 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:09 |
|
rlefaive joined #evergreen |
| 07:53 |
kmlussier |
Looks like that test has been failing since Saturday. |
| 08:05 |
jeff |
The have and want are equivalent, but the want has more explicit namespaces. |
| 08:05 |
jeff |
either that or i just compared the same thing. |
| 08:08 |
jeff |
Nope, I compared correctly. :-) |
| 08:08 |
|
mrpeters joined #evergreen |
| 08:08 |
jeff |
Also worth noting is that the test script isn't excaping XML output from tests. |
| 08:12 |
|
ericar joined #evergreen |
| 08:15 |
|
rjackson_isl joined #evergreen |
| 08:27 |
|
ericar joined #evergreen |
| 08:35 |
jeff |
"excaping"? oof. |
| 08:39 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:46 |
Dyrcona |
<sarcasm>Yay for smart quotes in MARC records!</sarcasm> |
| 09:01 |
phasefx |
csharp: confirmed |
| 09:07 |
Dyrcona |
I don't think I could get the z39.50 import to work the last time I tried, but that was long before the RC release. |
| 09:08 |
Dyrcona |
phasefx gmcharlt miker: If you'd like the latest sprint2 changes in before 2.9.0 final, that can be arranged if you point me at a branch before Monday. |
| 09:09 |
* Dyrcona |
runs off to finish setting up NCIPServer in production and then to test half-open connection fixes. |
| 09:09 |
gmcharlt |
Dyrcona: thanks, that is very generous of you! |
| 09:09 |
csharp |
phasefx: thanks |
| 09:09 |
gmcharlt |
we'll get a branch put together |
| 09:10 |
csharp |
that would totally rock |
| 09:11 |
csharp |
PINES would love to be able to offer a mostly-working web client to libraries willing to be on a "live beta" before next summer reading |
| 09:11 |
gmcharlt |
csharp: does it work for LC? |
| 09:11 |
csharp |
didn't check - I'll do so now |
| 09:12 |
csharp |
gmcharlt: same behavior |
| 09:12 |
csharp |
if cache-clearing or anything like that needs to happen between tests, just let me know ;-) |
| 09:13 |
|
yboston joined #evergreen |
| 09:17 |
|
rlefaive joined #evergreen |
| 09:19 |
|
rlefaive joined #evergreen |
| 09:23 |
gmcharlt |
csharp: so, I've pushed a fix to the collab/gmcharlt/webstaff-sprint branch |
| 09:23 |
gmcharlt |
now that sprint2 is about to enter the formal testing phase, webby itself will get updated at 5 p.m. every day |
| 09:24 |
gmcharlt |
(though there may be occassional earlier updates) |
| 09:38 |
miker |
I'm happy to drop that update in place for testing |
| 09:39 |
miker |
(but 5pm is the only guarranteed update time for webby going forward) |
| 09:39 |
miker |
as gmcharlt says |
| 09:39 |
|
collum joined #evergreen |
| 09:46 |
bshum |
kmlussier: Looking over at bug 1494427 and I wonder if we shouldn't edit bills2.js and remove the var entirely for staff.patron.bills.handle_refund.confirm_message |
| 09:46 |
pinesol_green |
Launchpad bug 1494427 in Evergreen "Staff client refund option generates an error" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1494427 |
| 09:52 |
phasefx |
I'll do it |
| 09:52 |
Dyrcona |
Thanks. |
| 09:52 |
kmlussier |
bshum: I could create a branch sometime today that does that, though. |
| 09:57 |
csharp |
miker: if you go ahead and put the change in, I'll test it immediately |
| 09:57 |
csharp |
gmcharlt: thanks! |
| 09:57 |
miker |
csharp: did so right after I said I wouldn't mind ;) |
| 09:58 |
csharp |
:-) cool - I'll do so now |
| 09:58 |
miker |
status: WORKSFORME, btw |
| 09:59 |
csharp |
I can confirm the editor is loading now when importing from OCLC |
| 09:59 |
gmcharlt |
groovy |
| 10:05 |
Dyrcona |
csharp++ gmcharlt++ |
| 10:08 |
Dyrcona |
Heh. So to test something on my dev machine, I process a hold that is in transit for me and then check the book out to myself. |
| 10:08 |
Dyrcona |
Less than 5 minutes later, a co-worker shows up at my office with the book in hand. |
| 10:17 |
gmcharlt |
heh |
| 10:22 |
remingtron |
Anyone know what happens if you place a hold on a multi-part record and keep "All Parts" selected? |
| 14:30 |
kmlussier |
Dyrcona: Thank you! |
| 14:31 |
Dyrcona |
Speaking of learning something new/first times: I used git add --patch for the first time today to break my working changes into 3 separate commits. |
| 14:36 |
jeff |
my fingers default to git add -p |
| 14:38 |
kmlussier |
dbwells: I'm pretty sure the adjust permission didn't get in. I did some testing last night, and removing the void permission prevented the account from adjusting a bill to zero. |
| 14:40 |
dbwells |
kmlussier: Thanks for letting me know. I'm itching to get in there again and see what's what, but I've got other obligations today. Monday looks more hopeful, or maybe over the weekend if I can't sleep :) |
| 14:42 |
Stompro |
remingtron++ that was an epic doc update. |
| 14:44 |
|
gdunbar joined #evergreen |
| 15:22 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 15:22 |
Bmagic |
yep |
| 15:22 |
Bmagic |
this has crossed my mind |
| 15:22 |
mmorgan |
I haven't been able to complete testing successfully on kmlussier's servers. |
| 15:22 |
Bmagic |
I dont see any lines here that affect checkin |
| 15:24 |
mmorgan |
So you checkin, and that voids the Lost charge, right? |
| 15:25 |
Bmagic |
yes it does void the lost charge |
| 01:03 |
|
Mark__T joined #evergreen |
| 02:25 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 03:57 |
|
gsams joined #evergreen |
| 04:11 |
|
eady joined #evergreen |
| 05:12 |
|
gsams joined #evergreen |
| 10:36 |
|
jvwoolf joined #evergreen |
| 10:38 |
|
dMiller_ joined #evergreen |
| 10:38 |
|
RoganH joined #evergreen |
| 10:38 |
maryj |
kmlussier: Trying to set things up in the staff client so aspects of the OPAC can be tested for documentation purposes. Is it okay if I modify barcodes for items within the mnlc 2.9.rc test server? |
| 10:39 |
kmlussier |
maryj: That's not a problem. It |
| 10:39 |
kmlussier |
It's there to be used and abused however you see fit. |
| 10:40 |
maryj |
Whoooo! I mean - with great power comes great responsibility. ;) Thanks, kmussier |
| 11:40 |
mmorgan |
Stompro: Sorry, I meant the latter. Events will get created without the filter, but won't be limited to the owning library. |
| 11:41 |
* mmorgan |
is hoping someone will correct any misconceptions. |
| 11:41 |
pinesol_green |
[evergreen|Yamil Suarez] Docs: remove TPAC based Searching of Authorities section - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2392315> |
| 11:44 |
Stompro |
mmorgan++ thanks, I'll test it out, eventually, and let you know if that isn't how it works. |
| 11:46 |
mmorgan |
Stompro++ |
| 11:46 |
* mmorgan |
also planned to test it out eventually. Unfortunately, "eventually" hasn't happened yet ;-) |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:21 |
pinesol_green |
[evergreen|Yamil Suarez] Docs: add info on disabled Google Analytics in staff client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cae3146> |
| 12:23 |
|
gdunbar joined #evergreen |
| 13:05 |
maryj |
remingtron, yboston, jvwoolf: Do we need screenshots of "Account Expiration Date in my account" then? The explaination seemed straightforward enough. |
| 13:05 |
maryj |
Same for "Column sorting in circulation screens " |
| 13:07 |
yboston |
maryj: when you say the explination is straightforward enough, do you mean in the release or do you mean the part of the offical docs that cover the UI elemnts/fetures of that part of EG? |
| 13:07 |
maryj |
jvwoolf: I looked at it and tested it to see if the written description matched the features on-screen, and if any needed details were needed for the 2.9 documentation. |
| 13:08 |
yboston |
maryj: so far you are mostly making sense to me, specially about "Column sorting in circulation screens", but I want to clear soemthing up |
| 13:08 |
maryj |
What's in the release notes for those two features "Account Expiration Date in My Account" and "Column sorting in circulation screens" would work for documentation for 2.9. I realize my misunderstanding of the linked documents on that wiki page now. |
| 13:08 |
maryj |
yboston: I'm all ears |
| 13:41 |
kmlussier |
Not only is DIG hack-a-way day a great way to get new docs, but it's also a good opportunity to get another round of bug checking done before the full release is out. |
| 13:41 |
* kmlussier |
just found a bug. :) |
| 13:53 |
* maryj |
may have just found a bug also |
| 13:55 |
bshum |
Nobody seems to kick the tires on the alpha/beta/rc testing like we used to. |
| 13:55 |
kmlussier |
bshum: Speak for yourself. I still kick tires. :) |
| 13:56 |
maryj |
kmlussier: there isn't a library setting for the test server to activate the holds, is there? Inability to place holds in staff client and in OPAC. No error messages, just reloads the screen. |
| 13:56 |
maryj |
*reloads the holds screen |
| 13:56 |
bshum |
maryj: Make sure you have a good pickup location selected |
| 13:56 |
kmlussier |
Are you logged in as admin? |
| 13:57 |
bshum |
That's a common bug that happens with the admin account. |
| 14:01 |
maryj |
kmlussier++ |
| 14:17 |
pinesol_green |
[evergreen|Lynn Floyd] Docs: Link in catalog to clear Added Content cache - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8626fb0> |
| 14:22 |
* jeff |
eyes OpenILS::SIP::clean_text |
| 14:24 |
kmlussier |
Huh...when I tested the last piece of the negative billing code, I could have sworn that "Adjust to zero" option replaced the void option. But the void option is still there. |
| 14:24 |
kmlussier |
And is producing negative balances when I said to prohibit them. :( |
| 14:26 |
kmlussier |
I must have been in a rush that day. |
| 14:27 |
|
akilsdonk_ joined #evergreen |
| 14:27 |
remingtron |
kmlussier: seems like it's not working right? you could try running the tests |
| 14:27 |
kmlussier |
remingtron: No, I don't think it would be picked up by the tests. It was a UI element that was going to be removed, but was not removed. |
| 14:28 |
kmlussier |
It's something I should be able to fix. |
| 14:28 |
remingtron |
kmlussier: ah, I see |
| 14:32 |
maryj |
another new question: Is there a location off of github where the official manual for 2.9 is? Or are we waiting for after this hackfest to publish it? (I ask because of the High Level Workflow 2.a. mentions "the official manual" & I wanted to include a correct link.) |
| 14:33 |
remingtron |
maryj: the official docs are built from the master code repository every night, and they end up here: http://docs.evergreen-ils.org/ |
| 16:55 |
maryj |
okay y'all - I'll have my one remaining piece of acq documentation in tomorrow. Have a good evening! |
| 16:57 |
yboston |
you too |
| 16:59 |
gmcharlt |
@coin |
| 16:59 |
pinesol_green |
gmcharlt: heads |
| 17:07 |
|
mmorgan left #evergreen |
| 17:14 |
|
dMiller_ joined #evergreen |
| 17:18 |
pinesol_green |
[evergreen|Christine Burns] Docs: New link to My Lists - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=805d4d6> |
| 17:28 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:30 |
|
rlefaive joined #evergreen |
| 17:31 |
|
dMiller_ joined #evergreen |
| 17:45 |
Bmagic |
does evergreen record user logins paired with actor.workstation ? |
| 09:50 |
gmcharlt |
kmlussier++ :) |
| 09:54 |
|
artunit joined #evergreen |
| 10:02 |
|
rlefaive joined #evergreen |
| 10:18 |
* bshum |
idly wonders if 2.next will be 2.10 |
| 10:24 |
bshum |
Hmm |
| 10:24 |
bshum |
csharp: I haven't tested the working code bits yet, but I think we might want to try some different ways of explaining the options in the README. |
| 10:25 |
bshum |
Looking at https://bugs.launchpad.net/evergreen/+bug/1493824 |
| 10:25 |
pinesol_green |
Launchpad bug 1493824 in Evergreen "Evergreen/PostgreSQL 9.4 support" (affected: 1, heat: 6) [Undecided,New] |
| 10:25 |
bshum |
If we do adopt the postgresql apt repo by default, I wonder too whether it makes more sense to just make PG 9.4 the standard target, and avoid dancing about between multiple make targets for Trusty |
| 10:27 |
* bshum |
also wonders when we should probably yank out all the Squeeze targets and references. |
| 11:16 |
jeff |
fwiw, no sign of any such records in our db. |
| 11:16 |
jboyer-isl |
My only thought is what I mentioned above, export with holdings, do whatever, re-import+overlay. I guess that workflow should also strip out the holdings tag, so if that’s the case I’m at a loss. |
| 11:16 |
gmcharlt |
one of SuperCat's export modes includes embedding such holdings elements |
| 11:17 |
jboyer-isl |
This is something I can test, I guess I should get to it. |
| 11:21 |
jboyer-isl |
Sigh. Good job RAID battery, why don’t you condition yourself in the middle of the day, why would this not be the perfect time. |
| 11:23 |
|
Christineb joined #evergreen |
| 11:23 |
gmcharlt |
jboyer-isl: http://demo.evergreencatalog.com/opac/extras/unapi?id=tag:demo.evergreencatalog.com,2015:biblio-record_entry/3122&format=marcxml-full |
| 11:27 |
jeff |
jboyer-isl: writeback cache disabled during battery conditioning? |
| 09:29 |
Dyrcona |
heh |
| 09:44 |
|
sarabee joined #evergreen |
| 09:52 |
csharp |
gonna take down the ubuntu and fedora buildslaves for a bit, FYI |
| 09:53 |
* Dyrcona |
plans to look into the failing test. I think the test needs adjustment. |
| 10:12 |
dbwells |
Dyrcona: I think you are right. I peeked at it last night, and we just need to remove the 'e's from the sample record in the test. |
| 10:15 |
dbwells |
I think the test might also read better if the "have" and "want" were swapped, but maybe that's just me. |
| 10:15 |
|
Christineb joined #evergreen |
| 10:20 |
Dyrcona |
In case you didn't know: cpan -u takes a long time to run and updates Perl modules installed from packages as well as those installed via CPAN. |
| 10:20 |
Dyrcona |
At least on Ubunut 14.04. |
| 11:45 |
mmorgan |
sqish, squish, squash - sometimes all are required :) |
| 11:53 |
Dyrcona |
Hmm. I'm starting to wonder if the fix in lp 1484281 was complete.... |
| 11:53 |
pinesol_green |
Launchpad bug 1484281 in Evergreen 2.8 "authority data may be deleted during propagation with current values of authority.control_set_authority_field" (affected: 1, heat: 10) [Critical,Fix committed] https://launchpad.net/bugs/1484281 |
| 11:53 |
Dyrcona |
The test still fails after I "fix" it. |
| 11:57 |
yboston |
Dyrcona: the deletes are still propagating? |
| 11:57 |
Dyrcona |
No, but a test keeps failing. |
| 11:58 |
yboston |
which test? one of mine? |
| 11:58 |
Dyrcona |
Also, there is a display_sf_list field that should probably be changed, and there is a 111 entry that probably needs the change. |
| 11:58 |
Dyrcona |
http://testing.evergreen-ils.org/~live/test.22.html |
| 11:59 |
yboston |
My understanding is that the $e can stay in the 111 according to cataloging rules; will double check |
| 12:00 |
yboston |
for the record, I thought that the display_sf_list was meant to still display the subfields that were found in the auth tag |
| 12:00 |
yboston |
and that I would want to display if the $e is actually there, but not authoirty control the $e in the auth tag, but my interpretation of display_sf_list could ahve been wrong |
| 12:44 |
krvmga |
i'm getting an error in course reserves whenever i click on an item "item_status() takes exactly 2 arguments (4 given)". has anyone run into this? |
| 12:46 |
krvmga |
the exception is coming out of Syrup/conifer/plumbing/hooksystem.py in callhook, line 24 ( which is "return f(*args, **kwargs)" |
| 12:47 |
jeff |
beware the dreaded kwargs. |
| 12:47 |
Dyrcona |
yboston: For fixing the test or anything else that the original patch mixed, I think we want a new bug. |
| 12:47 |
krvmga |
jeff: usually i can snickersnack them but now i'm stumped |
| 12:47 |
Dyrcona |
**kwargs |
| 12:49 |
gmcharlt |
yboston: ah, but upon reading again, yep, the *111* $e is a different beast |
| 12:52 |
jwoodard |
all I want is population stats! |
| 13:08 |
mmorgan |
krvmga: Is this every item, or only some items? Can you share a link, or is a login required? |
| 13:15 |
krvmga |
mmorgan: it's every item. you don't need a log in. go to http://rb.cwmars.org/qcc/browse and click on any title |
| 13:17 |
Dyrcona |
So, it gets weirder with this test. |
| 13:17 |
Dyrcona |
I run the function in the database that pg_prove says is failing and it looks like it outputs what is expected. |
| 13:18 |
Dyrcona |
Think I'll copy and paste it to be certain, or is that cheating? |
| 13:19 |
|
kbutler joined #evergreen |
| 13:23 |
dbs |
Dyrcona: does something else change the state of the db prior to running the failing test, by any chanceÉ |
| 13:23 |
Dyrcona |
dbs: Not as far as I know. I'm using concerto for this test. |
| 13:23 |
dbs |
ah le clavier Canadienne Multilinguel |
| 13:24 |
Dyrcona |
:) |
| 13:25 |
Dyrcona |
I did get the test to pass. I'm about to diff the two versions of the test, but I think the changed part is all one line so the difference may not stand out. |
| 13:25 |
Dyrcona |
I wonder if field order didn't change some where. |
| 13:25 |
Dyrcona |
did/didn't what's the difference? |
| 13:27 |
Dyrcona |
Ah.... |
| 13:30 |
gmcharlt |
nah, purely my fault for not reading ALL of the scrollback |
| 13:30 |
yboston |
Dyrcona: let me know if I can help with anything |
| 13:31 |
yboston |
Dyrcona: I would love to hear miker thouhgts on display_sf_list versus sf_list |
| 13:36 |
Dyrcona |
yboston: I don't think there's anything wrong with your change. The test needs to be updated, but I wonder why I'm getting the name space in every xml element. |
| 13:37 |
yboston |
OK |
| 13:37 |
Dyrcona |
Looking at the source from the failed testing server it is not getting the nameespace in every element. |
| 13:38 |
Dyrcona |
I am going to make the change that I originally thought was needed and push it to a branch after making a launchpad bug. |
| 13:38 |
Dyrcona |
I am inclined to blame different versions of libxml for the name space change. |
| 13:38 |
|
ericar joined #evergreen |
| 14:06 |
alynn26 |
stompro_home++ |
| 14:06 |
yboston |
*script |
| 14:07 |
alynn26 |
one step at a time |
| 14:07 |
yboston |
yes |
| 14:07 |
yboston |
shoudl I move on? |
| 14:07 |
yboston |
moving om |
| 14:07 |
yboston |
#info 3) remingtron will continue testing conversion of all .txt files to the .adoc extension |
| 14:08 |
yboston |
will postpone, because I am not sure if he is around today/now |
| 14:08 |
yboston |
#action remingtron will continue testing conversion of all .txt files to the .adoc extension |
| 14:08 |
yboston |
#info 4) kmlussier will send out an email to DIG list to request updates on unfinsished 2.8 new features |
| 14:08 |
yboston |
this was done |
| 14:08 |
yboston |
kmlussier++ |
| 14:09 |
alynn26 |
kmlussier++ |
| 14:09 |
yboston |
which leads to the next past action |
| 14:09 |
yboston |
#info 5) kmlussier will follow up with direct emails to request updates on unfinsished 2.8 new features or to ask for works in progress |
| 14:18 |
yboston |
#action Stompro will send a list to DIG list summarizing the 2.8 docs work he has so far shared |
| 14:19 |
yboston |
let me quickly postone my one task |
| 14:19 |
yboston |
#action yboston will move the undocumented content of the 2.8 new feature “TPAC Discoverability Enhancements” to its own section in the docs |
| 14:19 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1491962 Fix 0847 Live Test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=12a4f8d> |
| 14:19 |
yboston |
my bad, did not get to it, did get good feedback from DIG at last meeting |
| 14:20 |
remingtron |
when we're ready, I want to add an item to the agenda |
| 14:20 |
yboston |
yes, go ahead |
| 15:50 |
pinesol_green |
[evergreen|Bill Erickson] LP#1465847 Empty patron search exits early - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=12a3f5b> |
| 16:03 |
|
jlitrell joined #evergreen |
| 16:24 |
Bmagic |
Anyone out there use metarecord holds primarily? We defaulted our OPAC to have group formats turned on. |
| 16:31 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:31 |
Dyrcona |
"And there was much rejoicing." |
| 16:32 |
bshum |
Huzzah |
| 16:37 |
dbs |
Dyrcona++ |
| 10:23 |
Dyrcona |
The branch name disappears once the code is cherry-picked. |
| 10:25 |
yboston |
good to know |
| 10:26 |
Dyrcona |
I'll amend the commit messages to make sure they're prefixed with the proper lp bug if they need it. |
| 10:30 |
Dyrcona |
And, I'm ready to commence testing. |
| 10:44 |
Dyrcona |
So to test this I run authority_control_fields.pl and watch the $e disappear from my target bibs? |
| 10:44 |
Dyrcona |
Meaning that is the behavior before the fix. |
| 10:50 |
|
ericar_ joined #evergreen |
| 10:52 |
|
ericar joined #evergreen |
| 12:04 |
Dyrcona |
And, lunch |
| 12:04 |
|
Christineb joined #evergreen |
| 12:20 |
|
collum joined #evergreen |
| 12:41 |
Dyrcona |
Guess I'll roll up the 2.9-rc so I'll have a little time to test it. |
| 12:44 |
Dyrcona |
Give me some time to figure what happened with bower. |
| 12:53 |
|
ericar joined #evergreen |
| 12:59 |
|
jihpringle joined #evergreen |
| 13:28 |
Dyrcona |
pgardella1: A/T isn't my strong point, but you need to make sure that the events are enabled and the cron jobs are running. |
| 13:29 |
tsbere |
pgardella: Has anyone tried to submit a request? If so, are they running into the max active requests limit? Do they have email addresses on file? |
| 13:31 |
mmorgan |
For reference, here's what transpired yesterday regarding pgardella's question: http://irc.evergreen-ils.org/evergreen/2015-09-01#i_200538 |
| 13:31 |
pgardella |
tsbere: I'm testing my own account. I have an email on file. So has several other library staff. None of us should have hit the max active requests. |
| 13:32 |
pgardella |
mmorgan++ |
| 13:32 |
tsbere |
pgardella: Are there any recent rows in actor.usr_password_reset? |
| 13:33 |
pgardella |
tsbere: nothing since 8/15 |
| 13:33 |
tsbere |
pgardella: That would imply no successful attempts to initiate one |
| 15:18 |
Dyrcona |
Is it something we would want to discuss at a future meeting, or should we drop it? |
| 15:18 |
jeff |
no specific followup other than that. drop it from the next agenda unless further discussion brings it back to the agenda. |
| 15:19 |
Dyrcona |
#agree drop it for now. :) |
| 15:19 |
Dyrcona |
#info ldw will looking into integrating neg. balance tests on test writing day |
| 15:20 |
Dyrcona |
ldw: I think that happened more or less. |
| 15:20 |
ldw |
I did not get the neg balance tests personally. I do not know if someone else worked on it that day. |
| 15:21 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:21 |
Dyrcona |
There are some negative balance tests and more can always be added. |
| 15:21 |
Dyrcona |
dbwells or remingtron anything to add? |
| 15:22 |
dbwells |
I think the goal was to reconsider the way they were setup, but that doesn't need to happen with any particular urgency. |
| 15:23 |
Dyrcona |
So, we'll call that one done, too. |
| 15:39 |
Dyrcona |
#topic Evergreen Release(s) |
| 15:39 |
Dyrcona |
So, I'll take an action item right off the bat. |
| 15:39 |
Dyrcona |
#action Dyrcona to release 2.9-rc after the meeting. |
| 15:40 |
Dyrcona |
I just made the tarball this afternoon, loaded it on a test vm with concerto data, and all looks good. |
| 15:40 |
Dyrcona |
I even got it to work with the web staff client. I think that ended up being bad ownership on a directory. |
| 15:41 |
Dyrcona |
So, do we want action items for the maintenance releases in two weeks or is that overkill? |
| 15:42 |
Dyrcona |
I guess that would include 2.9.0 as well. |
| 17:05 |
Dyrcona |
bshum++ |
| 17:05 |
Dyrcona |
Thanks for taking care of that part. |
| 17:05 |
Dyrcona |
Well, time to go. I'll probably be back on later. |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:09 |
bshum |
Dun, dun, dunnnnn |
| 17:09 |
bshum |
Authority test fail |
| 17:10 |
* bshum |
disappears into the mists |
| 17:33 |
jwoodard |
learned glaring at Evergreen does not fix anything |
| 18:15 |
|
Dyrcona joined #evergreen |
| 19:00 |
|
gsams-web 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> |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:43 |
|
graced joined #evergreen |
| 07:57 |
|
mrpeters joined #evergreen |
| 09:33 |
jeff |
but i haven't measured that. |
| 09:34 |
mmorgan |
Using the back button, we can see the previous data that had been entered in the form. |
| 09:35 |
mmorgan |
Yours nicely clears that info. |
| 09:35 |
csharp |
quick question - we enabled Google Analytics in the OPAC yesterday, and it worked fine in all the browsers we tested, but we got mixed secure/insecure content warnings in the staff client (until we re-disabled it). Do others see that? How do you handle it? |
| 09:36 |
jeff |
csharp: pretty sure recent commit disables it in the staff client. |
| 09:36 |
tsbere |
csharp: That probably has to do with the oils protocol bit in the staff client for faking out "remote xul" and all. |
| 09:36 |
mmorgan |
lp 1466201 |
| 10:41 |
pinesol_green |
Launchpad bug 1175740 in Evergreen 2.4 "Acq: Certain workflows produce orphaned fund debits" (affected: 2, heat: 14) [Undecided,Incomplete] https://launchpad.net/bugs/1175740 |
| 10:43 |
csharp |
kmlussier: this came to me as "there are acq-orphaned copies floating around in the OPAC", so I haven't investigated deeply enough to know when copies/bibs aren't orphaned |
| 10:44 |
csharp |
in any case, I think Lebbeous's "prompt the user for copy deletion" approach is the best |
| 10:44 |
kmlussier |
Yes, I did some testing around those a while back and reported my results on bug 1269574. Not sure if the behavior has changed since then. |
| 10:44 |
pinesol_green |
Launchpad bug 1269574 in Evergreen "ACQ lineitems canceled via EDI not deleting linked bibs/items" (affected: 8, heat: 40) [Medium,Confirmed] https://launchpad.net/bugs/1269574 |
| 10:45 |
csharp |
kmlussier: oh - I inexplicably missed your comment on that bug :-/ |
| 10:47 |
kmlussier |
In re-reading bug 1175740, it looks like the initial issue reported was that fund debits stuck around if the lineitem was deleted without first being canceled. AFAIK, you can no longer delete lineitems in the UI, which is why I wasn't able to replicate it. |
| 10:47 |
kmlussier |
Of course, we want people to be able to delete lineitems in the UI, but only when they are in the "correct" state. Correct being pending or truly canceled. |
| 10:47 |
kmlussier |
I think that's on another bug. |
| 10:48 |
kmlussier |
So many bugs |
| 10:50 |
Christineb |
We have seen issues very similar to 1175740 - orphaned fund debits - I have it on my list to do additional testing and add notes |
| 10:50 |
Christineb |
so many bugs |
| 10:52 |
csharp |
yep |
| 10:53 |
kmlussier |
Christineb / csharp: If you can identify another scenario that creates orphan debits, let me know. I'll be happy to re-test an set the bug back to confirmed. :) |
| 10:54 |
kmlussier |
I'll also check back with my acq people to see if they are still seeing the problem. |
| 10:54 |
kmlussier |
I think one of our sites was the original source of that bug report from senator. But I could be mistaking it with another one because...so many bugs. |
| 10:55 |
kmlussier |
Speaking of so many bugs, I've been negligent on scheduling a Bug Squashing Day. We usually do one between beta and the full release. |
| 10:55 |
Christineb |
I think for us - when a line item is cancelled/delayed but then later received, an orhphan debit is created for the encumbrance - so we have a fund_debit where encumbrance = false and a fund_debit where encumbrance = true |
| 10:56 |
kmlussier |
Ah, that makes sense. |
| 10:56 |
Christineb |
I will test and add comments |
| 11:09 |
* kmlussier |
just spent 20 minutes typing up an email with a question to the dev list only to realize what the answer was as she was about to hit 'send.' |
| 11:09 |
dbs |
kmlussier: sounds like a blog post to me! |
| 11:09 |
kmlussier |
I think it would have taken less time if I had just talked to a rubber duck. |
| 16:42 |
pgardella |
What cronjob sends it? I've tried manually running the —run-pending |
| 16:46 |
mmorgan |
pgardella: Is your "Password reset request notification" action trigger enabled? It is not enabled by default. |
| 16:48 |
pgardella |
mmorgan: There isn't one in the example, nor listed anywhere I could find. |
| 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> |
| 16:52 |
tsbere |
pgardella: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/950.data.seed-values.sql;h=2532ba552eb1e9ae65e2fff98e45716fed1bad19;hb=master#l8164 |
| 16:52 |
mmorgan |
pgardella: If you look in the database table action_trigger.event_definition, it should be id 20. |
| 16:54 |
pgardella |
Ah. OK. I'll take a look. |
| 16:55 |
pgardella |
mmorgan: it is enabled. |
| 16:57 |
gsams |
pgardella: we gave password resets their own granularity. The cronjob looks like: */1 * * * * /openils/bin/action_trigger_runner.pl --osrf-config /openils/conf/opensrf_core.xml --run-pending --granularity password --granularity-only |
| 16:58 |
mmorgan |
pgardella: does the user requesting the password reset have an email address set in their account? |
| 16:58 |
pgardella |
Yes. I tested it with mine, as have several other library staff. |
| 16:58 |
tsbere |
gsans: Ours is very similar, but we only run it every five minutes instead of every minute. |
| 16:58 |
gsams |
of course, we had problems with A/T working without granularity settings |
| 16:59 |
pgardella |
I'll take a look and make sure the A/T is set up correctly. It looks like it, but I'll verify it against the git commit tsbere sent. |
| 17:04 |
kmlussier |
mmorgan: How often do your action triggers run? What I like about the approach from gsams and tsbere is that the password reset runs quite frequently. |
| 17:04 |
gsams |
mmorgan: We split it into 4 types, with overdue notices being by OU. The others are passwords, holds, and predue notices. |
| 17:05 |
* mmorgan |
checks the crontab |
| 17:05 |
gsams |
I was impatient when testing so I set it to 1 minute and never ended up changing it to 5 which was intended |
| 17:05 |
gsams |
it hasn't been a problem though, so bonus. |
| 17:05 |
kmlussier |
gsams: I think most users expect to receive the password reset immediately, so that seems like a good approach. :) |
| 17:06 |
mmorgan |
Our triggers run every two minutes. |
| 17:06 |
pgardella |
mmorgan: No events have been created since 8/15. Hum. Time to go figure out what we did that day! I'll check back in tomorrow once I talk to the engineers! |
| 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:43 |
|
sarabee joined #evergreen |
| 07:54 |
|
ericar joined #evergreen |
| 08:01 |
|
jboyer-isl joined #evergreen |
| 14:26 |
dbs |
Dyrcona: yeah, I suspect it's a permission issue |
| 14:26 |
dbs |
weird that it shows up in the staff client menu but whatever, i'm a psql guy anyway |
| 14:28 |
dbs |
Yay, set up a "Circ Modifier trumps ALL!" weight and associated it as the default, and it seems to work. |
| 14:28 |
rfrasur |
Ugh, I completely forgot about the GoToMeeting test call, tspindler. My apologies. |
| 14:29 |
bshum |
rfrasur: tspindler: I knew I was forgetting something too... sigh :( |
| 14:29 |
* bshum |
has been in other meetings too |
| 14:29 |
rfrasur |
bshum, I can't blame other meetings, but I did put together 3 telescopes (and only swore twice). |
| 14:31 |
Dyrcona |
bshum++ |
| 14:31 |
Dyrcona |
I had that it all up on my server at some point, but got a new server or something happened and that was all I could find. |
| 14:32 |
Dyrcona |
Anyway, I'm investigating what looks like a permissions issue and this one is surprising to turn up after four years on Evergreen. |
| 14:41 |
tspindler |
bshum: its ok, Chauncey, Yamil and Andrea were on. I think we saw enough of the functionality to report back. We might want to try a large test later to see how its performance is with a larger number. |
| 14:42 |
|
akilsdonk joined #evergreen |
| 14:43 |
|
mmorgan1 joined #evergreen |
| 14:45 |
bshum |
tspindler: Cool deal, thanks for the update. |
| 14:45 |
bshum |
tspindler: I'm curious, presuming you guys were testing on Windows, maybe a Mac from yboston. Did any other OS make it in the mix? |
| 14:47 |
* bshum |
has used GoToMeeting sorta on his android phone, but remembered some oddities with his Ubuntu workstations once upon a time. |
| 14:48 |
jlitrell |
Last I heard was partial html5 support, so it should (kinda) work in lunix too. |
| 14:51 |
dbs |
hmm, maybe the circ weight matrix problem wasn't permssions, according to our logs: Returning method exception with message: An unknown server error occurred |
| 14:51 |
dbs |
fancy! |
| 15:27 |
pinesol_green |
Launchpad bug 1257915 in Evergreen "Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled" (affected: 9, heat: 48) [Medium,Confirmed] https://launchpad.net/bugs/1257915 |
| 16:04 |
jihpringle |
Bmagic: we do that for at least one of our libraries every few months and haven't run into any issues |
| 16:05 |
Bmagic |
jihpringle++ that makes me feel confident |
| 16:05 |
jihpringle |
we did it on our test server first |
| 16:05 |
Bmagic |
right on |
| 16:06 |
jihpringle |
when she gets back from lunch, Christineb is going to try and find our ticket from when we tested this to see if we noted any issues/things to be aware of when testing |
| 16:07 |
|
tspindler left #evergreen |
| 16:08 |
jeff |
jihpringle++ Christineb++ |
| 16:29 |
jihpringle |
Bmagic: just confirmed in our ticket, all we do is change the state to = received and we've had no reports of issues from libraries |
| 00:45 |
bshum |
@later tell dbs Hmm, for some reason I'm not seeing a webstaff.pot i18n file in Launchpad translations, so I wonder if maybe the sync from your bzr in LP needs some further manual tweaking to get underway. |
| 00:45 |
pinesol_green |
bshum: The operation succeeded. |
| 01:05 |
|
Mark__T joined #evergreen |
| 01:14 |
|
ningalls 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:29 |
|
ningalls joined #evergreen |
| 06:29 |
|
kmlussier joined #evergreen |
| 06:29 |
|
bshum joined #evergreen |
| 06:29 |
|
mceraso joined #evergreen |
| 06:29 |
|
ldw joined #evergreen |
| 06:29 |
|
rangi joined #evergreen |
| 06:30 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 06:32 |
|
TaraC joined #evergreen |
| 06:32 |
|
mceraso joined #evergreen |
| 06:32 |
|
ldw joined #evergreen |
| 10:34 |
Dyrcona |
I could do #1 pretty quickly if you like. |
| 10:34 |
yboston |
on how to write upgrade code |
| 10:35 |
Dyrcona |
bshum++ |
| 10:35 |
yboston |
What I want to learn is what is the proper working branch live cycle |
| 10:35 |
yboston |
like, is it OK for me to just fix that commit and just destroy my branch a recreate it, when is it OK to force push a working branch |
| 10:36 |
yboston |
for now I was juts going to create a fresh branch... |
| 10:36 |
yboston |
then just cherry pick my exisitng commit; fix the bad one, then just add the upgrade code |
| 10:36 |
yboston |
I already have a pgTAP test |
| 10:36 |
Dyrcona |
It is usually OK to force push over a working/user branch. |
| 10:36 |
bshum |
I tend to force push mistakes away, as long as I haven't seen people pick my code up. |
| 10:36 |
Dyrcona |
Generally not OK on a working/collab branch. |
| 10:39 |
Dyrcona |
It's really up to you in your user branch. |
| 10:39 |
yboston |
I had seen the phrse (forced push) in git log; not sure if it is done by git or manually? |
| 10:39 |
dbs |
bshum: hmm, not really sure what's going on with the bzr thing |
| 10:40 |
Dyrcona |
I personally don't have a problem with making a new test branch of my own when a force push happens. |
| 10:40 |
* dbs |
will peek |
| 10:40 |
* Dyrcona |
decides not to pun on bzr/bazaar/bizarre. |
| 10:40 |
yboston |
also, I am crytal clear now that it is OK to force push on a user workign branch, though not on a collab brnach unless coordinated with others |
| 10:42 |
Dyrcona |
The reasoning is partly because only the owner can push to a user branch, but anyone with working access can push to a collab branch. |
| 10:42 |
yboston |
bshum & Dyrcona: thanks for all the info |
| 10:42 |
Dyrcona |
yw yboston. :) |
| 10:43 |
Bmagic |
mmorgan: Did you get that test machine to trigger to lost? |
| 10:43 |
yboston |
Dyrcona: I knew that, but I still wanted to confirm that it is OK to force push after doign a rebase with master on my own user working branch |
| 10:43 |
dbs |
https://code.launchpad.net/~denials/evergreen/master looks like it is plugging along |
| 10:44 |
yboston |
Dyrcona: then again, even though I knew that others could push to collabs, I had not realized how it would be a much bigger no-no to push to a collab branch; thank for helping me lreaize the implications |
| 14:01 |
Dyrcona |
Also faster and based on libxml2. |
| 14:01 |
jeff |
The interesting thing was that given 1000 records, it shifted over time. The first match wasn't always the first record. It changed every X or so. |
| 14:01 |
Dyrcona |
That is interesting. I never noticed that, but I wasn't parsing that many elements. |
| 14:05 |
jeff |
round tripping record to a string and back broke the association and "fixed" things. once i realized what was happening (after making a few test cases) i switched to relative xpath expressions and was happier. |
| 14:05 |
jeff |
but it was a bit confusing at first. |
| 14:05 |
jeff |
once I figured it out I recalled seeing something in the docs, but I think I just found what I was thinking of and it's almost entirely unrelated: ``Note that a string result returned by XPath is a special 'smart' object that knows about its origins. You can ask it where it came from through its getparent() method, just as you would with Elements'' |
| 14:06 |
Dyrcona |
yep. |
| 14:06 |
Dyrcona |
I'm not sure if that behavior is unique to lxml or if it comes from libxml2. |
| 14:10 |
jeff |
I still haven't found where it's documented. I'll let you know if I find out. :-) |
| 14:14 |
|
ningalls joined #evergreen |
| 14:14 |
|
bmills joined #evergreen |
| 14:27 |
jboyer-isl |
People with opinions on tests: I'm torn between simplistic "is there a row with this value in this table" vs actually testing the functionality "if you insert this record, are these fields extracted as expected?" |
| 14:28 |
jboyer-isl |
The functional tests seem more robust (if the rows or tables involved in the back end changes, the test still works) but I didn't know if there was a wider preference. |
| 14:29 |
gmcharlt |
jboyer-isl: testing intent is better than testing implementation details |
| 14:29 |
gmcharlt |
(as a rule of thumb) |
| 14:29 |
jboyer-isl |
That's what I was leaning toward. |
| 14:30 |
jboyer-isl |
I'm likely going to dump the 350+ "is there a row with these 3 fields" tests and replace them with 10-20 of the "are the correct fields extracted from this test marc" variety. |
| 14:31 |
Bmagic |
Dyrcona: About the backdating, I think the library was being misled when the message on the UI contained a date that wasn't what they entered |
| 14:33 |
tsbere |
jboyer-isl: Just ensure you test every combination already in the test set. ;) |
| 14:35 |
jboyer-isl |
tsbere: easy :p "SELECT ok((SELECT * FROM config.upgrade_log WHERE version = 'VERSION MY PATCH APPLIED'), 'fixed fields upgrade'); |
| 14:35 |
jboyer-isl |
;) |
| 14:41 |
bshum |
Bmagic: That's odd... I thought hyphens was fixed for SMS texting a couple versions ago. |
| 15:10 |
jeff |
it's rather trivial to get/guess that with reasonable accuracy. |
| 15:11 |
jeff |
especially if you're targeting a single or small handful of numbers. |
| 15:11 |
hopkinsju |
I wont' speculate about the dificulty or what constitutions reasonable accuracy, but I can say that our OPAC is not required for those attempts to be made. |
| 15:14 |
jeff |
bshum: if you attempt to message an invalid number, you will not be billed. if you attempt to message a number that isn't actually capable of receiving SMS, a lot of the "will i be billed" answer will vary based on the remote provider, the nature of the "why can't this receive SMS", etc. |
| 15:19 |
jeff |
bshum: typically, and on the two tests i just did, if you're sending to a landline you will not be charged. |
| 15:19 |
jeff |
bshum: and perhaps more importantly, you'll know that the message did not go through. |
| 15:28 |
jeff |
hopkinsju: for consortial environments, as long as you didn't mind $1/mo per billed entity, and as long as you could agree on something logical like "home_ou of user pays", billing could be reasonably well sorted out. |
| 15:29 |
jeff |
bonus there would be that the messages would come from a number dedicated to the billed entity, and in the future could do things like actually receive texts, etc, etc. |
| 15:32 |
jeff |
Any other concerns/issues/challenges that come to mind? |
| 15:35 |
|
bmills joined #evergreen |
| 15:36 |
* bshum |
can't think of anything right now, but also feels that Fridays are not his best thinking days. :P |
| 15:36 |
bshum |
Especially Fridays after a nice pizza lunch |
| 17:01 |
mmorgan |
Bmagic: For good measure, I would explicitly set them to False. |
| 17:04 |
mmorgan |
Yay! just tried the scenario from http://irc.evergreen-ils.org/evergreen/2015-08-28#i_199831 with the code from lp 1331174, and the transaction closed :) |
| 17:04 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 17:04 |
jeff |
mmorgan++ testing |
| 17:04 |
mmorgan |
Unfortunately, the mark lost part will need to wait until next week :-( |
| 17:13 |
|
mmorgan left #evergreen |
| 17:24 |
* dbs |
wonders if A/T needs to run to set the penalties that block circ |
| 05:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:14 |
|
rlefaive joined #evergreen |
| 07:45 |
|
collum joined #evergreen |
| 07:56 |
|
rlefaive joined #evergreen |
| 09:34 |
|
john joined #evergreen |
| 09:39 |
Guest3965 |
Hi, I am working on setting up an evergreen instance on ubuntu trusty. When I try to register a workstation with the staff client, I'm receiving 200: OK under version, but 500: Internal Server Error. I've checked the apache and system logs but haven't found anything useful. Does anyone know what might be causing the issue? |
| 09:40 |
Guest3965 |
Sorry, 500: Internal Server Error under status, I mean |
| 09:41 |
jeff |
Guest3965: looks like the nickname "john" was taken, so you've been renamed. |
| 09:42 |
jeff |
Guest3965: apache will return a 500 error in that case if the evergreen opensrf services aren't running (that's the most common cause) |
| 09:42 |
jeff |
Guest3965: I'd stop apache, stop all opensrf services, ensure that both ejabberd and memcached are running (you can restart them, stop/start them, whatever). |
| 09:43 |
jeff |
Guest3965: then, start the evergreen opensrf services. wait for that to be successful, consider using the --diagnostic argument to osrf_control to ensure that they all started. |
| 09:43 |
jeff |
Guest3965: finally, start apache and try the staff client again. |
| 09:44 |
jeff |
Guest3965: if that doesn't work, test with srfsh to ensure that you can successfully log in. |
| 09:44 |
Guest3965 |
Okay, thank you! I'll give that a try now |
| 09:44 |
Guest3965 |
I appreciate the help |
| 09:44 |
jeff |
Guest3965: if neither of those work, you may have a configuration issue with ejabberd or opensrf, etc. |
| 10:10 |
jeff |
docs/TechRef/Circ/custom-best-hold-selection.txt |
| 10:10 |
mmorgan |
jeff++ |
| 10:11 |
jeff |
Stompro: I don't have enough recent/relevant experience in this area to offer much more at this time, sorry. :-) |
| 10:13 |
* mmorgan |
did some testing on this early on. Have some notes somewhere... |
| 10:17 |
* jeff |
refreshed/added some knowledge after all |
| 10:17 |
Stompro |
Is circ_lib the location that the copy currently "lives" at? The term circ_lib just doesn't mean anything to me yet. I'm used to thinking in terms of owning locations for items. |
| 10:18 |
jeff |
Stompro: that table defines what priority is given to each of those attributes when a given hold order is configured. so, in the case of "first in, first out, but holds always go to patrons at the copy's circ lib first", top priority is "hprox" |
| 13:31 |
berick |
i can log in OK |
| 13:31 |
berick |
csharp_athens: chrome? |
| 13:32 |
berick |
chrome and FF both working for me |
| 13:33 |
jeff |
likewise here, including with incognito (testing to make sure my having logged in before wasn't obscuring another error) |
| 13:33 |
jeff |
csharp_athens: draconian firewall between you and webby? |
| 13:33 |
berick |
csharp_athens: could be firewall blocking websocket port. |
| 13:33 |
berick |
jinx |
| 13:33 |
berick |
JS console would show an error |
| 15:07 |
dcmh |
yboston: ok |
| 15:07 |
yboston |
I see that berowskim happened to reply to Stompro, which is perfectly fine |
| 15:07 |
afterl |
yboston: nice tab trick |
| 15:08 |
yboston |
let me try to reply to a bunch of you at the same time, to see if your IRC software/site sounds a ping |
| 15:08 |
yboston |
jacobsd Stompro dcmh loril dkvit: this is a mutliple reply test? |
| 15:09 |
yboston |
sorry I missed some of you |
| 15:09 |
dkvit |
yboston: ooh! I got a sound |
| 15:09 |
yboston |
cool |
| 15:09 |
phasefx |
some IRC clients will also highlight lines that contain your name to better get your attention |
| 15:37 |
yboston |
dkvit: is this what you saw or is it regualr messages that the UI of your IRC cleint/site happens to not make it as clear who is the author? |
| 15:37 |
* SharonD |
just talking to myself |
| 15:37 |
dkvit |
yboston: I think it's that third person thing... |
| 15:37 |
yboston |
ok |
| 15:37 |
yboston |
mmorgan: thanks for the idea |
| 15:37 |
yboston |
so lets recap what we have tried so far... |
| 15:38 |
yboston |
1) replying |
| 15:38 |
yboston |
2) private messages |
| 15:38 |
yboston |
3) karma |
| 15:38 |
yboston |
4) actions/third person voice |
| 15:38 |
yboston |
btw, you hsould all try the third person voice as test |
| 15:38 |
yboston |
*should |
| 15:39 |
* jacobsd |
is thinking in the third person |
| 15:39 |
yboston |
another key concept I wan to show you is how we often do infromal voting on an idea |
| 15:39 |
* dkvit |
a little stressed by the third person/karma thing. Will work through it |
| 16:52 |
jeff |
maybe. |
| 16:53 |
|
vlewis joined #evergreen |
| 16:58 |
jeff |
yup. |
| 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:00 |
|
kmlussier joined #evergreen |
| 17:03 |
|
bshum joined #evergreen |
| 17:03 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 17:06 |
|
jlitrell joined #evergreen |
| 17:07 |
jeff |
doing essentially a no-op batch update (set all these holds to Active when all are active) will end up stripping microseconds because it does an unconditional update. |
| 17:11 |
|
mmorgan left #evergreen |
