Time |
Nick |
Message |
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 |
07:59 |
|
rjackson_isl joined #evergreen |
08:05 |
|
ericar joined #evergreen |
08:09 |
|
collum joined #evergreen |
08:22 |
|
mrpeters joined #evergreen |
08:37 |
|
phasefx joined #evergreen |
08:49 |
|
mmorgan joined #evergreen |
09:10 |
|
Dyrcona joined #evergreen |
09:13 |
|
maryj joined #evergreen |
09:18 |
|
yboston joined #evergreen |
09:53 |
|
ericar_ joined #evergreen |
10:14 |
Dyrcona |
gmcharlt: I assume it is OK to remove your assignment on lp 1495509 |
10:14 |
pinesol_green |
Launchpad bug 1495509 in Evergreen "webstaff: merge more sprint 2 (cataloging) work into master for 2.9.0" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1495509 - Assigned to Galen Charlton (gmc) |
10:19 |
gmcharlt |
Dyrcona: yep |
10:20 |
Dyrcona |
Thanks. I'll have a look at the branches in a bit. |
10:26 |
gmcharlt |
Dyrcona++ |
10:30 |
|
rlefaive joined #evergreen |
10:46 |
Dyrcona |
gmcharlt: https://bugs.launchpad.net/evergreen/+bug/1495509/comments/2 |
10:46 |
pinesol_green |
Launchpad bug 1495509 in Evergreen "webstaff: merge more sprint 2 (cataloging) work into master for 2.9.0" (affected: 1, heat: 6) [Wishlist,New] |
10:50 |
Dyrcona |
Hmm. Wonder if that works on Pg 9.4 but not on < 9.4? |
10:51 |
|
ericar_ joined #evergreen |
10:54 |
gmcharlt |
Dyrcona: looking |
10:57 |
Dyrcona |
I tried moving the check for thesauruses = '' inside the when but that didn't make a difference. |
10:58 |
gmcharlt |
what version of Pg are you using? |
11:01 |
tsbere |
gmcharlt: 9.1, I believe |
11:02 |
* tsbere |
should really plan to update that server at some point |
11:02 |
Dyrcona |
Yeah. I was just thinking, "How long would it take us to upgrade that server?" |
11:02 |
Dyrcona |
Yep it is 9.1 on db2.... |
11:04 |
gmcharlt |
Dyrcona: I've convinced myself it's specifically a 9.1ism; now seeing if I can make a quick fix |
11:06 |
yboston |
who can check for moderated messages in the DIG mailing list? is one of them csharp? I purposely sent a message to trigger moderation and wanted to know who would check those messages |
11:08 |
Dyrcona |
gmcharlt: Thanks! |
11:08 |
bshum |
yboston: http://wiki.evergreen-ils.org/doku.php?id=website_administration#individual_list_information |
11:08 |
bshum |
The moderators are marked "vacant" for the DIG list |
11:08 |
bshum |
but the admins are listed as csharp/phasefx |
11:08 |
bshum |
I'm sure csharp would be glad to have other folks added for the moderator roles :) |
11:09 |
bshum |
If you know of any volunteers. |
11:09 |
* gmcharlt |
can be added to that list |
11:09 |
gmcharlt |
yboston: and for that matter, if you want to be a moderator too... |
11:16 |
gmcharlt |
Dyrcona: OK, I've pushed a patch fixing the problem to the tip of that working branch |
11:16 |
|
Christineb joined #evergreen |
11:17 |
yboston |
bshum: I never new that page existed, good to know |
11:18 |
yboston |
I would like to be added as a moderator, maybe remingtron could be be too if he is up to it |
11:18 |
bshum |
yboston: We haven't kept it as well maintained, but the idea originated ages ago to try tracking all the parts of our website infrastructure for the community. |
11:18 |
Dyrcona |
gmcharlt++ It is working. |
11:19 |
yboston |
Today I noticed that the footer of the offical docs point to the offical mailing email address. I wondered if there was a backlog of messages waiting for moderation |
11:20 |
yboston |
I'll message csharp |
11:21 |
remingtron |
bshum: I'm happy to let yboston handle it unless it becomes too burdensome for him |
11:22 |
Stompro |
Self check question, if you sign in to the self check without setting a workstation, does it use the signin staff users home library as the circ lib, and just leaves the workstation blank for the circulation? |
11:22 |
yboston |
remingtron: I can start by myself and see how much traffic we get |
11:23 |
Stompro |
I'm referring to the bult in web based self check btw. |
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:35 |
* bshum |
wrestles with svn |
11:37 |
mmorgan |
Stompro: I can't think of a use case for not using a workstation for self check. I think the only transactions that truly have a NULL workstation are web renewals. |
11:41 |
mmorgan |
Stompro: Just to confirm the other part of your question. circ_lib does come from the signed in user's home lib. |
11:41 |
Stompro |
mmorgan++ thanks, and if the workstation is set, that comes from the WS library, right? |
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. |
11:58 |
bshum |
In theory I thought it was something like "svn diff -r XXX:YYY filename" |
11:59 |
bshum |
But I get nothing when I do that. |
11:59 |
bshum |
So it's slowly driving me mad |
12:00 |
dbs |
"svn diff -r 410:412" works for the only svn repo I have left that I use |
12:00 |
dbs |
"svn log" lists the revisions as r410, r411, r412, so don't put the "r" in |
12:01 |
bshum |
dbs: Yep, that's what I've been attempting, without the leading r's |
12:01 |
bshum |
dbs: I'm toying with trying to actually see what diffs occurred in the evergreen.ledger file, whee.... |
12:01 |
dbs |
bshum: ah right |
12:01 |
bshum |
But svn hates me |
12:02 |
Dyrcona |
bshum: It senses your hostility. :) |
12:02 |
bshum |
At the root level, it won't let me do a compare cause of permissions it seems. |
12:02 |
bshum |
Or some other weird error |
12:02 |
dbs |
bshum: I tried to convince bkuhn it would be okay to use git, but at that point it was still relatively early git days for me, so he went with svn to be kind (IIRC) |
12:03 |
dbs |
bshum: so, do an svn2git thing and then you can git away to your heart's content :) |
12:03 |
bshum |
dbs: I'm literally reading up on that next :) |
12:04 |
jeff |
I've found svn diff -c NUMBER useful. |
12:04 |
* dbs |
actually has a local svn2git version (outdated) of the Evergreen-Conservancy account, probably for that very reason |
12:04 |
jeff |
"show me what changed in revision NUMBER" |
12:04 |
jeff |
also is accepting/forgiving of a leading r, for easy copy-paste of revision from svn log. |
12:04 |
dbs |
yeah, equivalent of "git show <hash>" |
12:04 |
dbs |
jeff++ |
12:05 |
* dbs |
remembers when git was the scary thing :) |
12:05 |
jeff |
also accepts a filename if you want to limit it to that filename. |
12:05 |
gmcharlt |
:) |
12:05 |
bshum |
dbs: It seems to me that if "Git" is a member of Conservancy, we should be using git. But I'll add that to my suggestion box submissions... |
12:05 |
bshum |
And yeah, I used svn back in the day when I first worked on website stuff |
12:06 |
bshum |
So I should know this, but I'm super rusty |
12:06 |
bshum |
And it hates me |
12:08 |
Dyrcona |
I never really used svn much, but I still use cvs for OpenBSD. |
12:08 |
bshum |
I also went through a whole to-do because they changed their servers recently. |
12:13 |
|
jihpringle joined #evergreen |
12:23 |
dbs |
bshum: Mercurial is a member of Conservancy too, so maybe they're trying not to play favourites. Heh. |
12:23 |
bshum |
Heh, perhaps. |
12:27 |
bshum |
And now that it's in git, I got exactly what I've been looking for. |
12:37 |
* mmorgan |
is looking at user circ and holds history settings. |
12:37 |
mmorgan |
For circs, there are usr_setting_types for retention_start and retention_age. |
12:38 |
mmorgan |
For holds, there are setting types for retention_start, retention_age, and retention_count |
12:38 |
mmorgan |
The only setting types I can see that can be set for users are history.circ.retention_start and history.holds.retention_start. Only these appear in actor.usr_setting. Are the other setting types used anywhere? |
13:03 |
|
rlefaive joined #evergreen |
13:11 |
dbs |
bshum: Oh, and Darcs too. |
13:22 |
|
maryj joined #evergreen |
14:12 |
kmlussier |
To add on to mmorgan 's aging circ questions, we noticed that when a circ is aged, any money entries attached to the circ are removed from the money.materialized_billable_xact_summary tables, which means libraries can't report on that money once a circ is aged. |
14:12 |
csharp |
yep |
14:12 |
kmlussier |
How have other sites handled this issue? |
14:13 |
csharp |
we just let people know that was going to happen and had them get what they needed while the data was still there |
14:13 |
* csharp |
is working on a to-be-published data retention policy |
14:13 |
|
rlefaive joined #evergreen |
14:14 |
* kmlussier |
will be interested in seeing that policy when it is published. |
14:15 |
csharp |
wow - I should say "was working on" since the last edit to that Google doc ;-) |
14:15 |
csharp |
... was in September 2013 |
14:16 |
kmlussier |
One thought we had is that it might be better for purge_circulations update the usr field to null rather than remove that entry from the money table. |
14:16 |
kmlussier |
csharp: Two years? Feels just like yesterday. :) |
14:16 |
csharp |
actually, it really does |
14:18 |
kmlussier |
csharp: Yup. That's also the month when a bunch of us gathered together to build a responsive catalog and to set a direction for the client. |
14:18 |
csharp |
exactly |
14:18 |
kmlussier |
Anyway, I wanted to throw that idea out there to see if it would be a "bad thing" to set the usr field in that table to null when aging circs. |
14:19 |
csharp |
maybe a "preserve billing data" YAOUS? |
14:19 |
* csharp |
doesn't want to keep that billing data around |
14:21 |
kmlussier |
csharp: Thanks for that feedback. It's good to know that everyone wouldn't want to retain that data. |
14:37 |
jeff |
some may want to retain the user's home_ou even if the usr is nulled. |
14:38 |
jeff |
also, if mmpbbt makes it into the next version of evergreen that could be adjusted to meet "reporting on aged data" needs. |
14:39 |
* Dyrcona |
is waiting for ackthppt to make it in. |
14:39 |
jeff |
:-) |
14:39 |
Dyrcona |
That's in the hairball, not the tarbal, btw. :) |
14:44 |
* mmorgan |
reads backscroll, carefully stepping over the hairball. |
14:45 |
kmlussier |
jeff: They should be able to get the home_ou from action.all_circulation . |
14:46 |
kmlussier |
Ewwww. Hairballs. |
14:46 |
mmorgan |
Regarding the money when circs are aged, rows are removed from money.billable_xact and money.materialized_billable_xact_summary, but the rows in money.billing and money.payment remain. |
14:47 |
mmorgan |
Wondering if that data can give us whatever reports we need. |
14:50 |
* csharp |
is soooo glad he no longer has cats :-) |
14:50 |
gmcharlt |
HERESY |
14:50 |
gmcharlt |
;) |
14:51 |
mmorgan |
=-O |
14:51 |
csharp |
gmcharlt: I like pictures of *your* cats - just not real-life cats I have to take care of :-D |
14:51 |
gmcharlt |
heh |
14:51 |
mmorgan |
cats++ |
14:51 |
|
maryj joined #evergreen |
14:51 |
bshum |
I like my PINES cat. Very low maintenance. And very well behaved. |
14:52 |
csharp |
mmorgan: actually yes - if I recall correctly, the transaction ID is preserved |
14:52 |
csharp |
so they should still link |
14:52 |
csharp |
but I'm happy to be corrected ;-) |
14:53 |
csharp |
bshum++ # that's enough cat for me |
14:54 |
csharp |
I'm pretty sure my professional organizer wife "decluttered" my PINES kitten years ago :-/ |
14:54 |
bshum |
We need more Evergreen swag. |
14:55 |
csharp |
webby the duck! |
14:55 |
bshum |
That should go on the EOB agenda... demands for more swag from the Merchandising committee. |
14:57 |
kmlussier |
Oh, I was just thinking of swag I wished we had, but I can't recall what it was now. |
14:57 |
gmcharlt |
speaking of cats *grumble* *grumble* ... moar coffee cups would be good |
15:39 |
|
ldw joined #evergreen |
15:41 |
Dyrcona |
grabbing 0942 and 0943 |
15:50 |
csharp |
okay - just asking the collective here... I have a big pile of customizations on top of 2.7.2 that I want to put on top of 2.9.X - the way I handled this before was 'git rebase -i', but that creates duplicate commits (see here for a good summary of the issue: http://stackoverflow.com/questions/9264314/git-commits-are-duplicated-in-the-same-branch-after-doing-a-rebase) |
15:51 |
csharp |
that link's answer suggests a merge, but I've been warned off of git merge before (don't remember why not) |
15:51 |
csharp |
so I just wanted to know how others are managing this issue... do you just live with dupe commits, or do you merge, or what? |
15:52 |
bshum |
So what I usually do with dupe commits is I end up finding out what they are as I rebase, and start clipping those out of the rebase -i list before I go |
15:52 |
bshum |
That doesn't often happen to me anymore. |
15:52 |
bshum |
Because we get our stuff pushed more timely ;) |
15:53 |
bshum |
But uh, yeah, basically every time I get a git commit with empty on the rebase |
15:53 |
bshum |
I abort |
15:53 |
bshum |
Find the hash, and eliminate it from the next rebase |
15:53 |
csharp |
ok - that makes sense |
15:53 |
bshum |
Do you try a rebase first of your customizations from 2.7 to rel_2_7 too? |
15:54 |
bshum |
And then grab your commits and move over? |
15:54 |
* bshum |
also finds life is super awesome when you just have all your customizations built on master, period. |
15:54 |
bshum |
:D |
15:54 |
|
jlitrell joined #evergreen |
15:54 |
csharp |
well, I was envisioning something like that, but I hadn't gotten that far |
15:54 |
csharp |
I was just thinking high-level at the moment |
15:56 |
|
jwoodard_tablet joined #evergreen |
15:59 |
pinesol_green |
Showing latest 5 of 100 commits to Evergreen... |
15:59 |
pinesol_green |
[evergreen|Mike Rylander] webstaff: Remove dependency-suggesting indent from "Use checkdigit" default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e728e2e> |
15:59 |
pinesol_green |
[evergreen|Galen Charlton] webstaff: explicitly pass record type to MARC editor from Z39.50 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=61b801d> |
15:59 |
pinesol_green |
[evergreen|Galen Charlton] webstaff: update release notes for sprint 2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6651101> |
15:59 |
pinesol_green |
[evergreen|Galen Charlton] LP#1489955: tweak to work on PostgreSQL 9.1 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=96fdd22> |
15:59 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1495509: Stamping upgrade scripts. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9fe4a8> |
16:03 |
miker |
woo hoo! |
16:03 |
Dyrcona |
csharp: At MVLC, we base our custom branches on master. |
16:03 |
Dyrcona |
csharp: We tend to use rebase to keep them up to date. |
16:03 |
Dyrcona |
csharp: We use merge to build our branches for production, training, etc. |
16:03 |
Dyrcona |
miker++ phasefx++ gmcharlt++ berick++ |
16:03 |
gmcharlt |
Dyrcona++ |
16:04 |
miker |
Dyrcona++ # indeed |
16:04 |
Dyrcona |
Cataloging actually was useful this time. :) |
16:07 |
Dyrcona |
Oops. Made a typo in 002.schema.config.sql but it doesn't break anything. |
16:08 |
Dyrcona |
forgot the h in gmcharlt. |
16:09 |
pinesol_green |
[evergreen|Jason Stephenson] Fix typo in comment in 002.schema.config.sql. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=000cf61> |
16:09 |
gmcharlt |
Dyrcona++ # not that I minded, but I appreciate your concern for gettings folks' nicks right |
16:21 |
|
jwoodard_tablet joined #evergreen |
16:42 |
mmorgan |
What do others have set for the ou setting circ.item_checkout_history.max? I seem to remember a problem if this is set to zero, but can't remember what it was. |
16:45 |
bshum |
mmorgan: Ours is set to 3. |
16:45 |
bshum |
I imagine that if it were set to 0, you wouldn't see any prevoius checkouts in the staff client? |
16:46 |
mmorgan |
bshum: Yes, except what displays on the item summary alternate checkout history tab |
16:46 |
* bshum |
shrugs on that |
16:46 |
Bmagic |
mmorgan: We do not have a default consortium setting, 5 of our libraries have it set to various values (999,4,5,10) |
16:48 |
mmorgan |
We currently have it set to 1 for the consortium. |
16:49 |
kmlussier |
mmorgan: If you set it to zero, it still displays circs in that one tab on the item status screen. |
16:49 |
kmlussier |
mmorgan: But you just said that, didn't you? :) |
16:50 |
mmorgan |
kmlussier: Yes, the setting doesn't affect that tab. |
16:50 |
|
Christineb joined #evergreen |
16:51 |
Bmagic |
bshum: you had warned me that the JSPAC code is getting removed, it appears that none of the code that I am relying on has been removed by bug 1312309. Are there other bugs that I need to refer to in order to double check? |
16:51 |
pinesol_green |
Launchpad bug 1312309 in Evergreen "to remove last remnants of JSPAC" (affected: 3, heat: 14) [Wishlist,Fix committed] https://launchpad.net/bugs/1312309 |
16:51 |
mmorgan |
I think a problem is that a circ is a circ. There's no distinction between open and closed transactions as far as what can be visible. The last circ is the last circ whether it's open or closed. |
16:51 |
mmorgan |
It's not possible only to hide the closed transactions. |
16:51 |
bshum |
Bmagic: I think that was the big branch to be checked, so I'm glad. I thought that perhaps the bbags.js was being used by your carousel. |
16:52 |
bshum |
I thought that file went poof. |
16:52 |
Bmagic |
it did, but I wasnt using it |
16:52 |
bshum |
Oh, good then. |
16:52 |
Bmagic |
I took some of the code and created my own |
16:52 |
bshum |
:) |
16:53 |
Bmagic |
the code that I do is located here: /opac/common/js/ |
16:54 |
Bmagic |
utils.js config.js CGI.js slimtree.js JSON_v1.js fmall.js and so on. 12 files in total |
17:08 |
|
mmorgan left #evergreen |
18:38 |
jeff |
Bmagic: some of those will likely go when the xul client goes, but i suspect you'll notice that. :-) |
19:23 |
|
dcook joined #evergreen |
19:50 |
|
jwoodard_tablet joined #evergreen |
19:54 |
|
jonadab joined #evergreen |
20:54 |
kmlussier |
@librarian |
20:54 |
pinesol_green |
kmlussier: Management:14, Cataloging:11, Acquisitions:15, Reference:10, Circulation:13, Systems:11, Research:11, Custodial:10 |
20:56 |
kmlussier |
High on acq, low on custodial and cataloging. Sounds about right. |
21:23 |
|
sarabee joined #evergreen |
21:31 |
|
jwoodard_tablet joined #evergreen |
22:01 |
|
jwoodard_tablet joined #evergreen |
23:27 |
|
sbrylander joined #evergreen |