| Time |
Nick |
Message |
| 01:32 |
|
Mark__T joined #evergreen |
| 04:39 |
|
shadowspar joined #evergreen |
| 04:40 |
|
dbwells joined #evergreen |
| 04:41 |
|
remingtron joined #evergreen |
| 05:01 |
|
shadowspar joined #evergreen |
| 07:32 |
|
jboyer-isl joined #evergreen |
| 07:39 |
|
rjackson-isl joined #evergreen |
| 07:42 |
|
akilsdonk joined #evergreen |
| 08:09 |
|
kmlussier joined #evergreen |
| 08:17 |
|
kbeswick joined #evergreen |
| 08:53 |
|
Shae joined #evergreen |
| 08:54 |
|
collum joined #evergreen |
| 08:56 |
|
mdriscoll joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:09 |
|
kmlussier joined #evergreen |
| 09:13 |
|
ericar joined #evergreen |
| 09:16 |
|
mrpeters joined #evergreen |
| 09:19 |
|
6JTAAG4D3 joined #evergreen |
| 09:19 |
|
timf joined #evergreen |
| 09:37 |
|
RoganH joined #evergreen |
| 09:45 |
|
mllewellyn joined #evergreen |
| 10:34 |
|
timf joined #evergreen |
| 10:36 |
jboyer-isl |
senator++ for finding time to get Stripe integration solidified. |
| 10:37 |
senator |
jboyer-isl++ |
| 10:37 |
senator |
and atheos++ (good luck in TN) |
| 10:43 |
|
timlaptop joined #evergreen |
| 10:45 |
|
ericar joined #evergreen |
| 10:49 |
|
remingtron joined #evergreen |
| 11:11 |
|
fparks joined #evergreen |
| 11:18 |
kmlussier |
moodaepo++ # awesome work on the web site. |
| 11:32 |
pinesol_green |
[evergreen|Bill Erickson] ACQ general search sort funds; display year - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb27b41> |
| 11:33 |
|
smyers_ joined #evergreen |
| 11:38 |
|
remingtron joined #evergreen |
| 11:38 |
|
smyers_ joined #evergreen |
| 11:39 |
kmlussier |
Is there any chance that the fix to bug 1227344 also affected the fund dropdown in the Funding Source interface? Bug 1175293 describes the same problem showing up there. |
| 11:39 |
pinesol_green |
Launchpad bug 1227344 in Evergreen 2.4 "Funds missing year and not sorted in acq general search" (affected: 2, heat: 10) [Medium,Fix committed] https://launchpad.net/bugs/1227344 |
| 11:39 |
pinesol_green |
Launchpad bug 1175293 in Evergreen "ACQ: Allocate to Fund drop down menu (in Funding Source) Not Following Precedents Set by Other Fund Menus" (affected: 3, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1175293 |
| 11:41 |
dbwells |
kmlussier: No, it doesn't seem to fix it there, but the fix is probably really similar. |
| 11:44 |
kmlussier |
dbwells: ok, thanks! |
| 11:55 |
|
jdouma joined #evergreen |
| 12:14 |
pinesol_green |
[evergreen|Bill Erickson] Vandelay copy overlay call number merge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cd36c2e> |
| 12:25 |
|
kbeswick joined #evergreen |
| 12:41 |
jeff |
How do those here handle upgrades between major versions of Evergreen? Do you close your libraries? Do you fit the upgrade into times when you are already closed? Run in offline mode? Other? |
| 12:41 |
jeff |
I fully expect Dyrcona and bshum to say "we track master, and thus don't have all-at-once upgrade pain". ;-) |
| 12:43 |
Dyrcona |
Well, the pain is usually a lot less. |
| 12:43 |
Dyrcona |
Since we (at MVLC) keep a couple of development vms relatively up to date, we also know more what to expect. |
| 12:44 |
jeff |
right. |
| 12:44 |
tsbere |
jeff: Since you didn't expect *me* to say it, I will: we track master, and thus don't have all-at-once upgrade pain :P |
| 12:44 |
jeff |
tsbere++ |
| 12:44 |
* jeff |
grins |
| 12:45 |
Dyrcona |
I'm sure jeff does this, but if you do your own upgrades, it is a good idea to have a training/test server around to try the upgrade on before doing it for real. |
| 12:47 |
tsbere |
jeff: Generally we (which usually means I) do updates on a sunday evening, when libraries are already closed. That obviously doesn't work if your updates take all weekend....I know some others have done them over holiday weekends to reduce the amount of time libraries would be in offline mode. |
| 12:59 |
jeff |
we do try to test things beforehand, including with a snapshot of data and with staff hitting on a test system beforehand both to find issues and to get familiarity with the new version. |
| 13:07 |
Dyrcona |
Our staff (outside of central site) don't seem too interested in looking at our test environment. |
| 13:09 |
jeff |
our actual upgrades are performed by ESI, where we are hosted. |
| 13:10 |
jeff |
my reasons for asking are both short term / selfish, and long term / altruistic. :-) |
| 13:11 |
jeff |
the long term / altruistic reasons include making large upgrades either faster or easier to do without need for anyone to close libraries :-) |
| 13:12 |
Dyrcona |
there is always the offline circulation client. |
| 13:13 |
Dyrcona |
our libraries didn't even do any special closures for our migration. |
| 13:13 |
Dyrcona |
well, some might have, but it was their choice. |
| 13:13 |
jeff |
and that would fall under the not-yet-stated "making things less-painful" option. |
| 13:14 |
jeff |
offline circ (either with the evergreen staff client or with a SIP client) has its own set of compromises. |
| 13:14 |
Dyrcona |
The way we get around it is by doing smaller, more frequent upgrades, like once every quarter. |
| 13:14 |
* jeff |
nods |
| 13:15 |
Dyrcona |
tracking master or a rel_N_N branch is a good way to do that. |
| 13:15 |
Dyrcona |
That's another option that hasn't really come up before, tracking a release branch from git. |
| 13:16 |
Dyrcona |
I'm not sure that upgrading from one branch to another would be any easier, though. |
| 13:18 |
|
kbeswick joined #evergreen |
| 13:21 |
jeff |
shifting gears back to the "SIP renewal fails when checking item out with active barcode that is not primary barcode", looks like that should be fixable. |
| 13:23 |
jeff |
i do sometimes wish that the rscel effort had resulted in some tools for "these evergreen libraries actively use these features of evergreen" |
| 13:23 |
jeff |
i suppose that may never have been a stated objective of rscel. |
| 13:24 |
jeff |
but knowing "these are the libraries that are using rentals" or "these are the libraries that are using $BRAND SIP clients" can be helpful. |
| 13:25 |
Dyrcona |
But, SIP2 is a STANDARD. It shouldn't matter what brand a library uses. |
| 13:25 |
* Dyrcona |
runs off before jeff can smack him. |
| 13:30 |
* jeff |
faxes Dyrcona a late draft copy of the SIP 3.0 spec with all the typos and errors hilighted |
| 13:33 |
gmcharlt |
and a young one asks... "what's a fax?" |
| 13:37 |
jeff |
and then the interesting philosophical questions... what do you do when a hold representing an external pending ILL (or NCIP DCB) request is cancelled in the ILS? Do you do something different if it's a patron vs staff that does the cancellation? Do you attempt to prevent the cancellation in the ILS? |
| 13:38 |
jeff |
If the item later comes in, do you resurrect the hold and trigger notification for pickup? |
| 13:39 |
Dyrcona |
jeff: You sell the book on EBay? |
| 13:40 |
* gmcharlt |
has heard of net lenders and net borrowers for ILL, but not net sellers ... until now! ;) |
| 13:41 |
jeff |
wait for the incoming ItemRequested message, cancel the request, purchase the book from Amazon, notify patron upon arrival. |
| 13:42 |
Dyrcona |
Then the patrons sells the book on Ebay! |
| 13:42 |
Dyrcona |
;) |
| 13:43 |
collum |
gmcharlt: re. fax - it's what you wish you had, if you are using a teletype |
| 13:43 |
jeff |
it's a Telex without the green screen. |
| 13:43 |
* Dyrcona |
actually wrote software to feed a teletype, and that was in the late '90s..... |
| 13:43 |
gmcharlt |
collum++ |
| 13:44 |
Dyrcona |
MiniTel! |
| 13:47 |
|
remingtron joined #evergreen |
| 14:05 |
pinesol_green |
[evergreen|Ben Shum] Use libnet-z3950-simpleserver-perl package - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e797f7b> |
| 14:16 |
dbwells |
I am intending to cut RC sometime between this moment and Monday. Does anyone want to push for review of anything on this list? https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field |
| 14:16 |
dbwells |
.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.milestone%3Alist=61666&field.tag=pullrequest+&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_bluepri |
| 14:17 |
dbwells |
nts.used=&field.has_no_blueprints=on |
| 14:17 |
dbwells |
oof, sorry |
| 14:17 |
dbwells |
We'll try this instead: https://launchpad.net/evergreen/+milestone/2.5.0-rc |
| 14:18 |
dbwells |
Personally, I'd really appreciate a review of bug 1235326. |
| 14:18 |
pinesol_green |
Launchpad bug 1235326 in Evergreen "TPAC "results header" needs some fixes" (affected: 1, heat: 6) [Low,New] https://launchpad.net/bugs/1235326 |
| 14:20 |
|
artunit joined #evergreen |
| 14:26 |
|
rsoulliere joined #evergreen |
| 14:30 |
Dyrcona |
aw. remingtron beat me to it. |
| 14:30 |
remingtron |
Dyrcona: hey, you're welcome to take a look too |
| 14:31 |
eeevil |
dbwells: https://bugs.launchpad.net/evergreen/+bug/1188217 is my only one |
| 14:31 |
pinesol_green |
Launchpad bug 1188217 in Evergreen "TPAC should use client locale globally per request" (affected: 1, heat: 6) [Medium,Triaged] |
| 14:31 |
remingtron |
dbwells is making a quick change though |
| 14:31 |
Dyrcona |
Well, I'll see if I can verify the problem first. I have a mostly stock master installation at the moment. |
| 14:33 |
Dyrcona |
ok. i can wait to pull the branch, but I think I see the behavior that is described. |
| 14:39 |
remingtron |
Dyrcona: you can pull now |
| 14:40 |
jboyer-isl |
Does anyone have a quick explanation of the diff between LONGOVERDUE and LOST (related to action.circulation.stop_fines)? I'm just now looking at fm_IDL.xml changes, didn't know if LONGOVERDUE should ignore xact_finish. |
| 14:41 |
Dyrcona |
jboyer-isl: It's a terminology thing that apparently people coming from III can't live without. |
| 14:41 |
eeevil |
Dyrcona: and others |
| 14:42 |
jboyer-isl |
So they're essentially identical, and if xact_finish is set we don't care about long overdue items? |
| 14:42 |
Dyrcona |
I guess so, but I've been hired to make the mess even messier by adding a lost and paid status. |
| 14:42 |
jboyer-isl |
for staff client item out display, that is. |
| 14:43 |
Dyrcona |
jboyer-isl: Part of the reason for longoverdue as I understand it is it enables a different workflow. |
| 14:43 |
eeevil |
Dyrcona: ah, yes, THAT is a III think. also: |
| 14:43 |
eeevil |
III-- |
| 14:43 |
eeevil |
for that and many other reasons |
| 14:43 |
* eeevil |
runs away |
| 14:43 |
Dyrcona |
one positive thing it does is allow a library *not* to charge the book price for a longoverdue. |
| 14:44 |
Dyrcona |
they'll only charge when the patron says they lost it or something like that. |
| 14:44 |
jboyer-isl |
I always wondered what the point of it was. (My previous ILS experiences were DRA and Unicorn) |
| 14:45 |
* Dyrcona |
goes back to testing dbwells branch |
| 14:45 |
jboyer-isl |
Though Unicorn may have had it too, now that I think about it. |
| 14:48 |
dbwells |
eeevil: I think we are still waiting on a release of OpenSRF 2.2.1 before adding 1188217. That does seem imminent, but I am not 100% sure what's happening with it. |
| 14:50 |
Dyrcona |
dbwells: Fixes it for me. I'll signoff and push it to master. |
| 14:51 |
dbwells |
Dyrcona++ # thanks! |
| 14:51 |
gmcharlt |
dbwells: bah, indeed. I'll cut an RC candidate this weekend. |
| 14:55 |
pinesol_green |
[evergreen|Dan Wells] TPAC: Redo some margins/padding for better collapse behavior - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=00a58d7> |
| 14:55 |
pinesol_green |
[evergreen|Dan Wells] TPAC: Remove needless divs from results header bar - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d8278e3> |
| 14:56 |
kmlussier |
jboyer-isl: MassLNC was interested in a long overdue feature until we saw that PINES was sponsoring it. There were several reasons for it. One consortium wanted a middle ground between overdue and lost where they wouldn't be billing for the item, but where they could issue more blocks than they do for overdue and send out notices might be a little more threatening. |
| 14:57 |
kmlussier |
Another consortium plans to bill at long overdue, but sees a distinction between the two in that an item reported as lost is really, really lost and therefore might be replaced. Whereas an item that is automatically moved to long overdue has a chance of being returned again. There are also differences in what they might do for OPAC visibility for each status. |
| 14:58 |
jboyer-isl |
kmlussier: I've not heard about adding blocks and using it as a stepping stone to lost, but that does make sense. |
| 15:09 |
kmlussier |
dbwells: When is the RC scheduled to be released? |
| 15:09 |
dbwells |
kmlussier: one week ago :) |
| 15:10 |
dbwells |
Which mean, ASAP, hopefully this weekend sometime. |
| 15:11 |
kmlussier |
dbwells: OK. I had some additional edits I made to the release notes, but then I got pulled in other directions before I was done. I'll make sure I finished that up today then. |
| 15:11 |
dbwells |
kmlussier: sounds good, thanks! |
| 15:26 |
|
misilot left #evergreen |
| 15:27 |
Dyrcona |
If I had a dollar for every patch file in my patches directory whose filename starts with 0001, I'd have 12 dollars. :) |
| 15:27 |
|
kbeswick joined #evergreen |
| 15:28 |
gmcharlt |
Dyrcona: and now you must regret doing all that squashing ;) |
| 15:28 |
Dyrcona |
heh. |
| 15:28 |
Dyrcona |
They're not all my patches, though. |
| 15:36 |
kmlussier |
Dyrcona: Since any commits made to the doc repository update the official docs overnight, I was thinking it might be appropriate to immediately move those to Fix Released. Does that make sense? |
| 15:37 |
Dyrcona |
Well, I guess so. |
| 15:37 |
kmlussier |
And that way any doc bugs don't need to become a part of that regular bug churn that typically happens at release time. |
| 15:37 |
* Dyrcona |
must be new here. ;) |
| 15:37 |
Dyrcona |
Maybe we need a separate launchpad for docs bugs? |
| 15:39 |
kmlussier |
It probably would be a good idea if we (meaning DIG) write out Launchpad documentation procedures since we're hoping to track more doc issues there. |
| 15:40 |
kmlussier |
As far as a separate Launchpad, I don't know. What would the benefit be? |
| 15:44 |
Dyrcona |
Separating the documentation issues from the code issues would be the benefit. |
| 15:44 |
Dyrcona |
At any rate, it would really help if bugs all got appropriate tags, targets, and comments, so I don't make an ass out of myself because I didn't pay enough attention to the commit emails. |
| 15:50 |
kmlussier |
Dyrcona: Yes, you're right. Well, about the tagging, not about the making an ass of yourself ;) That's part of the reason why I think these procedures should be written up, so that everyone knows what tags should be used and how to best track just those bugs related to documentation. |
| 15:51 |
Dyrcona |
@hate Launchpad |
| 15:51 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates Launchpad. |
| 15:56 |
kmlussier |
Dyrcona: Should we add bug 1235642 to the agenda for the dev meeting? |
| 15:56 |
pinesol_green |
Launchpad bug 1235642 in Evergreen "Launchpad Too Cumbersome" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1235642 |
| 15:57 |
Dyrcona |
Whatever. I probably won't be there. |
| 15:57 |
|
yboston joined #evergreen |
| 16:15 |
|
kbeswick joined #evergreen |
| 16:28 |
kmlussier |
Bah! I just realized I don't have git set up on the computer I'm using. Looks like I won't be making edits to the Release Notes after all. |
| 16:57 |
|
mdriscoll left #evergreen |
| 17:14 |
jeff |
for those temporary bibs that are created in our system by ncip, i'm wondering how best to prevent things like holds placed by staff for other patrons (which are only going to cause issues or just hang out unfulfilled) |
| 17:20 |
Dyrcona |
jeff: Are you creating temporary bibs the way that issa does or are you using bib -1? |
| 17:20 |
Dyrcona |
issa has an option to use -1, now, but I don't think any of the three of us who use issa use that feature. |
| 17:20 |
jeff |
making them pre-cats might make more sense, but there are some circ-time assumptions surrounding pre-cats that might get in the way. |
| 17:21 |
Dyrcona |
true. |
| 17:21 |
Dyrcona |
we used a "Virt Cat" bib source for ours. |
| 17:21 |
Dyrcona |
Actually we added a whole system, etc. for virt cat. and hid it from the OPAC. |
| 17:22 |
jeff |
Dyrcona: iNCIPit creates temporary bibs. I plan to have it create them with a specific source, which would then let me teach TPAC to either hide/shade bibs, including hiding the Place Hold buttons... |
| 17:22 |
jeff |
Yeah, we did not go the system route. |
| 17:23 |
Dyrcona |
we have the source and the system. |
| 17:23 |
Dyrcona |
It's also how we handle holds. |
| 17:23 |
Dyrcona |
Virt cat stuff says route to virt cat on the slip, etc. |
| 17:23 |
phasefx |
could maybe use real call numbers against the -1 bib |
| 17:25 |
jeff |
for things where we are the item agency, we pull holds from the DCB client printed slips. |
| 17:25 |
Dyrcona |
jeff: You also aren't dealing with 36 libraries on one Evergreen system. :) |
| 17:26 |
jeff |
when we're the user agency, we create a bib+volume+copy (in a non-opac-visible shelving location) and place a copy-level hold for pickup at the system level (because ItemRequested does not include pickup location details). |
| 17:27 |
jeff |
we update the pickup location on the hold when we get the ItemShipped (and replace the item ID with the real barcode), and when we AcceptItem we check the copy in at the pickup location so that it captures and goes to available. |
| 17:27 |
jeff |
notification then triggers, etc. |
| 17:27 |
jeff |
in the meantime, until the copy+volume+bib are deleted, they show in a staff search (without any copies available/visible -- just the bib) |
| 17:27 |
Dyrcona |
NCIP is supposed to benefit us, how? |
| 17:28 |
jeff |
for NCIP DCB-3, the idea is that you don't have to do dual entry / dual checkout / etc. |
| 17:29 |
Dyrcona |
oh well. I'm signing out, 'cause I'm going to power the laptop off before leaving the office. |
| 17:29 |
* tsbere |
likes the idea of a -2 bib for "temporary items", use the author/title copy level fields, and then place force holds for patrons |
| 17:30 |
jeff |
tsbere: depending on how far you want to take it, you could even have that indicate to the system that certain actions not be allowed, or must trigger an external action... |
| 17:30 |
jeff |
but that's for another day, perhaps. |
| 19:07 |
|
smyers_ joined #evergreen |
| 19:47 |
|
artunit joined #evergreen |
| 19:55 |
|
jeffdavis joined #evergreen |
| 19:59 |
|
jeffdavis joined #evergreen |
| 21:01 |
|
mrpeters joined #evergreen |
| 22:16 |
|
jeff_ joined #evergreen |
