01:37 |
|
Mark__T joined #evergreen |
05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
07:56 |
|
jboyer-isl joined #evergreen |
07:56 |
|
rjackson_isl joined #evergreen |
08:00 |
|
collum joined #evergreen |
09:22 |
kmlussier |
I know the page you're talking about. It is indeed very difficult to find. |
09:23 |
kmlussier |
http://wiki.evergreen-ils.org/doku.php?id=website_administration |
09:23 |
remingtron |
yeah, I just searched for Chris Sharp and found that page too |
09:25 |
kmlussier |
I guess I see the release notes acknowledgements as a way to thank the people/organizations responsible for contributing the code, docs, tests that made a release happen. We could expand upon it, but there may be better places where we can acknowledge other contributions to the community. |
09:26 |
remingtron |
kmlussier: on the main website? |
09:26 |
kmlussier |
Yes, that seems appropriate. Because they are ongoing contributions. |
09:26 |
remingtron |
I agree, ongoing contributions are different than version contributions |
12:39 |
bshum |
Disagree? |
12:39 |
Bmagic |
or agree |
12:41 |
Bmagic |
I think that the issue is the link actually. It should reference "id" instead of "source" |
12:50 |
Dyrcona |
csharp: I am installing 2.8.4 so I can test the upgrade script for 2.8.4 to 2.9.0. |
12:55 |
mmorgan |
Bmagic: Disclaimer, I don't pretend to have a deep understanding of the idl, but the id field has datatype "id", not "link" so it's not referring to that link field. |
12:56 |
Bmagic |
mmorgan: compare to metabib::record_attr |
12:56 |
Dyrcona |
Well, it should most likely be a link to bre.id. Does that appear in the list of links? |
13:45 |
Dyrcona |
It works for me. I'm going to post a branch based on rel_2_9. |
13:46 |
Dyrcona |
You check it out and just try the 2.8.4 to 2.9.0 upgrade script, or you can go through the whole install process from git if you like. |
13:52 |
Dyrcona |
csharp: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1497307_fix_upgrade_script |
14:27 |
csharp |
Dyrcona: excellent! I'll test |
14:27 |
Dyrcona |
csharp++ |
14:33 |
csharp |
so far so good - I'm at the authority update, which will take a while |
14:33 |
csharp |
I'll update the bug with a signoff unless I hit anything |
15:38 |
Dyrcona |
I'll send an email to the general list to let anyone know who has already downloaded it that they should download it again. |
15:38 |
csharp |
excellent |
15:44 |
kmlussier |
Stompro: Glad you got it to work the way you wanted! |
15:52 |
* csharp |
experiments with parallel pg_dump |
15:53 |
csharp |
on a test server with SSDs and 64 processor cores (using 48) - this should speed up a couple of upgrade steps ;-) |
15:56 |
* jlitrell |
sighs wistfully |
16:03 |
Bmagic |
I might have found a bug, would someone confirm. Using the staff client, replacing a barcode using this method: Edit Menu -> Replace barcode. It's resulting in a new item instead of replacing the barcode of the old item. Seems to be new in 2.8+ |
16:05 |
* jeffdavis |
submits a feature request entitled "Require all SQL generated by the reporter to be reviewed and approved by a knowledgeable human before being run" |
16:13 |
jboyer-isl |
That’s the first I’ve heard of it. Almost like an in-line version of the audit tables (but I assume with a different feature set in mind, long, long ago) |
16:14 |
Dyrcona |
Probably. |
16:14 |
berick |
apt metaphor. a MARC record eats its owner, its owner goes on to provide power for the MARC record, which would have otherwise died out. |
16:14 |
kmlussier |
Bmagic: I tested it on master too and had the same results as mmorgan. |
16:14 |
jboyer-isl |
berick++ |
16:14 |
Bmagic |
weird |
16:15 |
kmlussier |
mmorgan: The sound was a little unexpected, wasn't it? |
16:16 |
mmorgan |
Maybe it's the old barcode saying: Noooooo! as it goes poof. |
16:16 |
mmorgan |
Actually, we have not replaced it. |
16:17 |
mmorgan |
I wonder if our users would miss it if we replaced it now. I think we still have folks that pine for the turtle. |
16:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:06 |
|
mmorgan left #evergreen |
17:17 |
|
bmills1 joined #evergreen |
19:44 |
|
jihpringle joined #evergreen |
20:31 |
gmcharlt |
doing maintenance on evergreen-ils.org |
23:40 |
|
serflog joined #evergreen |
23:40 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
23:44 |
gmcharlt |
testing |
23:48 |
gmcharlt |
ok, all done - everything should be up and running again (with the exception of piwik tracking, which I've mostly disabled) and running Wheezy |
23:49 |
csharp |
gmcharlt++ |
23:49 |
gmcharlt |
another O/S upgrade is in store some time next week |
04:13 |
|
mnsri_ joined #evergreen |
05:01 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
05:14 |
|
sarabee joined #evergreen |
07:31 |
|
graced joined #evergreen |
07:39 |
|
jboyer-isl joined #evergreen |
07:42 |
|
ericar joined #evergreen |
07:46 |
|
collum joined #evergreen |
08:12 |
miker |
so, that test failure is due to a postgres bug fix which, by the way, we desperately want: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=79af9a1d2668c9edc8171f03c39e7fed571eeb98 |
08:12 |
miker |
I'll adjust the test to match modern PG, because everyone should upgrade to the most recent minor version in any case :) |
08:25 |
dbwells |
miker: Thanks for the commit link, I've been wondering about the history behind the change. Do you think it's going to cause problems for some of our uses? It seems like in some cases we actually just want an XML fragment, since we're going to insert into another record or whatnot. |
08:25 |
miker |
no, the fix is going to allow us to simplify all /sorts/ of xpath-using code |
08:27 |
dbwells |
Ah, I wasn't really thinking that direction. There are a bunch of places where we have to dance around not having a proper namespace. |
08:32 |
miker |
I look at it like this: it's just space, which is cheap ... and, while I've certainly been known to do it, and it's currently much faster, munging xml via regex is still wrong and shameful |
08:33 |
dbwells |
but it's so fast! ;) |
08:33 |
|
Dyrcona joined #evergreen |
08:35 |
miker |
Dyrcona: sorry to pounce immediately, but I have a fix for the test failure, and as RM[aintainer] I'll just ask you: shall I wait for launchpad to load, create a bug, push a branch, and update the bug, or just push the test fix to master? :) |
08:36 |
Dyrcona |
That's what has typically been done with test fixes so far, so I'd say yes. |
08:36 |
miker |
you mean push to master? |
08:36 |
Dyrcona |
No, I mean create a bug on launchpad, etc. |
08:37 |
miker |
k |
08:38 |
dbwells |
miker: I'm happy to sign off based on what I already know about the situation, so the bug report can be pretty "lite" :) |
08:38 |
|
mmorgan joined #evergreen |
08:40 |
dbwells |
Maybe a small consolation. |
08:40 |
Dyrcona |
Well, I don't think we need much for fixing tests. Something like "test [blah] is broken, this should fix it." |
08:41 |
|
maryj joined #evergreen |
08:43 |
miker |
dbwells: bug 1496837 at ya', and thanks! |
08:43 |
pinesol_green |
Launchpad bug 1496837 in Evergreen "xml-related test is invalid" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1496837 |
08:45 |
|
mrpeters joined #evergreen |
08:47 |
pinesol_green |
[evergreen|Mike Rylander] LP#1496837: Postgres fixed a bug and broke our test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b06b541> |
08:47 |
dbwells |
dang, forgot the -s to sign-off. |
08:58 |
|
rjackson_isl joined #evergreen |
09:08 |
miker |
dbwells++ |
14:04 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Kent County Public Library |
14:04 |
bshum |
I'll keep us going for now then. |
14:04 |
sherbertbc_ |
having connection problems, sorry |
14:04 |
bshum |
#topic Minutes/actions from last meeting - http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-07-16-14.00.html |
14:05 |
bshum |
1) tspindler will announce a test meeting in the next 2 months to |
14:05 |
bshum |
use our GoToWebinar so we can test it and invite other members of the |
14:05 |
bshum |
Evergreen community to join if they want. |
14:05 |
bshum |
tspindler++ for putting that together |
14:05 |
bshum |
And thanks to all of you who participated |
14:05 |
rfrasur |
What was the verdict? |
14:05 |
bshum |
#info tspindler to test GoToWebinar with other EOB members |
14:06 |
bshum |
#info tspindler's results: http://list.evergreen-ils.org/pipermail/eg-oversight-board/2015-September/001114.html |
14:06 |
tspindler |
I think it worked well over all. Gives us some different options if you want to use it |
14:06 |
yboston |
I thought it worked well. Might want to test it with more people at once to be safe |
14:06 |
montgoc1 |
I agree. Seemed like it would be fine. |
14:07 |
yboston |
I bet it would be fine |
14:07 |
abneiman |
I'm on record before but I like the audio convo better than IRC, I'm more comfortable speaking extemporaneously than typing. Agree on testing with more members. |
14:07 |
rfrasur |
And, was the idea that it supports voice and it's recordable? |
14:07 |
tspindler |
rfrasur: yes |
14:08 |
* rfrasur |
is just restating for the log. |
14:12 |
rfrasur |
Let's shoot for October if all are amenable. |
14:12 |
montgoc1 |
Sure. |
14:13 |
sherbertbc_ |
I'm n/a Oct 15, our annual all staff, but go ahead w/o me! |
14:13 |
bshum |
tspindler: Along the way, for those of us who weren't part of the original trial (me, for example, I'm such a slacker), I wonder if we could ask you to help set up another test in between now and then. |
14:13 |
abneiman |
10/15 should be OK with me |
14:13 |
yboston |
that date works for me |
14:13 |
bshum |
And we can do a dry run so to speak of the board procedures. |
14:14 |
tspindler |
bshum: i think i could squeeze a date in, I may just have to schedule it and hope it works |
14:14 |
rfrasur |
+1 |
14:14 |
bshum |
tspindler: That'd be fine, and I will hopefully find myself available this time around. |
14:14 |
tspindler |
how is the week of October 5 for a test run? |
14:15 |
bshum |
tspindler: Depends on the day of the week for me. |
14:15 |
rfrasur |
That Monday, Thursday, or Friday are fine. |
14:15 |
tspindler |
I could set up for Thursday, October 8 at 2PM EST if that works for a test for anyone |
14:15 |
bshum |
Thursday or Friday afternoon work for me |
14:15 |
bshum |
I think there's an academics meeting on that Thursday |
14:15 |
sherbertbc_ |
Mon or Fri |
14:18 |
tspindler |
rfrasur: +1 |
14:18 |
montgoc1 |
rfrasur: +1 |
14:18 |
|
maryj joined #evergreen |
14:19 |
bshum |
#info Pre-meeting practice for GoToWebinar to occur at 1:30 pm Eastern on October 15 prior to the regular EOB meeting. |
14:19 |
bshum |
Cool deal, thanks all, and hopefully we get some good feedback on how that next meeting's test goes via audio. |
14:19 |
bshum |
Anything further on that for now? |
14:19 |
rfrasur |
And tspindler, you send out the join link? |
14:19 |
tspindler |
rfrasur: yes, I'll do that |
14:19 |
rfrasur |
tspindler++ |
16:24 |
miker |
or not |
16:24 |
miker |
bshum++ # thanks |
16:25 |
|
jlitrell joined #evergreen |
16:44 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
16:45 |
kmlussier |
Huzzah! |
16:55 |
phasefx |
yay |
16:57 |
phasefx |
those unrecognized value "" for "ECHO"; assuming "none" warnings are also relatively new, and introduced with a change in psql |
09:21 |
kmlussier |
dbwells: Yes, they are. I just have the Default one set to True. |
09:22 |
kmlussier |
Thanks dbwells! While you're looking at it, I was thinking it might be better if the warning said "Voiding these bills may violate local policy by producing a negative balance." Our users like lots of clarity in their messages. :) |
09:24 |
* mmorgan |
is wondering about the use of the term "local policy" here. |
09:24 |
kmlussier |
dbwells: Ugh. Never mind! I just realized I loaded the wrong branch on the server. Sorry! |
09:26 |
kmlussier |
dbwells: Scratch that last comment. It is the correct branch. |
09:26 |
kmlussier |
This is what happens when kmlussier tests without coffee. |
09:26 |
mmorgan |
I agree with kmlussier - lots of clarity for users. |
09:26 |
mmorgan |
@coffee kmlussier |
09:26 |
* pinesol_green |
brews and pours a cup of Panama Esmeralda Mario Carnival, and sends it sliding down the bar to kmlussier |
09:27 |
mmorgan |
Maple cream? Wow. |
09:29 |
kmlussier |
mmorgan: For a limited time only! |
09:29 |
dbwells |
kmlussier: Are the menu options showing and hiding as expected? |
09:30 |
kmlussier |
dbwells: I'm testing that now. |
09:30 |
mmorgan |
You can always tell what season it is by looking at the coffee flavors available :) |
09:31 |
mmorgan |
Just my $.02 about the warning message, I'd find this clearer "Voiding these bills may produce a negative balance. Are you sure you wish to continue?" |
09:32 |
kmlussier |
dbwells: Yes. The void option is gone now that I've removed the void permission. |
10:55 |
jeff |
(but hasn't been able to mine enough tuits to have a useful contribution to the conversation at hand) |
11:01 |
jeff |
Though I should probably at least note that my dislike statement above is at least somewhat unclear / ambiguous. |
11:02 |
kmlussier |
jeff: Well, the voiding behavior doesn't change at all from what we currently do. Which is why I'm looking at ways to make sure libraries can keep their staff away from it while also not losing the ability to do things that they currently can do. |
11:06 |
dbwells |
kmlussier: Dyrcona: I probably won't have time to work on this more today. I think the current branch is highly functional and seems to be not breaking, so I'd like to see it pushed sooner rather than later. (This is not a statement about overall release-readiness, which I leave entirely up to Dyrcona.) Thanks for testing! |
11:07 |
|
RoganH joined #evergreen |
11:10 |
bshum |
miker: https://bugs.launchpad.net/evergreen/+bug/1483857 got marked fix committed, but I don't see a corresponding commit to master or a milestone assigned to the bug. |
11:10 |
pinesol_green |
Launchpad bug 1483857 in Evergreen "Web based staff client in house use barcode box clear" (affected: 2, heat: 10) [Undecided,Fix committed] |
11:28 |
jeff |
kmlussier: it's my understanding that currently it's frowned upon to push to master around/near release time without coordination with the RM. i could be wrong. |
11:28 |
bshum |
jeff: Huh? |
11:29 |
bshum |
Oh hmm.... |
11:29 |
kmlussier |
jeff: Ah, ok. But if it were another say, say next week, miker could just push those changes to master since he's reviewed and tested them, couldn't he? |
11:29 |
kmlussier |
Apologies for garbling that sentence, but y'all know what I mean. |
11:29 |
miker |
also, they haven't been pushed to webby for broader testing yet |
11:34 |
miker |
if 2.9 is cut later than today (but don't delay for those minor fixes alone, please!) then broader testing will be applied, and I will push them to master for good and all |
11:42 |
kmlussier |
dbwells / Dyrcona: I've been waiting to hear back from one other person to get a sense of how often the void option in Full Details is used. And it may be too late to give feedback if Dyrcona has already started release cutting. |
11:43 |
kmlussier |
dbwells / Dyrcona: My personal opinion right now is, to truly prohibit negative balances we we had hope to do, we will need to remove that void permission from our users. And when we remove that void permission, they will lose the ability to do something they previously could do. It's a regression. |
11:44 |
kmlussier |
My preference is that they don't lose any functionality when the .0 release is out. But I leave it in the hands of our fearless RM to make the final decision. |
12:37 |
miker |
if you don't use circ_mod much in other rules, that might do it |
12:38 |
dbs |
bshum: should make things a lot easier for people who want to tailor templates without worrying about breaking the embedded metadata, so would be worth it I think |
12:39 |
Bmagic |
miker: right now, we have about a 50/50 split of rules that mention circ mod and those that dont |
12:40 |
miker |
Bmagic: if the rule in question is the only one using that particular circ_mod, it still might be OK |
12:40 |
miker |
testing would tell, obv |
12:41 |
Bmagic |
right on |
12:42 |
Bmagic |
it would be neat if there was a mechanizm for "pickup library is NOT x" |
12:43 |
Dyrcona |
miker gmcharlt: I'm in favor of web staff client fixes being treated like normal bugs and have considered saying it would be OK to backport them to rel_2_9 once it is branched. |
12:55 |
miker |
I can be in a position soon ... in, say, 15min |
12:55 |
Dyrcona |
OK. I can wait. |
12:55 |
Dyrcona |
I'd prefer to have as much as possible in master before branching. |
12:56 |
miker |
Dyrcona: and, to be clear, I'd like to push the top 6 commits of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/sprint2-fixes ... the first 4 are from this morning, the next 2 are fixes that are widely tested |
12:57 |
Dyrcona |
OK. That works for me. |
12:58 |
miker |
where "widely" means "by more than the author, and don't break webby" |
12:59 |
Dyrcona |
:) |
12:59 |
Dyrcona |
Should I use Chrome when testing the web staff client? |
12:59 |
Dyrcona |
Or, do you want it to work with Firefox, too? |
13:00 |
miker |
both ideally, but chrome is moar better in general |
13:00 |
Dyrcona |
Thanks! That is what I thought. |
14:13 |
bshum |
Does anyone remember offhand what a hold status of -1 means? I know it's indicative of some sort of error failure, I just don't recall the exact nature of it. |
14:14 |
Dyrcona |
The hold is in an invalid state. |
14:14 |
Bmagic |
bshum: I had this question a few weeks ago...... now I forget what the answer was, lol. Apparently it was important. Let me look back |
14:14 |
jeff |
only displayed in the staff client, it's "something isn't what i expect" |
14:15 |
jeff |
it's set to "-1" at display time as a fall-through after several conditional tests. |
14:15 |
Dyrcona |
Typically happens when some field has or is missing a value that it shouldn't because of other values in the hold request. |
14:15 |
berick |
usually a mismatch between copy status and hold disposition |
14:22 |
bshum |
Okay, 2.7.8 is all set. But I'll wait to update the downloads page for now. |
14:43 |
kmlussier |
Dyrcona: I do have some changes I need to make to the 2.9 release notes. I think I'm done with the neg balance additions from today's branch, but I also need to add acknoledgements. I'll remove those bug fix release note entries at that time. |
14:43 |
Dyrcona |
OK. Works for me. |
14:44 |
* kmlussier |
will first grab the tea that is probably getting cold by now. :) |
14:51 |
jeffdavis |
dbwells: I was finally able to apply your fix for bug 1484989 on a test server. After applying the commit, lost transactions are being closed when the item is checked in and the fine balance hits zero, which is what we want. |
14:51 |
pinesol_green |
Launchpad bug 1484989 in Evergreen 2.8 "Fines are not calculating until after circulation is closed" (affected: 1, heat: 6) [Medium,Fix committed] https://launchpad.net/bugs/1484989 |
14:51 |
jeffdavis |
dbwells: However, that behavior still does not seem to be governed by the circ.lost.xact_open_on_zero setting, which is what we expected (i.e. the circs are closed even when that setting is true). |
14:52 |
jeffdavis |
I haven't replicated our original problem on a stock 2.8 install though. |
16:03 |
Bmagic |
yep |
16:03 |
pinesol_green |
[evergreen|Kathy Lussier] Additions to the 2.9 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c06390> |
16:03 |
Bmagic |
I reloaded the patron in a new tab just to make sure |
16:04 |
kmlussier |
Release note changes are pushed. One change I made to the acknowlegements is that we are thanking people for contributions to tests as well as code and doc patches. |
16:04 |
Bmagic |
I tested it on a non-lost circ, and it did increase the count |
16:04 |
Dyrcona |
kmlussier++ |
16:04 |
Bmagic |
kmlussier++ |
16:04 |
mmorgan |
kmlussier++ |
16:43 |
kmlussier |
As usual, when working on acknowledgements, it was great to see all the different types of organizations big and small that went into making this Evergreen release. A big y'all++ |
16:43 |
kmlussier |
And an even bigger Dyrcona++ |
17:08 |
|
mmorgan left #evergreen |
17:19 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:32 |
pinesol_green |
[evergreen|Remington Steed] Docs 2.9: Update and add detail for Holdings Import profile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=584dfb9> |
17:46 |
pinesol_green |
[evergreen|Jason Stephenson] Porting 2.8.4->2.9.0 SQL upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=69bb3ce> |
17:48 |
pinesol_green |
[evergreen|Jason Stephenson] Forward port 2.9.0 translations. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d40524> |
18:13 |
Dyrcona |
Well, I hope that's that. |
18:16 |
pinesol_green |
[evergreen|Jason Stephenson] 2.9 Release notes creation and cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d10f91> |
18:26 |
kmlussier |
Dyrcona++ |
23:14 |
bshum |
Well, maybe. |
23:15 |
kmlussier |
bshum++ |
23:16 |
bshum |
"And now his watch is ended." (almost, almost....) |
23:27 |
jeff |
what's the bar for "commissioned developments"? |
23:27 |
jeff |
oh, and is there a better method for me to help fix this typo than just mentioning it here? "individuals who contributed code, documentations patche and tests to this release" :-) |
23:27 |
jeff |
(first question is just one of curiosity, not thinking that there was an omission or anything) |
23:28 |
kmlussier |
jeff: Organizations that contracted for development work that made it into the release. |
23:29 |
kmlussier |
In the case of this release, we have organizations that paid for development through Equinox, Sigio, and Catalyst. |
23:30 |
bshum |
I think it covers the base of funding partners who don't get their names/organizations represented with the actual authoring/testing/signoff/committing. |
23:30 |
kmlussier |
Basically, it's a way to give credit to organizations that may not have the development staff to contribute code, but made one of the features happen through funding. |
23:33 |
kmlussier |
bshum: Did you already update the release notes with my feature? If not, can you fix my typo? |
23:33 |
bshum |
kmlussier: Already updated, but we can do another one... |
01:39 |
|
Mark__T joined #evergreen |
03:03 |
|
gsams joined #evergreen |
05:21 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
06:33 |
|
TaraC joined #evergreen |
07:32 |
|
jboyer-isl joined #evergreen |
07:56 |
|
rlefaive joined #evergreen |
09:00 |
Dyrcona |
I'm looking into LP 1494427. |
09:00 |
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:00 |
Dyrcona |
It looks like something quick I can do before the rest of my day gets swallowed whole by meetings. |
09:01 |
Dyrcona |
And one barcode shows up at least three times, think I'll test with that patron. |
09:06 |
|
mmorgan left #evergreen |
09:08 |
|
yboston joined #evergreen |
09:16 |
pinesol_green |
[evergreen|Kathy Lussier] lp1494427: Fix refund error - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4efea97> |
10:25 |
bshum |
When we touch the same table a couple times during the same major upgrade |
10:25 |
bshum |
Cause the minor upgrade scripts do stuff |
10:25 |
csharp |
well, it looks like we'll need to change the script so that it doesn't do that in the same transaction |
10:25 |
bshum |
Usually, only live testing reveals it, and then the RM can make necessary edits to the upgrade script |
10:26 |
csharp |
ok, so bug report? |
10:26 |
bshum |
And either combine necessary changes into one SQL update, or break it up into stuff inside and outside the main body transaction |
10:27 |
|
Christineb joined #evergreen |
11:12 |
Stompro |
mmorgan, does printing the list of holds work for you on your self checks(EG web based self check)? It doesn't work for me with a default setup. |
11:13 |
bshum |
Stompro: Do you have popups disabled? |
11:14 |
Stompro |
bshum, the other print lists work fine, printing list of items out and fines work. Popups are allowed. |
11:15 |
bshum |
Stompro: Do you have any sort of browser error logging? Maybe it could indicate if it's a specific failure somewhere in the execution |
11:15 |
* bshum |
hasn't tested hold printing lately |
11:15 |
Stompro |
bshum, thanks I'll enable the JS log and see what it says. |
11:17 |
bshum |
length of undefined |
11:17 |
bshum |
That's helpful... |
12:33 |
|
pmurray left #evergreen |
12:39 |
|
rlefaive joined #evergreen |
12:45 |
|
bmills joined #evergreen |
13:04 |
* mmorgan |
reads up. |
13:05 |
mmorgan |
Glad Stompro and bshum found the hold slip printing bug. It really hasn't been much of an issue for us for the reason Stompro mentioned. |
13:06 |
mmorgan |
Can anybody point me to some fairly concise guidelines for setting up credit card processing using paypal? |
13:08 |
mmorgan |
We have a training system set up with a paypal sandbox, but aren't having any success testing payments. |
13:14 |
kmlussier |
mmorgan: I thought there was a message on the mailing list that had a concise list of steps, but I don't see it now. |
13:14 |
kmlussier |
mmorgan: I once successfully used the paypal sandbox with Evergreen, but it was so long ago, I don't recall what I did. I remember I was a bit confused on the PayPal side of things. |
13:16 |
mmorgan |
kmlussier: Right now I'm a bit confused on both sides! ;-) |
13:36 |
|
Dyrcona joined #evergreen |
13:36 |
jeffdavis |
^ Noted here so that it's in the logs. I haven't reproduced on a stock EG install yet, so no LP bug so far. |
13:43 |
jeff |
jeffdavis: on the system where you're seeing this, is it affecting most/all bookbags, or just some/one? |
13:43 |
jeffdavis |
All the ones I've tested so far, but my testing pool has been fairly small. |
13:44 |
jeff |
seq scan on asset.copy -- ouch. |
13:46 |
jeffdavis |
The filter there is on two boolean columns though, so it seems like the solution isn't an index but reducing the number of rows scanned. |
13:49 |
|
maryj joined #evergreen |
14:03 |
jeffdavis |
csharp: Interesting! You folks are on PG 9.4, right? |
14:03 |
csharp |
9.3, currently |
14:03 |
jeffdavis |
ah nope, I see 9.3 in the bug :) |
14:03 |
csharp |
testing on 9.4 as we speak, though |
14:03 |
jeff |
jeffdavis: what are you guys on? |
14:04 |
jeffdavis |
we're 9.4 |
14:04 |
csharp |
jeffdavis: see the suggestions from miker in the last comment on the bug report - they didn't solve my issue, but may help yours |
14:04 |
jeffdavis |
csharp: I see miker suggested adjusting stats on one of the tables there, have you tried that? |
14:04 |
csharp |
heh - yep |
14:04 |
csharp |
they didn't solve the problem, so I let it go |
14:05 |
csharp |
actually, I haven't tested it since we purged most of our holds data |
14:05 |
csharp |
it's probably fixed |
14:07 |
csharp |
nope - stats are still borked for me on that query |
14:07 |
csharp |
it is faster, though |
14:07 |
miker |
jeffdavis: your modification looks like it's just joining call number before location. I wonder if the underlying json_query can just be adjusted to do that. where is the code for that query, if you know off hand? |
14:07 |
csharp |
in my case, it's vastly overestimating the number of rows |
14:09 |
jeffdavis |
miker: not sure yet - figuring that out is the next step on my todo list for that bug :) |
15:59 |
|
maryj joined #evergreen |
16:26 |
|
bmills joined #evergreen |
16:30 |
|
ericar joined #evergreen |
16:35 |
* kmlussier |
grabs the code from bug 1494544 to get a Sandbox set up for testing later this evening. |
16:35 |
pinesol_green |
Launchpad bug 1494544 in Evergreen "Void options in the billing UI allow negative balances to occur when they should be prohibited" (affected: 1, heat: 6) [Critical,Confirmed] https://launchpad.net/bugs/1494544 - Assigned to Dan Wells (dbw2) |
16:36 |
kmlussier |
dbwells++ |
16:37 |
|
Christineb joined #evergreen |
16:40 |
* kmlussier |
also grabs the code from bug 1340852 in the hopes of getting jlitrell's first contribution into Evergreen. :) |
16:40 |
pinesol_green |
Launchpad bug 1340852 in Evergreen "Copy Location Groups search not retaining original search params after searching" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1340852 |
16:53 |
jlitrell |
Huzzah! |
17:04 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:04 |
|
mmorgan left #evergreen |
17:34 |
Bmagic |
Has anyone tackled sending automated emails to patrons on a regular basis showing how much to owe? I can't imagine an action trigger doing this. Any thoughts? |
17:35 |
Bmagic |
how much they* owe |
01:30 |
|
Mark__T joined #evergreen |
01:42 |
|
dac joined #evergreen |
04:38 |
|
book` joined #evergreen |
05:06 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
07:00 |
|
_bott_ joined #evergreen |
07:22 |
|
rlefaive joined #evergreen |
07:40 |
|
sarabee joined #evergreen |
11:26 |
bshum |
Stompro: That might be the case, I've honestly always used a workstation with our web-based selfchecks. |
11:26 |
bshum |
I can't recall if it's a library setting that forces you to register a workstation via the selfcheck |
11:26 |
bshum |
It might be. |
11:28 |
mmorgan |
Stompro: Just gave this a test on a training server, and the circulation got NULL as the workstation. |
11:29 |
Stompro |
mmorgan, thanks for testing it, I just want to get the facts right for what I'm going to add to the docs. |
11:29 |
mmorgan |
We also require a workstation for self check. |
11:30 |
mmorgan |
Stompro++ # getting the facts right! |
11:31 |
Stompro |
mmorgan, I'm not sure why you wouldn't set a workstation, but the default option is to not require a WS. Why would you want to remember that self check circs are the ones without a NULL WS for that location. |
11:50 |
jeff |
a new OpenILS::Application::Circ::Circulator object is either passed a circ_lib, or it gets its circ_lib from the user session's ws_ou, which defaults to the user's home_ou if there is no workstation associated with the user's session. That default behavior is part of open-ils.auth |
11:51 |
jeff |
As for "does anything in stock pass a circ_lib as an argument to one of the API methods that create Circulator objects to do their work?"... I didn't look. :-) |
11:51 |
Stompro |
jeff++ thanks |
11:52 |
mmorgan |
Stompro: Testing shows that the circ_lib in the transaction comes from the workstation, too :) |
11:56 |
bshum |
svn-- git++ |
11:56 |
bshum |
Why is this so hard??! |
11:57 |
Stompro |
mmorgan++ for testing things all the time. |
11:58 |
* mmorgan |
likes to get the facts right, too. |
11:58 |
jeff |
bshum: what are you struggling with? |
11:58 |
bshum |
jeff: Just trying to get an svn diff from two revisions to try seeing what's changed for a given file. |
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 |
15:32 |
mmorgan |
jhpringle: Bmagic: fwiw, our circ.lost.generate_overdue_on_checkin is not set. We aren't seeing the same problem. |
15:33 |
dbwells |
Actually, that commit may be unreleased, but it is committed for 2.8.4. |
15:33 |
mmorgan |
jihpringle, that is. Are any fines involved in your situation? |
15:34 |
jihpringle |
usually in the examples libraries have sent us but not in our tests |
15:34 |
Bmagic |
if there are bills that do not get voided as part of the checkin proceedure, then everything is fine. You just pay/void those bills later, and the circulation is closed and removed. Its only when the checkin proceedure voids ALL of the bills and the transaction should be closed, it's not closed |
15:35 |
jihpringle |
we can check out the item, set it to lost, and then checkin and reproduce the issue all in a couple minutes |
15:35 |
Bmagic |
jihpringle: Oddly enough, we had circ.lost.generate_overdue_on_checkin set to false the whole time, and have the issue, I changed it to true, and the bug went away |
15:37 |
Bmagic |
jeffdavis: she said it wasn't showing itself in 2.8. It's 2.8.1 and higher |
15:39 |
dbwells |
jeffdavis: can you try commit 4357ab325959f2ed48 and see if it helps? I am guessing this is already fixed under different symptoms. |
15:39 |
pinesol_green |
[evergreen|Dan Wells] LP#1484989 Don't close xacts with checkin-generated fines - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4357ab3> |
15:39 |
jeffdavis |
dbwells: yep, I will be testing that asap |
15:39 |
dbwells |
jeffdavis: looking forward to hearing back, thank you |
15:40 |
jeffdavis |
thanks for the pointer :) |
15:42 |
bshum |
dbwells: I'm following the discussion on bug 1494544 and I wonder, do you think it'd be hard to base display of the different buttons based on the actual settings used? |
15:42 |
pinesol_green |
Launchpad bug 1494544 in Evergreen "Void options in the billing UI allow negative balances to occur when they should be prohibited" (affected: 1, heat: 6) [High,Confirmed] https://launchpad.net/bugs/1494544 |
15:42 |
jeffdavis |
Bmagic: our stock test server is running 2.8.1 fwiw |
15:42 |
bshum |
Like if prohibit negative balances is engaged, don't display the void buttons. |
15:42 |
bshum |
Rather than basing it entirely on just permissions on the users. |
15:43 |
bshum |
I just worry about policing the permissions over use of the settings, which are a lot simpler to enact initially. |
16:08 |
kmlussier |
dbwells: Also, you're right about the ADJUST_BILLS permission allowing/disallowing the adjust to zero action. I thought I saw the word "void" in the message that appeared, but it was late at night. Must have been seeing things. |
16:09 |
kmlussier |
But it looks like the permission didn't make it into the seed data. |
16:09 |
* kmlussier |
will add that correction to the lp bug. |
16:09 |
* bshum |
probably tested everything using a superuser :( |
16:09 |
* bshum |
hates permissions |
16:10 |
dbwells |
kmlussier: great, thank you also for following up |
16:10 |
bshum |
Well I hate permission wrangling. |
16:10 |
kmlussier |
bshum: Well, then, you can just give Everything to all of your users and see what fun ensues. :) |
16:16 |
mmorgan |
kmlussier: Think I just fixed that. |
16:16 |
kmlussier |
mmorgan++ |
16:17 |
kmlussier |
Stompro++ # Moving good tips into the official docs. |
16:17 |
Bmagic |
dbwells: that patch fixes the checkin issue on our test machine |
16:17 |
mmorgan |
Stompro++ |
16:17 |
dbwells |
Bmagic: sweet, glad to hear it |
16:17 |
Bmagic |
dbwells++ mmorgan++ jihpringle++ bshum++ jeffdavis++ |
16:37 |
|
bmills joined #evergreen |
16:45 |
|
gdunbar joined #evergreen |
16:53 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
16:55 |
Dyrcona |
Ha ha! |
16:55 |
Dyrcona |
Now it is getting the xmlns attribrute in ever tag. |
16:56 |
Dyrcona |
You just /have/ to /love/ tests! |
16:57 |
Dyrcona |
Too late in the day to fix it, now. |
16:59 |
dbwells |
I looked at that a bit in the first round, and my feeling is that Dyrcona may be right about this being a change in the underlying XML library which is bubbling up. |
17:08 |
|
mmorgan left #evergreen |
17:16 |
phasefx |
jfyi, I fixed HTML escaping for the test output webifier, so we can actually see the xmlns stuff from the web page for that failed test |
17:18 |
pinesol_green |
[evergreen|Angela Kilsdonk] Docs: 2.9 Updates to OPAC documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f5140d5> |
17:22 |
pinesol_green |
[evergreen|Angela Kilsdonk] Docs: 2.9 Purchase Order Activation Progress Bar - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=23f8679> |
19:06 |
|
bmills joined #evergreen |
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 ? |