| Time |
Nick |
Message |
| 01:52 |
|
dcook joined #evergreen |
| 02:23 |
|
Mark__T joined #evergreen |
| 04:48 |
|
Mark__T joined #evergreen |
| 05:12 |
|
artunit_ joined #evergreen |
| 06:43 |
csharp |
ldw++ # test wrangling |
| 07:37 |
|
Callender joined #evergreen |
| 07:45 |
|
TaraC joined #evergreen |
| 07:46 |
|
mrpeters joined #evergreen |
| 07:58 |
|
ericar joined #evergreen |
| 08:06 |
|
akilsdonk joined #evergreen |
| 08:07 |
|
Shae joined #evergreen |
| 08:42 |
|
Dyrcona joined #evergreen |
| 08:49 |
|
krvmga joined #evergreen |
| 08:50 |
krvmga |
in eg 2.5 it was easy to change the order of search format filters in the opac dropdown list. since 2.6, they have been listed alphabetically. is it possible to change the order of the filters somehow other than by alphabetical manipulation? |
| 08:56 |
|
mmorgan joined #evergreen |
| 09:14 |
|
jwoodard joined #evergreen |
| 09:25 |
Stompro |
mmorgan++ thanks for testing the patron expiration notice.. now to get the release notes done. |
| 09:25 |
|
yboston joined #evergreen |
| 09:27 |
* Dyrcona |
wonders if hopkinsju had any success with backstage yesterday evening. |
| 09:27 |
mmorgan |
Stompro++ Thanks for polishing the code, and (in advance) for the release notes! |
| 09:29 |
|
ericar_ joined #evergreen |
| 09:35 |
|
collum joined #evergreen |
| 10:07 |
|
pmurray_away joined #evergreen |
| 10:10 |
Stompro |
ldw++, thanks for all the test writing bugs, I assigned myself to the simplest one I could find :-) |
| 10:23 |
krvmga |
is there any way to change the order of search format filters in the opac other than by playing with the alphabetical listing? |
| 10:29 |
dbwells |
krvmga: I don't think there is anything built in. We ordered ours as you are thinking by manipulating the strings. In our case, we prepended a certain number of spaces to the "Search Label"s. The spaces do not show up. |
| 10:29 |
krvmga |
dbwells: can i look at your catalog url? |
| 10:30 |
krvmga |
dbwells: i mean, what is your catalog url? |
| 10:33 |
dbwells |
krvmga: sure, though we don't use the stock filters: http://ulysses.calvin.edu/eg/opac/home |
| 10:34 |
krvmga |
dbwells: i see. thanks. |
| 10:41 |
|
Christineb joined #evergreen |
| 10:43 |
dbs |
dbwells: that is a nasty hack :) |
| 10:43 |
dbs |
but an impressive one |
| 10:44 |
|
ericar_ joined #evergreen |
| 10:44 |
Dyrcona |
krvmga: I recall there being a launchpad bug requesting that filters and similar things sort alphabetically, so code may have been added somewhere to do that. |
| 10:48 |
krvmga |
Dyrcona: thanks. i'll take a look for it and see what happened there. |
| 10:49 |
dbs |
alphabetical is certainly better than "random by database ID" or unordered :) |
| 10:51 |
Dyrcona |
dbs: yep. |
| 10:52 |
krvmga |
i found this one https://bugs.launchpad.net/evergreen/+bug/802700 about "values are ordered by database id value (not very intuitive) rather than some alpha-sorting" |
| 10:52 |
pinesol_green |
Launchpad bug 802700 in Evergreen "Dojo interface dropdown sort method is not intuitive" (affected: 5, heat: 32) [Low,Confirmed] |
| 10:53 |
krvmga |
dbs: i agree completely. i would just like to be able to manipulate the order. |
| 10:56 |
Dyrcona |
krvmga: That one was never fixed, and there could be a duplicate or one specifically for the OPAC. |
| 10:56 |
Dyrcona |
Searching Launchpad is awful. |
| 10:59 |
* Dyrcona |
listens to Jimi Hendrix. Today is a good day for "Still Raining, Still Dreaming." |
| 11:00 |
Dyrcona |
@weather 01845 |
| 11:00 |
pinesol_green |
Dyrcona: The current temperature in WB1CHU, Lawrence, Massachusetts is 66.9°F (11:00 AM EDT on August 11, 2015). Conditions: Light Rain. Humidity: 100%. Dew Point: 66.2°F. Pressure: 29.91 in 1013 hPa (Falling). |
| 11:06 |
|
_krvmga joined #evergreen |
| 11:07 |
_krvmga |
is anyone at an academic institution doing single sign on that includes evergreen? |
| 11:08 |
_krvmga |
i don't think we have this capability in the community right now but i wanted to check |
| 11:09 |
_krvmga |
we can work it out so they can single sign on to their campus and databases but i don't think we can do it to include evergreen |
| 11:12 |
csharp |
_krvmga: there is LDAP support, which is probably what most people use for SSO (but I've never used it so can't speak to particulars) |
| 11:13 |
csharp |
I *think* dbs and/or dbwells have direct knowledge about it |
| 11:14 |
_krvmga |
csharp: by LDAP support, do you mean we could hook out eg into someone else's LDAP? |
| 11:14 |
_krvmga |
out -> our |
| 11:15 |
dbwells |
_krvmga: Yes, we use our campus IT LDAP to authenticate to EG, if that's what you mean. |
| 11:16 |
_krvmga |
dbwells: i wonder how that would play out in a consortial environment. (i'm assuming you are a single library environment) |
| 11:16 |
dbwells |
_krvmga: There is nothing in place for authorization/account creation, so that needs to be done as a separate process. |
| 11:17 |
csharp |
we've been tossing that idea around here for a while |
| 11:17 |
dbwells |
_krvmga: there is support for different LDAP configs for different org units, but if you mean more as an access/politics question, I can't help there :) |
| 11:18 |
csharp |
one of the libraries' complaints is too many passwords to remember |
| 11:18 |
|
pmurray joined #evergreen |
| 11:18 |
|
pmurray left #evergreen |
| 11:57 |
|
bmills joined #evergreen |
| 12:07 |
dbs |
krvmga: we use LDAP for single sign on for most things in Evergreen. There are a few places, like Dojo and reports, that don't know about open-ils.auth_proxy and thus require Evergreen-internal passwords :/ |
| 12:07 |
dbs |
huge thanks to dbwells for getting things going with that |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:13 |
jeff |
hrm. pokemon record looks correct in catalog, looks oddly encoded in SIP2 response. also seems to cause issues for at least two SIP clients. |
| 12:13 |
* jeff |
grabs berick's python3 sip2 client |
| 12:14 |
jeff |
...and python3 while i'm at it. :P |
| 12:15 |
jeff |
since Evergreen stores MARC data as MARCXML in UTF8, are any MARC leader values that indicate MARC8 an error? |
| 12:15 |
dbs |
jeff: Yes |
| 12:20 |
Stompro |
Can someone confirm for me that the circ history opt-out/opt-in resets the circ history? When you opt-out and then opt-in your history starts from when you last opted in? |
| 12:28 |
berick |
Stompro: when you opt-in, it starts from now |
| 12:28 |
jeff |
hrm. marcxml and mods have Pokémon while mods32 and mods33 have Pokémon |
| 12:28 |
berick |
Stompro: because in the meantime, your history may have been deleted |
| 12:31 |
mmorgan |
Stompro: When a user opts in, the history.circ_retention_start usr_setting is set for the user with the current date as the value. |
| 12:32 |
jeff |
@decide too much encoding, or not enough encoding? |
| 12:32 |
pinesol_green |
jeff: Have you tried turning it off and back on again? |
| 12:32 |
berick |
yeah, jeff, try that |
| 12:32 |
phasefx |
ROT13 ROT13 |
| 12:33 |
mmorgan |
The user's history comes from action.circulations starting at that date, I believe |
| 12:38 |
Stompro |
Thanks mmorgan, berick , we are just trying to figure out how our reading history from Millennium is going to migrate. In millennium the opt-in/out is a stop/start operation, so you can have reading history displayed even when you are currently opted out. |
| 12:38 |
Dyrcona |
mmorgan: It's more complicated than that if you're aging and keeping the last couple circulations around for various reasons. |
| 12:40 |
Dyrcona |
Stompro: Unless you can migrate the reading history as circulations, it won't show up in Evergreen. |
| 12:40 |
mmorgan |
Dyrcona: Yes, the point is, it's not a separately maintained circ history. It comes from the circulation table. |
| 12:40 |
Dyrcona |
mmorgan: Yep. |
| 12:41 |
* Dyrcona |
doesn't know what reading history looks like in Millennium. |
| 12:43 |
|
rlefaive joined #evergreen |
| 12:43 |
Dyrcona |
BTW, patrons can also retain hold history in Evergreen. |
| 12:43 |
Stompro |
Dyrcona, we are able to convert it to circulation, but the opt-in/out status isn't included, so we have to figure out how to guess. |
| 12:44 |
Dyrcona |
Stompro: You don't have a user setting/preference in Millennium for that? |
| 12:45 |
Stompro |
Dyrcona, not one that is exposed for us to see. |
| 12:45 |
|
mrpeters joined #evergreen |
| 12:47 |
mmorgan |
We had not implemented circ history in the Millennium days, so didn't have that challenge. |
| 12:49 |
Dyrcona |
Well, s'pose you could migrate all the circ data, and give patrons some kind of notice that after x months, you will start making old circulation data disappear and they should opt in before that date if they want to keep their history. |
| 12:49 |
Dyrcona |
I don't recall how that worked (if at all) with Horizon when we did our migration. |
| 12:51 |
Dyrcona |
jeff: Different encodings in the same character set? ;) |
| 12:51 |
Dyrcona |
UTF-8 is fun! |
| 12:53 |
Dyrcona |
And, I've recently seen MARC records that said they were UTF-8, but were really MARC-8. |
| 12:53 |
Dyrcona |
Just adding that 'a' to the leader doesn't magically change the encoding, guys.... :) |
| 12:55 |
jeff |
right. |
| 12:57 |
Stompro |
Dyrcona, but the date they opt-in is the date that the EG circ activity gets shown, so opting in wouldn't show their old circ history. |
| 12:57 |
Dyrcona |
Guess you could just turn it on for everyone with a date in the past..... Then tell them to opt out, but I hate opt out. |
| 12:58 |
mmorgan |
Stompro: Are you able to see the oldest circ date for each user in their circ history? |
| 13:01 |
mmorgan |
If so, you can opt them in by adding to actor.usr_setting the history.circ_retention_start setting with the date of their earliest circ as the value. You'd need to load the circs, too. |
| 13:02 |
Stompro |
mmorgan, migrating them all opt-in isn't a problem, except that many of them have opted out at some point, but never cleared out their history manually. So we would be opting in a bunch of people that opted out. |
| 13:03 |
mmorgan |
Ah. I see the challenge :-( |
| 13:08 |
|
akilsdonk joined #evergreen |
| 13:26 |
Dyrcona |
Stompro: You could always bug Millennium support to find out if you can get access to the opt-in status of patrons somehow. |
| 13:26 |
jeff |
do a dummy circ to every patron and see if they get a new entry in their history? :-) |
| 13:27 |
* Dyrcona |
doesn't know enough about it to tell if jeff's suggestion would work. |
| 13:28 |
mmorgan |
Compare the patron's most recent checkou to their circ history and only opt in patrons where the entry exists in both? Are there dates associated with the Millennium circ history? |
| 13:51 |
|
mrpeters joined #evergreen |
| 13:58 |
|
ericar_ joined #evergreen |
| 13:59 |
|
mrpeters joined #evergreen |
| 14:06 |
|
kitteh_ joined #evergreen |
| 14:27 |
Bmagic |
Are we reporting bugs with the web based staff client? We just upgraded to 2.8.2 and some of our libraries are excited to use it and they have a list of things/bugs. Do I make a launchpad bug? |
| 14:29 |
mmorgan |
Bmagic: Yes, web client bugs should go to Launchpad at this point. |
| 14:29 |
berick |
though you might want to wait until the pending sprint2 branch is merged. it has a variety of bug fixes. |
| 14:29 |
berick |
well, i mean, it never hurts to open a bug |
| 14:29 |
Dyrcona |
There's a tag, but I don't recall what it is off the top of my head. |
| 14:29 |
Bmagic |
berick: I was sorta thinking along those lines |
| 14:30 |
Bmagic |
I was having trouble finding a report about the in-house barcode box not clearing the box after the enter button was pressed (ready to accept the next barcode) |
| 14:39 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1483857 |
| 14:39 |
pinesol_green |
Launchpad bug 1483857 in Evergreen "Web based staff client in house use barcode box clear" (affected: 1, heat: 6) [Undecided,New] |
| 14:59 |
ldw |
Stompro: thank you for taking a bug. Have you worked with the pgTap testing suite before? |
| 15:00 |
Stompro |
ldw, Never, All I know about it is from reading the docs that you linked to previously. |
| 15:00 |
|
rlefaive joined #evergreen |
| 15:03 |
ldw |
Stompro: If you have any questions about it do not hesitate to ask. |
| 15:04 |
|
akilsdonk joined #evergreen |
| 15:17 |
jboyer-isl |
I don't think I've asked this before, but what are the thoughts re: tests and simply adding new seed data? Don't bother, check to see if a few values are present, check every value, etc? |
| 15:18 |
berick |
jboyer-isl: for example? |
| 15:18 |
jboyer-isl |
I'm looking at LP #1371647 and have a large upgrade script ready to go, but I haven't decided what to do about a test case. |
| 15:18 |
pinesol_green |
Launchpad bug 1371647 in Evergreen "config.marc21_ff_pos_map needs an audit" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1371647 |
| 15:20 |
jboyer-isl |
berick: example incoming |
| 15:21 |
jboyer-isl |
Bah, it would have, but I mistyped my nick... |
| 15:21 |
jboyer-isl |
http://paste.evergreen-ils.org/23 |
| 15:22 |
berick |
ohh, ok, i understand the question now |
| 15:22 |
berick |
sorry, i was confuzzled |
| 15:23 |
berick |
i've just been checking a few values, like a basic sanity check. |
| 15:23 |
berick |
don't think we have a policy on that |
| 15:25 |
jboyer-isl |
Excellent. I don't mind spot checking a few things to be sure the patch was applied, but a "full check" would be a huge pain to write for things like that. |
| 15:26 |
jboyer-isl |
I'll try to get something put together and posted for proper discussion/testing asap; this is holding up some format search improvements that we're trying to do and I don't want it to be a local only fix. |
| 15:27 |
Dyrcona |
Well, you could use a macro in your text editor to write the tests for you... I've done that recently from other upgrade scripts. |
| 15:30 |
berick |
you're gonna need a unit test on that macro |
| 15:32 |
Dyrcona |
You're gonna need a unit test on your unit test, too. :) |
| 15:33 |
Dyrcona |
But actually, I didn't use a macro just a regex search and replace. I misspoke. |
| 15:45 |
jboyer-isl |
That's true, but then there's only full coverage for a chunk of data. If there's ever interest in fully verifying seed data, I'd rather see one big test that checks it all (one file per schema/table, not necessarily the entire seed database) |
| 15:52 |
Dyrcona |
jboyer-isl: That sounds reasonable to me. When do you start working on it? :P |
| 15:52 |
Dyrcona |
j/k |
| 15:54 |
jboyer-isl |
Well, I suppose someone could find and replace 950.config.seed-data.sql, heh. |
| 15:55 |
pinesol_green |
[evergreen|Angela Kilsdonk] Documentation: Items out enhancements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=68c2255> |
| 16:08 |
|
jlitrell joined #evergreen |
| 16:09 |
jwoodard |
@weather 76227 |
| 16:09 |
pinesol_green |
jwoodard: The current temperature in Nipe Ranch, Krugerville, Texas is 100.8°F (3:09 PM CDT on August 11, 2015). Conditions: Clear. Humidity: 46%. Dew Point: 77.0°F. Pressure: 30.02 in 1016 hPa (Falling). |
| 16:09 |
Dyrcona |
That is hot. |
| 16:10 |
jwoodard |
Thankfully the humidity is low. |
| 16:10 |
Dyrcona |
yep. The rain finally let up here, but looks like we might get more. |
| 16:11 |
jwoodard |
The heat index is sitting at 109°F but its not really that bad....at least if you grew up in it. |
| 16:11 |
jwoodard |
Dyrcona: Send the rain my way if you do not want it. |
| 16:11 |
* Dyrcona |
does a weather dance. :) |
| 16:12 |
jlitrell |
@weather 11210 |
| 16:12 |
pinesol_green |
jlitrell: The current temperature in Flatbush - Ditmas Park, Brooklyn, New York is 82.9°F (4:07 PM EDT on August 11, 2015). Conditions: Mostly Cloudy. Humidity: 77%. Dew Point: 75.2°F. Pressure: 29.73 in 1007 hPa (Rising). High rip current risk in effect until 8 PM EDT this evening... |
| 16:12 |
jlitrell |
Living in soup. |
| 16:21 |
Dyrcona |
Hmm. Looking into something from yesterday that I thought would require a staff client change and now it looks like I can handle it all on the back end. |
| 16:22 |
Dyrcona |
berick: Do you remember the LP bug that was created for the branch that allowed pre cat copies to be created for ILL and other purposes? |
| 16:22 |
Dyrcona |
kmlussier and I tested it, but I can't find the bug now, even search fix committed bugs. |
| 16:23 |
|
mmorgan1 joined #evergreen |
| 16:23 |
|
mmorgan1 left #evergreen |
| 16:24 |
|
mmorgan2 joined #evergreen |
| 16:24 |
Dyrcona |
Ah, launchpad seems to like me today.... I found it whereas I failed yesterday: lp 1308239 |
| 16:24 |
pinesol_green |
Launchpad bug 1308239 in Evergreen "Support targeting and fulfillment of precat copy holds (for ILL)" (affected: 2, heat: 10) [Wishlist,Fix released] https://launchpad.net/bugs/1308239 |
| 16:24 |
|
mmorgan2 left #evergreen |
| 16:25 |
Dyrcona |
berick++ # that's a handy feature. |
| 16:26 |
Dyrcona |
Looks like bshum tested it, too. |
| 16:27 |
hopkinsju |
Dyrcona: Just made a breakthrough. |
| 16:27 |
Dyrcona |
hopkinsju: What was the problem? |
| 16:28 |
hopkinsju |
Initial issue was the default last_run_date and the fact that we didn't use the script to do the initial export |
| 16:29 |
hopkinsju |
I need to set the last_run_date to the date that they sent their records off to BS, and then, because they have edited records since then, flip the logic of the DateTime->compare. |
| 16:29 |
hopkinsju |
After this, I think the script will work as intended, assuming we use it to handle the export. |
| 16:30 |
Dyrcona |
Generally, you don't want to overlay edited bibs with what BSLW sends you. |
| 16:30 |
Dyrcona |
That's what the date checks prevent. |
| 16:31 |
Dyrcona |
Yeah, it is written with export and then import being the workflow, but we also get files of just authorities that we load without having done another export. |
| 16:31 |
|
mmorgan joined #evergreen |
| 16:31 |
|
mmorgan left #evergreen |
| 16:31 |
Dyrcona |
Our workflow is we send backstage a file of new bibs. |
| 16:31 |
hopkinsju |
It decides to keep the existing bib in the case where the edit date is < the last export date. |
| 16:32 |
hopkinsju |
So, pretty much every bib that was sent to BS had an earlier date. |
| 16:33 |
hopkinsju |
I wonder if I can talk BS into processing these bibs again for free :) |
| 16:33 |
hopkinsju |
Then just do the export. |
| 16:34 |
Dyrcona |
first, it checks if the existing bib record has an edit date < the export date, yes. |
| 16:34 |
Dyrcona |
but then it compares the edit date of the incoming record from bslw with the existing bib record. |
| 16:34 |
Dyrcona |
if the existing bib record was edited more recently, it keeps the existing record, otherwise it overlays with the record from bslw. |
| 16:36 |
Dyrcona |
That outer if may be unnecessary, but the idea was to not overlay records that were edited since the export was done. |
| 16:36 |
Dyrcona |
We use it mainly to get the authorities records, since they don't do major cleanup on the bibs, normally, just a few additions here and there for us. |
| 16:37 |
Dyrcona |
And, I was going to add that we send them a file with our new bibs, and they send back the processed bibs and authorities. |
| 16:37 |
Dyrcona |
About 1 month later they notify us that a file of updated authorities is available and we load that with the software. |
| 16:38 |
Dyrcona |
For us, the above happens on a quarterly basis. |
| 16:39 |
Dyrcona |
We also have a cataloging workflow that caused me to recently make some major alterations in a custom branch to not send brief bibs, but to keep a list of the brief bibs so they'd be sent later. |
| 16:41 |
Dyrcona |
So, yeah, if you had the export date at the default of 2012-01-01 or whatever that would be a problem.... |
| 16:42 |
hopkinsju |
And it was :-) I ignored it because it was in the export part of the prefs file |
| 16:42 |
Dyrcona |
That could maybe use a mention in the README. |
| 16:42 |
Dyrcona |
Or the code could possibly be removed. |
| 16:44 |
Dyrcona |
git blame says that if has been there from the beginning, so I hesitate to just remove it. |
| 16:47 |
|
eady joined #evergreen |
| 16:47 |
hopkinsju |
I think that some output could be generated since the expected output is "keep" or "import" |
| 16:47 |
hopkinsju |
and if that check fails neither of those things happen |
| 16:52 |
hopkinsju |
Or, allowing for the last_run_date value to be empty. |
| 16:54 |
Dyrcona |
Yeah, those sound like decent ideas. Patches welcome! :) |
| 17:00 |
Dyrcona |
Well, time to go home. |
| 17:12 |
|
mmorgan1 joined #evergreen |
| 17:12 |
|
mmorgan1 left #evergreen |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:20 |
|
rjackson_isl_ joined #evergreen |
| 18:20 |
|
mmorgan joined #evergreen |
| 18:23 |
|
TaraC joined #evergreen |
| 23:28 |
|
RBecker joined #evergreen |
| 23:37 |
|
dcook joined #evergreen |
