| 09:41 |
* paxed |
investigates |
| 09:42 |
|
mrpeters joined #evergreen |
| 09:43 |
rfrasur |
something that's called .id is usually a number, isn't it? while w/o the .id....it's a text string? that's just the understanding I've had when building reports (that work 50% of the time) |
| 09:43 |
paxed |
http://i.imgur.com/6jPQg1l.jpg |
| 09:43 |
paxed |
i think ctx.user.home_ou is a fieldmapper object, so it shouldn't work |
| 09:44 |
* paxed |
compiles eg and tests |
| 09:44 |
rfrasur |
just so you know...I prefer earth to the other views. much prettier....and watered |
| 09:44 |
paxed |
yup |
| 09:46 |
paxed |
(the Venus picture was taken in '67!) |
| 09:47 |
rfrasur |
We've already got the steam. Now we just need a mouthy young adult...and we'll have the punk. |
| 09:48 |
rfrasur |
jboyer-isl: are you available? |
| 09:49 |
jboyer-isl |
I'm in and out. In now. |
| 09:51 |
rfrasur |
I did a little testing on the galaxy tab 7 last night. it worked well, looked good, etc. the only thing I was noticed was when I changed orientation it switches to traditional OPAC view (which was expected), but because it's narrower, the facets and results don't fit...and the facets show first. Is there a way to have an intermediate view that gets those facets out of the way? |
| 09:52 |
jboyer-isl |
There is. I'll have to look some things up, but there can easily be an intermediate step between everything and bare bones. |
| 09:54 |
rfrasur |
excellent. Other than that...and I also was thinking about the search view. I'm not sure that's a big deal after all. Does it show results based on relevance as default? (I don't really know how to spell relevance/relevence) |
| 09:54 |
rfrasur |
but...other than that...I think it's good. I mean, there's always something to critique/criticize, but it seems like a great step. |
| 11:14 |
kayals |
By default admin account did not get associated to the top org level unit. How to assign admin to get top level permission...say Global Administrator |
| 11:14 |
kayals |
thanks |
| 11:23 |
rjackson-isl |
bshum++ for knowledge sharing |
| 11:23 |
bshum |
rjackson-isl: Please feel free to add notes or findings to that bug report. |
| 11:24 |
bshum |
I'll try to do the same once the dust settles more over here :( |
| 11:27 |
bshum |
kmlussier: "Now witness the firepower of this fully armed and operational battle station." (replace battle station with test server) |
| 11:29 |
|
kmlussier1 joined #evergreen |
| 11:31 |
kmlussier |
Heh |
| 11:31 |
rfrasur |
kmlussier++ # that sounds like a huge task |
| 11:37 |
bshum |
And then let the hold targeter spread things back out more evenly again. |
| 11:38 |
bshum |
Like I set all active holds to a prev check time of midnight or something back then. |
| 11:38 |
bshum |
I've been thinking to push them back towards 9 or 10 pm at the rate I'm going. |
| 11:55 |
jboyer-isl |
We secretly replaced kmlussier's test server with Folgers crystals. Let's see if she notices. |
| 11:55 |
rfrasur |
jboyer-isl++ |
| 11:56 |
jboyer-isl |
dbs: agreed. I was also trying to take a light touch with the html in 2.2. I'll still try to leave as much alone in the future as I can thouhgh, or I'm likely to try to redesign the whole thing. :D |
| 11:56 |
* kmlussier |
probably wouldn't notice, but tsbere might. :) |
| 10:15 |
|
rfrasur joined #evergreen |
| 10:15 |
jeff_ |
we're on 2.2, so we don't even have copy location groups, so we just emulated groups in the template -- <option value='527,531,530,532,791,795,529,793,528,794,792,571,516,593,771,770,542,589,549'>Juvenile</option> |
| 10:15 |
Dyrcona |
jeff_: Take a look at OpenILS::Utils::Normalize::clean_marc in master. It will have some tricks you might to use. |
| 10:16 |
jeff_ |
it is likely less performant than copy location groups, but I've not tested |
| 10:16 |
jeff_ |
Dyrcona: thanks! |
| 10:16 |
csharp |
jeff_: thanks for those details ;-) |
| 10:22 |
* rfrasur |
sees an email with the subject "mobile OPAC testing" from jboyer-isl - looks very interesting |
| 10:23 |
gmcharlt |
testing the OPAC from the bookmobile? |
| 10:23 |
rfrasur |
jboyer-isl: I have story time at 10:30 but will test on a variety of screens after I get done with that. Probably around 11:30. |
| 10:23 |
gmcharlt |
;) |
| 10:23 |
rfrasur |
gmcharlt++ # maybe |
| 10:24 |
rfrasur |
as an unrelated aside - when your mother and brother endorse you on Linkdin, it kind of takes some of the professionalism and credibility away. |
| 11:19 |
bshum |
parts-- |
| 11:20 |
bshum |
kmlussier: Our pain begins early this week. |
| 11:20 |
Dyrcona |
To elebenty and beyond! |
| 11:21 |
Dyrcona |
kmlussier: My development VM is working if you're interested in testing things. |
| 11:25 |
|
BigRig joined #evergreen |
| 11:38 |
bshum |
senator: Dyrcona: To verify, the branch I should look at for the browse stuff is collab/dyrcona/bib-auth-browse-squash, right? |
| 11:38 |
senator |
bshum: right |
| 11:38 |
bshum |
(We're rebasing our test servers today and I'm going to add it again to the mix) |
| 11:38 |
bshum |
Cool deal. |
| 11:39 |
bshum |
And also, holy cow that's alot o' commits |
| 11:39 |
Dyrcona |
bshum: There's a small conflict with master at the moment, just keep both parts. |
| 11:39 |
bshum |
:D |
| 11:39 |
senator |
bshum: i think when all parties are reasonably happy with it, it can be squashed way down |
| 11:56 |
senator |
asimon: that should show up in the staff client. if not, there's either a permissions issue or some deeper problem. |
| 11:56 |
bshum |
That should be in the library settings editor. |
| 11:56 |
bshum |
Or at least, it was when we configured it. |
| 11:57 |
dbs |
asimon: maybe your site missed an upgrade ? |
| 11:57 |
dbs |
looks like it's in 1.6.1-2.0-upgrade-db.sql |
| 12:03 |
dbs |
Hey, here's a brilliant idea for a simple perl test... ensure that DEBUG_TIMING == 0. heh :) |
| 12:06 |
|
rfrasur joined #evergreen |
| 12:07 |
paxed |
dbs: are peer.title & peer.author already scrubbed of hmtl? |
| 12:07 |
paxed |
blah. html. |
| 12:09 |
dbs |
paxed: no; good catch. gotta prevent those cataloguers from exploiting vulnerabilities :) |
| 12:09 |
paxed |
dbs: well, who knows, maybe some author will name their book <a href="goatse"> ... :P |
| 12:15 |
dbs |
paxed: pushed a nice sanitized branch with a hat-tip to you in the commit message |
| 12:15 |
rfrasur |
jboyer-isl: testing on galaxy nexus phone...then kindle fire. will try galaxy tab 7 at home later. |
| 12:16 |
rfrasur |
(of course, it'd help if I could remember my password) |
| 12:17 |
jboyer-isl |
Thanks. I was able to do a little testing with someone's random android somethingorother and it looked ok, so I'm hoping things will be good all around. |
| 12:17 |
rfrasur |
so far, it looks good. will take a look in my account and then do a couple searches and do some stuff. |
| 12:17 |
dbs |
jboyer-isl: any of your work headed 2.5 / master's way? |
| 12:19 |
rfrasur |
(figure it's a good chance to see how easy it is to do a password reset from my phone) |
| 12:19 |
jboyer-isl |
Everything that I re-make for 2.4, sure. I haven't actually started that though. D: Need to study up on user/collab branches, because I'm also starting from 0 on that. |
| 12:20 |
jboyer-isl |
rfraur: and you would also be testing a page I forgot to ever even look at. Hope it looks ok, heh. |
| 12:20 |
jboyer-isl |
And I can't type. :/ |
| 12:20 |
rfrasur |
jboyer-isl: the reset page? it looked fine :) |
| 12:20 |
jboyer-isl |
Lucky us. |
| 12:22 |
jboyer-isl |
Also, I don't know if all of the necessary back end stuff is running for that to actually work. If you need me to change the password on an account let me know. (The dataload is several months old, in case you've changed it recently.) |
| 12:27 |
rfrasur |
also, are we foregoing a limited advanced search forever or just for now? |
| 12:28 |
jboyer-isl |
I just meant that the email will never come, and the actual reset may not work if it did. Are you using the same hostname on the desktop vs. mobile? (and NOT letting the keyboard "help" you by auto-capitalizing the first letter of your username? They're ALSO case sensitive...) |
| 12:29 |
jboyer-isl |
I'm personally planning to forego advanced search forever. I'm working off the assumption that it's a hassle to enter things into a bunch of fields. I won't argue with anyone else that wants to take care of it. |
| 12:30 |
rfrasur |
no, I'm using the standing catalog on the desktop (to make sure that I wasn't messing up the log-in). let me try the mobile on the desktop and see what it does there. I'm okay with just the basic search for the same reason you mentioned. |
| 12:31 |
|
mmorgan left #evergreen |
| 12:31 |
rfrasur |
yeah, it's not helping me on the desktop (as you say), and I can't log in on the test site. |
| 12:32 |
rfrasur |
hmm...s/standing/standard |
| 12:37 |
rfrasur |
I do like the library chooser |
| 12:38 |
kmlussier |
Dyrcona: Searches on your dev server are quite zippy today. :) |
| 12:38 |
Dyrcona |
kmlussier: It's the new database server. We got one almost identical to what we use in production. |
| 12:39 |
Dyrcona |
Which reminds me of an email I have to answer after lunch. |
| 12:39 |
kmlussier |
Dyrcona++ |
| 12:40 |
rfrasur |
jboyer-isl: search works well as far as I've delved into it. |
| 12:40 |
bshum |
dbwells++ #milestone wrangling |
| 12:41 |
rfrasur |
and records show up nice. can't test the hold placing because of the authentication issue. let me try something with that real quick (sorta quick). |
| 12:43 |
rfrasur |
yeah - no. won't authenticate. |
| 12:49 |
pinesol_green |
[evergreen|Dan Wells] Make AuthProxy LDAP bind code more robust - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=36ea3a2> |
| 12:49 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 12:52 |
bshum |
Blah, 0795 fails because we apparently don't have a metabib_field entry 30 for LCCN. |
| 13:37 |
paxed |
do people remove the bug assignment once they've released a fix for it? |
| 13:39 |
jboyer-isl |
I'm more interested in how Chrome likes it than "Browser," but I was able to log in with someone else's phone using Browser. |
| 13:39 |
|
sidion left #evergreen |
| 13:39 |
rfrasur |
I'm testing Chrome right now. Browser didn't work on phone...and neither did Firefox on desktop. Maybe I need to clear out the cache and start over. |
| 13:41 |
bshum |
kmlussier: I'll be here and there. But yeah, in a phone call during the meeting, so I might be a little more distant than I'd like :( |
| 13:41 |
rfrasur |
jboyer-isl:fail on phone using chrome |
| 13:41 |
kmlussier |
bshum: A little difficult to run a meeting that way. :) |
| 14:07 |
|
akilsdonk_ joined #evergreen |
| 14:09 |
jboyer-isl |
It's possible they're all disabled in case a patron tried to play with it., I've not looked at it. |
| 14:09 |
jboyer-isl |
disabled because it's the migration server, that is. |
| 14:10 |
rfrasur |
ahhh, I gotcha. You're probably right. Are you testing it with a staff profile account I'm assuming? |
| 14:10 |
jboyer-isl |
yes. |
| 14:10 |
jboyer-isl |
They act the same in the OPAC anyway. |
| 14:11 |
rfrasur |
except when they're disabled :-) |
| 14:14 |
rfrasur |
paxed++ |
| 14:32 |
|
tspindler joined #evergreen |
| 14:40 |
|
jihpringle joined #evergreen |
| 14:41 |
Dyrcona |
Well, I'm going to rig an experiment to test my question. |
| 14:59 |
|
rfrasur joined #evergreen |
| 15:12 |
|
kbeswick joined #evergreen |
| 15:27 |
|
ldwhalen joined #evergreen |
| 15:56 |
linuxpoet |
Dyrcona: it is not reasonable to suggest that kind of switch at this time. It isn't like it is something that can be done overnight for this installation |
| 15:56 |
paxed |
phasefx: no. we're not in production yet. |
| 15:57 |
phasefx |
paxed: roger that |
| 15:57 |
paxed |
phasefx: but i do tend to test most of my fixes with our full conversion db |
| 15:57 |
Dyrcona |
linuxpoet: You will have fewer problems or none at all if you switch, and you'll get actual useful help. |
| 15:58 |
Dyrcona |
Anyway, at that point GNU Make is passing the error up from an executable that it has run. The first [3] suggests it is in the 3 recursive make call, so 3 three Makefiles down. |
| 16:00 |
bshum |
linuxpoet: Actually it seems perfectly reasonable to me for Dyrcona to suggest using one of the established known linux distributions that are currently supported by the community documentation for OpenSRF. |
| 17:06 |
* Dyrcona |
recently cleaned his hates up. ;) |
| 17:06 |
dbwells |
paxed: Sorry, was afk. Yes, just confirming that 2.5.0-alpha1 targetting is fine and expected. |
| 17:06 |
|
kmlussier1 joined #evergreen |
| 17:06 |
gmcharlt |
@love test cases |
| 17:06 |
pinesol_green |
gmcharlt: The operation succeeded. gmcharlt loves test cases. |
| 17:06 |
bshum |
@love Fridays |
| 17:06 |
pinesol_green |
bshum: The operation succeeded. bshum loves Fridays. |
| 17:06 |
rfrasur |
@caresabout |
| 17:27 |
* rfrasur |
decides doing payroll is better than sifting through county personal income growth study. |
| 17:28 |
jeff_ |
yeah. i'm not even lucky enough to get it in PickupLocation, but it's in ItemShipped/ShippingInformation/PhysicalAddress/UnstructuredAddress |
| 17:29 |
Dyrcona |
Gotta love standards that aren't. |
| 17:29 |
jeff_ |
There are codes in the system for individual branches, but the codes don't seem to be used here, so it's unstructured freeform-looking text. |
| 17:29 |
jeff_ |
This is because I got impatient and jumped ahead and found a way to test without our contact at the state level, so I could be shown a better way on Monday, but it is seeming unlikely. |
| 17:30 |
Dyrcona |
Y'know, it is valid to respond with just the version response if you don't "understand" a message you've received. |
| 17:30 |
jeff_ |
It is incredibly likely that we will not expose our end users to the statewide web interface, and will just scrape it on their behalf. :P |
| 17:31 |
* Dyrcona |
shudders at the mention of scraping. |
| 12:22 |
rfrasur |
my thinking was...present this to comp sci professors/departments as an educational tool. So, these kids may not actually be involved in the EG community (yet...or ever) or contributing/building anything of value (right now...or ever) |
| 12:23 |
rfrasur |
but, it's free software that requires all the basics that get covered in a comp. eng./sci. program...and if the net was thrown over a broad enough area, there could protentially be some quality return. |
| 12:24 |
|
laque|2 joined #evergreen |
| 12:26 |
egbuilder_ |
build #257 of evergreen-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/257 blamelist: Bill Erickson <berick esilibrary.com> |
| 12:26 |
egbuilder_ |
build #233 of evergreen-master-ubuntu-12.04-x86 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/233 blamelist: Bill Erickson <berickesilibrary.com> |
| 12:26 |
egbuilder_ |
build #199 of evergreen-master-fedora-18 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/199 blamelist: Bill Erickson <berickesilibrary.com> |
| 12:28 |
eeevil |
dangit |
| 12:28 |
* eeevil |
goes to fix |
| 12:29 |
bshum |
buildbot++ |
| 12:36 |
pinesol_green |
Launchpad bug 833820 in Evergreen "Support PO activation without requiring bibs/items" (affected: 1, heat: 8) [Wishlist,Triaged] https://launchpad.net/bugs/833820 - Assigned to Dan Wells (dbw2) |
| 12:37 |
berick |
dbwells: will do |
| 12:38 |
dbwells |
berick: thanks! |
| 12:46 |
egbuilder_ |
build #258 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/258 |
| 12:46 |
egbuilder_ |
build #234 of evergreen-master-ubuntu-12.04-x86 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/234 |
| 12:46 |
egbuilder_ |
build #200 of evergreen-master-fedora-18 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/200 |
| 12:55 |
rfrasur |
why wouldn't Google+ integrate bookmarks into a person's profile? |
| 12:56 |
dbs |
rfrasur: possibly because it would require browser integration, and not everyone uses Chrome? |
| 12:56 |
* rfrasur |
uses Firefox as default. |
| 14:13 |
rfrasur |
I like the idea of the Google Hangout. It may be difficult for those further abroad to handle two trips out east (in our case). |
| 14:14 |
kmlussier |
Sure, I don't think I could travel out of state to a doc hack-a-way this year, but would be happy to join via a Hangout if it is hosted in another area. |
| 14:15 |
yboston |
BTW, with my intern I used Dropbox to share the files she was converting to AsciiDoc, which we can use in combination with Google hang out |
| 14:15 |
dbs |
I highly recommend getting people who plan to join via Google Hangout to go through a test run a few days before, just to ensure everyone's equipment is all good :) |
| 14:15 |
yboston |
dbs: thanks |
| 14:15 |
rfrasur |
dbs: very good point |
| 14:16 |
yboston |
we can try it during a DIG meeting |
| 16:51 |
dbs |
we also added some custom code to support users logging in with their LDAP username, even though their actor.usr.usrname was their email address, because of the likelihood of dscottlaurentian.ca clashing with dscottuwindsor.ca when it came to LDAP uids |
| 16:51 |
dbs |
but that's only a consortial concern where more than one LDAP (or CAS in the case of Windsor) system is in play |
| 16:52 |
dbs |
LDAP CNs, I should use the appropriate terminology :) |
| 16:55 |
dbwells |
berick: are you actively testing it now? I have a bug fix branch I made a while back for a specific request here in IRC, but never heard back whether it helped them or not. I am going to try and figure out what happened to that. |
| 16:55 |
berick |
dbwells: not this second, but will be doign some poking soon-ish |
| 16:56 |
berick |
i'd be glad to review the code. not sure if I know enough to be of assistance just yet, though. |
| 16:57 |
|
mtcarlson joined #evergreen |
| 10:24 |
paxed |
so the surveys cannot be answered anymore? |
| 10:24 |
|
kmlussier joined #evergreen |
| 10:25 |
|
jboyer-isl joined #evergreen |
| 10:28 |
rfrasur |
paxed: my understanding, and this is old understanding that might have been wrong in the beginning - was you could set it up whenever and when it went into effect, it'd alert you when you went into the patron account. |
| 10:28 |
* rfrasur |
has never used it. |
| 10:28 |
|
Meliss1 joined #evergreen |
| 10:28 |
* rfrasur |
will do a lil test |
| 10:29 |
paxed |
i only quickly glanced at the UI today (and filed bug 1199626) |
| 10:29 |
pinesol_green |
Launchpad bug 1199626 in Evergreen "Add New Survey asks start and end dates in US format" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1199626 |
| 10:30 |
|
bshum joined #evergreen |
| 11:08 |
rfrasur |
I did clear the cache, but it might not have been enough. |
| 11:08 |
phasefx |
the view under Other is read-only. I think the patron editor and offline patron registration is the only other places they show up |
| 11:09 |
* paxed |
hopes for several utf-8 related fixes in -m2 ... :P |
| 11:10 |
rfrasur |
testing |
| 11:11 |
rfrasur |
(an automatic reload when saving configuration would be nice as well) |
| 11:13 |
rfrasur |
okay...the read only did show up... |
| 11:13 |
rfrasur |
ty phasefx. hunting around still. |
| 11:15 |
phasefx |
rfrasur: automatic reloads may be trickier than you might think, if you expect all of your workstations to instantly get changes like that. At the time, the mindset was that a lot of these changes were supposed to be treated as big deals and not on the fly tinkering. I'd like instant updates, though |
| 11:15 |
rfrasur |
and it's in the patron registration, but not in the patron acct editor...registration and offline registration. |
| 11:16 |
rfrasur |
phasefx: yeah, I understand...and I tend to do a lot more on-the-fly things anyway. the whole break it and ask questions later. |
| 11:26 |
|
acoomes joined #evergreen |
| 11:26 |
phasefx |
was a developer itch, but I don't think it was something PINES was pushing for, so it didn't land in jspac |
| 11:27 |
rfrasur |
personally, I don't have any desire to do a survey through the OPAC. I think it'd cheese some people off and confuse some others. But, if that's the case, and maybe it's already addressed in later versions, that needs to be removed from the UI |
| 11:28 |
Dyrcona |
gmcharlt: If you have a test version of MARC::Charset that you'd like me to try, just let me know. |
| 11:28 |
gmcharlt |
Dyrcona: soon |
| 11:29 |
Dyrcona |
cool |
| 11:29 |
phasefx |
rfrasur: I think the only reason for us to even want to implement over just using a dedicated javascript library is the js-lite mandate for the TPAC |
| 14:44 |
pinesol_green |
Launchpad bug 1103706 in Evergreen 2.4 "Hold ratios in circ policies cause errors when trying to renew items" (affected: 2, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1103706 |
| 14:45 |
|
jdouma joined #evergreen |
| 14:46 |
fparks |
bshum: Interesting in a good way? |
| 14:46 |
bshum |
fparks: I'm sure kmlussier and others will be quite interested in what you've found. |
| 14:47 |
bshum |
Sounds like a good thing though; I'll have to test it out too, but we don't use hold ratios in our system. |
| 14:47 |
kmlussier |
I'm in the process of adding it to Dyrcona's list of development branches. :) |
| 14:48 |
rfrasur |
Okay, lovelies - time to shut 'er down and make the trek south. |
| 14:50 |
kmlussier |
fparks: I'll see if I can test it soon. If it works, you will make a lot of our libraries very happy. :) |
| 15:05 |
jeff_ |
kmlussier: what does hold ratio decide for you? |
| 15:06 |
jeff_ |
kmlussier: are you using it to permit/deny renewals, or something else? |
| 15:07 |
kmlussier |
jeff_: We aren't using it yet because of bug 1103706. What we want to use it for is to prevent renewals when there are holds on the title and no available copies to fill that hold. |
| 15:12 |
gsams__ |
The worst part is I am having trouble duplicating the behavior |
| 15:12 |
gsams__ |
but I have seen it happen |
| 15:13 |
jeff_ |
you can't reproduce it with an item checked out, placing a copy-level hold on the item, then attempting renewal? |
| 15:14 |
gsams__ |
I haven't been able to so far, its really quite odd. I've been trying to track down the items that this has happened on |
| 15:14 |
gsams__ |
I just got a small list of items that this has happened and am about to run tests with those |
| 15:14 |
jeff_ |
gsams__: i suspect it may vary depending on if there are any other holds. |
| 15:15 |
gsams__ |
jeff_: and I can't verify if the holds were the only ones on those items/titles |
| 15:16 |
jeff_ |
my initial thought was that the copy check was done solely on action.hold_copy_map and that copy holds might not use ahcm -- but at least in 2.2, I've confirmed that copy level holds do indeed use ahcm. |
| 15:24 |
phasefx |
bshum: there's a list of overridable events for renewals in server/circ/util.js, line 3883 |
| 15:25 |
|
zerick joined #evergreen |
| 15:27 |
|
zerick joined #evergreen |
| 15:29 |
gsams__ |
jihpringle: I will test this out and submit a bug if I can duplicate it on our system. I don't currently see anything like that. |
| 15:31 |
jihpringle |
I don't think we ever submitted it as a bug, we just told our library to make sure to check things in first, but I agree that it is a bug |
| 15:35 |
|
mtcarlson joined #evergreen |
| 15:37 |
bshum |
csharp: There were improvements to patron search and UI, but yes, there's still something major going on. |
| 13:20 |
WNPL |
Would anybody know if there is a way to include a ILS User expiration in my reports? |
| 13:21 |
WNPL |
Expiration date* |
| 13:21 |
dbwells |
rfrasur: The intention of the event is to focus on development, especially complex or cross-feature development which can benefit from in-person developer interaction. I don't want to exclude people outright, but if a person cannot partcipate in such things, then this event isn't really for them. |
| 13:26 |
yboston |
rfrasur: I am a member of DIG, and I am planning on attending the hack-away. I am not very familiar with the code, but I already know some Template Toolkit basics, but if all else fails I can set up tests systems with brand new code at the hack away. I can also work on some documentation while there. |
| 13:27 |
yboston |
rfrasur: DIG also has rough plans to try to do our own documentation sprint / hack-a-way sometime in the next few months. We had one last year around the same time of the dev hack-a-way at my library in Boston |
| 13:27 |
kmlussier |
moodaepo: Sure, either Lori or Jim. I think Jim has the archive. |
| 13:28 |
rfrasur |
dbwells: yboston: will roll this around in my head for a few minutes - hookin' a youngin' up with a new card and some work/study for her fines. |
| 13:33 |
rfrasur |
okay...reading |
| 20:02 |
pinesol_green |
[evergreen|Dan Scott] Correct Linux staff client build instructions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=39c46c1> |
| 20:07 |
* bshum |
ponders |
| 20:15 |
mcooper |
bshum: what are you pondering? |
| 20:16 |
bshum |
mcooper: Reading the bug tickets and picking which to work on. |
| 20:16 |
bshum |
mcooper: Speaking of which, I vaguely remember testing your work for the admin perms so whenever you're finished with your rebase, I think we can move that along. |
| 20:16 |
pinesol_green |
[evergreen|Pasi Kallinen] Fix LP#1108668 by marking the internet access level column contents as translatable in fm_IDL.xml - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f0f70c4> |
| 20:17 |
mcooper |
bshum: funny you mention it, i did that just recently. needs some testing though. |
| 20:18 |
mcooper |
bshum: by me i mean, i try to do that before inflicting anything on other people |
| 20:18 |
mcooper |
=) |
| 20:18 |
bshum |
mcooper++ |
| 20:22 |
pinesol_green |
[evergreen|Jason Stephenson] Modify default logging of SIP2 in oils_ctl.sh. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2a8ca3> |
| 20:40 |
pinesol_green |
[evergreen|Pasi Kallinen] Don't let pref_ou repeat in staff recent searches list - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8a1598e> |
| 03:25 |
|
Lunchb0x joined #evergreen |
| 07:18 |
|
mrpeters joined #evergreen |
| 07:41 |
|
jboyer-isl joined #evergreen |
| 08:03 |
csharp_ |
so during the vandelay upload step, to which location is the file uploaded? I am expecting it to be in the location specified in <open-ils.vandelay><importer> in opensrf.xml, but I don't see it there |
| 08:04 |
csharp_ |
also not in /tmp on either of the brick heads on my test server |
| 08:28 |
|
kbeswick joined #evergreen |
| 08:36 |
berick |
csharp_: the file is deleted after all the records are queued |
| 08:37 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
Shae joined #evergreen |
| 08:45 |
|
ericar joined #evergreen |
| 08:48 |
|
csharp joined #evergreen |
| 08:50 |
csharp |
berick: I guess I'm trying to see where in the process things are. I'm testing whether the ~250MB file I'm uploading is actually moving since I'm just seeing "Uploading..." on the interface. Just looking for a way to monitor progress |
| 08:51 |
berick |
ah, gotcha |
| 08:52 |
berick |
in that case, yes, you should see a file slowing growing in size in the directory configured under <importer> |
| 08:52 |
berick |
s/slowing/slowly/ |
| 15:01 |
kmlussier |
csharp: My understanding is that our consortia limit the size of their uploads, but I can't remember what limit they used. |
| 15:01 |
csharp |
it's possible that my staff client auth session timed out while it was running too |
| 15:01 |
csharp |
ah - makes sense |
| 15:02 |
kmlussier |
I don't think anyone did a test to see how large the files could get. But I can check. |
| 15:02 |
csharp |
thanks |
| 15:02 |
|
tmccanna left #evergreen |
| 15:05 |
|
tmccanna joined #evergreen |
| 16:10 |
Dyrcona |
MARC::CharSet just loves them to death! |
| 16:13 |
Dyrcona |
gmcharlt: I'll be emailing you some examples a bit later, possibly tomorrow. |
| 16:13 |
gmcharlt |
Dyrcona++ |
| 16:13 |
rfrasur |
Hah! Have been wanting to test some Korean records. How many characters are in the vietnamese charset? |
| 16:14 |
Dyrcona |
Phép lạ của sự tỉnh thức. |
| 16:15 |
Dyrcona |
That's what seems to be causing the problem. |
| 16:15 |
rfrasur |
oh...that's not what I was expecting. |
| 07:47 |
dbs |
paxed: a major part of the value of review & sign-off is reproducing the before / after behaviour in a separate environment, as well as ensuring nothing else breaks unexpectedly as a result. so, not really :/ |
| 07:48 |
* dbs |
is enjoying Canada Day, apparently |
| 07:51 |
paxed |
dbs: disheartening. |
| 07:53 |
dbs |
paxed: it's a time vs. quality thing. We keep on seeing what happens when we push commits that "look good" without actually testing them. |
| 07:53 |
dbs |
Or testing them in a very limited way. And testing in production, really, really sucks for the community. |
| 07:54 |
csharp |
bshum: thanks! |
| 07:57 |
csharp |
dbs: happy Canada Day! |
| 07:58 |
csharp |
not a holiday I take it? ;-) |
| 08:01 |
csharp |
dbs: ah - I see ;-) |
| 08:03 |
|
jasonb-iph joined #evergreen |
| 08:03 |
jcamins |
dbs: have you looked at things like gerritt? |
| 08:06 |
dbs |
jcamins: it's more about testing & reproducing UI behaviour (selenium etc) than code review tools |
| 08:07 |
|
Dyrcona joined #evergreen |
| 08:08 |
jcamins |
dbs: ah. We have both problems with Koha. |
| 08:10 |
dbs |
for example, paxed has a patch that affects 8 or so different dialogues in the staff client. testing that means setting up a clean testing environment, reproducing the problem conditions (possibily requiring setup of special data to provoke the problem), setting up the test env + patch, reproducing the corrected scenarios... and all of that gives us no guarantee that other scenarios haven't been negatively affected by the patch |
| 08:10 |
dbs |
jcamins: I'm not saying gerritt or the like wouldn't be helpful, just a different problem :) |
| 08:21 |
|
finnx joined #evergreen |
| 08:25 |
|
rjackson-isl joined #evergreen |
| 08:34 |
|
laque joined #evergreen |
| 18:12 |
|
konr_revmob joined #evergreen |
| 18:12 |
|
finn1 joined #evergreen |
| 18:13 |
|
finnx1 joined #evergreen |
| 18:14 |
konr_revmob |
Can I test whether, say, the infinite scroll functionality works in my website using evergreen, or its not the appropriate tool? |
| 18:15 |
|
finnx1 left #evergreen |
| 18:18 |
|
finnx1 joined #evergreen |
| 18:19 |
|
finnx1 left #evergreen |
| 07:21 |
|
Dyrcona joined #evergreen |
| 07:32 |
|
jboyer-isl joined #evergreen |
| 07:34 |
|
bkuhn joined #evergreen |
| 08:25 |
csharp |
okay - I'm back to troubleshooting my circ rule issue - the problem is that we have a rule based on a circ modifier called 'dvd' assigned to dvd items. When I use the find_circ_matrix_matchpoint test on an item, patron, and location on our production server, the correct rule matches. When I do the same test on our test server, it picks a different rule. |
| 08:25 |
csharp |
The only thing I've changed is linking a circulation limit set |
| 08:26 |
csharp |
the rule it selects on our test server is based on the item's marc type |
| 08:27 |
pastebot |
"csharp" at 204.193.129.146 pasted "circ policy matching descrepancy" (16 lines) at http://paste.evergreen-ils.org/34 |
| 08:27 |
csharp |
as you'll see in the paste, rule 159 no longer matches |
| 08:27 |
|
timf joined #evergreen |
| 08:30 |
Dyrcona |
@quote random |
| 08:30 |
pinesol_green |
Dyrcona: Quote #21: "< Dyrcona> Writing software is more fun than working." (added by csharp at 09:29 AM, November 29, 2011) |
| 08:36 |
|
kbeswick joined #evergreen |
| 08:37 |
csharp |
created CSVs of a dump of circulation policies on test and production and diffed them - no difference |
| 08:39 |
csharp |
btw - test image is from 6/26, so no substantial differences between the datasets |
| 08:40 |
|
finnx joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
Dyrcona |
csharp: I've not ever seen the behavior you described in my environment. If I check something out in production and in development, I get the same matchpoint. |
| 09:26 |
csharp |
I'm using the Default weightset, which has worked fine for us until now |
| 09:28 |
* bshum |
checks to see what that is :) |
| 09:33 |
pastebot |
"csharp" at 204.193.129.146 pasted "default weightset" (7 lines) at http://paste.evergreen-ils.org/35 |
| 09:36 |
bshum |
csharp: Can you paste the rules 139 and 159 from your test server? |
| 09:36 |
bshum |
Curious to see what the rows look like. |
| 09:37 |
pastebot |
"csharp" at 204.193.129.146 pasted "more details on circ limit set setup" (43 lines) at http://paste.evergreen-ils.org/36 |
| 09:37 |
|
rfrasur joined #evergreen |
| 09:38 |
csharp |
I'll paste 139 too |
| 09:38 |
pastebot |
"csharp" at 204.193.129.146 pasted "circ matrix matchpoint 139" (4 lines) at http://paste.evergreen-ils.org/37 |
| 09:39 |
bshum |
What's the copy location of the item you're testing? |
| 09:39 |
bshum |
Just the first thing that jumped out to me looking at rule 159 |
| 09:39 |
|
remingtron joined #evergreen |
| 09:39 |
bshum |
Hopefully 7404 |
| 09:39 |
csharp |
we don't use copy locations in our rules since copy locations are managed at the library level |
| 09:40 |
csharp |
that would multiply our number of rules exponentially |
| 09:40 |
bshum |
But 7404 is in the column for "copy_location" in the paste. |
| 10:03 |
bshum |
Just thinking aloud, but it seems bad to allow copy location to be set for a specific library if they're also creating consortium level rules (or rules in general that affect greater than just them). |
| 10:03 |
csharp |
Indiana's still using script-based circ too, I think |
| 10:04 |
* csharp |
agrees |
| 10:04 |
bshum |
Since we don't let end users create policy, I don't think we've ever tested restricting the level of rules they can create. |
| 10:04 |
rfrasur |
csharp: yes...I think we are (because it breaks from time to time) |
| 10:04 |
bshum |
Or if that's possibly restricted by permission. |
| 10:12 |
rfrasur |
So, explain to me while I'm editing a million call #s - why not to use the "circ as type" attribute? |
| 10:17 |
rfrasur |
hmm, our circ policies are based on circ modifiers |
| 10:17 |
rfrasur |
meh |
| 10:17 |
jeff_ |
But those incorrect bibs should still be fixed -- because the copy-level override for circulate as type will do nothing to fix the other issues caused by the incorrect MARC data -- mostly with searching and display in the catalog. |
| 10:17 |
dbs |
paxed's fixes in bug 1195334 looks like it's probably golden, but because we lack any sort of UI test automation to reproduce the problems before the patch and show that it's fixed after the patch, I'm reluctant to wade into applying & testing it myself |
| 10:17 |
pinesol_green |
Launchpad bug 1195334 in Evergreen "Some data URIs don't define character set" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1195334 |
| 10:18 |
dbs |
and without testing, I'm not going to commit anything. Which is a major part of our QA problem in a nutshell, methinks. (surprise, broken record, whatever) |
| 10:22 |
mrpeters |
is there any way to test a LONG (14 day) grace period without checking out an item and waiting 2 weeks? --- using in-db circ |
| 10:24 |
mrpeters |
i suppose i could check out an item for 1 day and see if it accrues fines over the weekend... |
| 10:26 |
bshum |
mrpeters: I haven't tried it recently, but I think you could edit the circulation entry to be in the past, like 10 days past due or whatnot. |
| 10:26 |
Dyrcona |
mrpeters: Check it out and change the due date to the past? |
| 10:26 |
bshum |
mrpeters: Through the DB |
| 11:25 |
jeff_ |
k. |
| 11:25 |
jeff_ |
i forget that reports have debug output now. :-) |
| 11:25 |
mrpeters |
ya itsnice |
| 11:26 |
* rfrasur |
is running a test report (obviously not the same one...but similar) |
| 11:26 |
rfrasur |
so...in a couple hours.... |
| 11:28 |
mrpeters |
http://pastie.org/private/af01zwkuj3hikoucyobttg |
| 11:30 |
rfrasur |
(is it just me or are Indiana reports taking longer and longer and longer to generate?) |
| 11:33 |
mrpeters |
big database.... |
| 11:38 |
mrpeters |
they all look like normal circs.....except the "migrated" ones have no due date |
| 11:39 |
mrpeters |
http://imageshack.us/a/img838/5477/auvn.png |
| 11:39 |
|
collum joined #evergreen |
| 11:39 |
jeff_ |
mrpeters: er, that contains patron data. |
| 11:39 |
jeff_ |
unless those are test users. |
| 11:40 |
mrpeters |
yeah, guess i better obscure that |
| 11:40 |
mrpeters |
image deleted |
| 11:41 |
mrpeters |
http://imageshack.us/a/img834/102/hj51.png |
| 13:57 |
* rfrasur |
is def not THAT cool |
| 13:58 |
bshum |
jeff_: I have multiple accounts to LP but only get notifications to one as well. I don't think it sends to more than one. |
| 13:58 |
bshum |
Since you're cool and have gapps though, you could probably setup a filter to find LP emails and forward them on and only those. |
| 14:05 |
hopkinsju |
jeffdavis: I added CASCADE to the upgrade script and it completed successfully. It took quite a while but I'm finally done upgrading this test DB to 2.4. OPAC searching is being weird though... |
| 14:05 |
hopkinsju |
Searching takes forever and so far I'm seeing queries that should return results not returning any results on the first try, but oddly returning them on the second attempt. |
| 14:05 |
rfrasur |
Hah! One of those two staff members is already GOING to GenCon (no money from lib needed) |
| 14:06 |
hopkinsju |
I need to have a better way to test that the db upgrades *really* worked well. |
| 14:07 |
bshum |
hopkinsju: Returning on the second attempt sounds like the query ran long and didn't finish till later. And it being cached. |
| 14:07 |
hopkinsju |
bshum: Makes sense |
| 14:07 |
Dyrcona |
hopkinsju: You probably have to reingest. |
| 14:27 |
dbs |
GIN takes more space, more time to build, but is faster |
| 14:27 |
bshum |
faster++ |
| 14:27 |
* csharp |
peruses http://www.postgresql.org/docs/9.1/static/textsearch-indexes.html |
| 14:27 |
jeffdavis |
metabib_title_field_entry_index_vector_idx is a GIN index on our upgraded 2.4 test db |
| 14:27 |
dbs |
and will be required if oleg / alex gets their super-fast text search patches in |
| 14:27 |
rfrasur |
faster++ |
| 14:27 |
* Dyrcona |
has had some recent experience with faster in a different context. |
| 16:09 |
* bshum |
ponders how safe it is to make a copy of m_* migration schemas and then drop them from production DBs. |
| 16:09 |
rfrasur |
you live dangerously, remember? |
| 16:10 |
* rfrasur |
does payroll and prepares to be entertained by bshum living dangerously. |
| 16:10 |
bshum |
rfrasur: You've got a point. And hey that's what test databases are for right? :D |
| 16:11 |
rfrasur |
bshum: that's exactly right. |
| 16:11 |
* rfrasur |
cues music https://www.youtube.com/watch?v=7nqcL0mjMjw |
| 16:13 |
|
stevenyvr2 joined #evergreen |
| 09:02 |
rfrasur |
okay, I got it going. thank you |
| 09:03 |
rfrasur |
okay, thanks sir. see ya later. |
| 09:22 |
|
ericar joined #evergreen |
| 09:27 |
* dbs |
noticed, while testing the upgrade path for the catapostrophe fix from 2.3 - 2.4, that the 2.3-2.4.0 upgrade script will bomb out for anyone who recently installed 2.3 due to having already applied upgrade 0788. I suppose we should move that into its own transaction in the upgrade script. |
| 09:29 |
dbs |
huh, or is that because I installed from rel_2_3 and not a packaged version which might get a different value in 002.schema.config.sql? |
| 09:29 |
* dbs |
looks |
| 09:31 |
dbs |
Nope, that's in the packaged 2.3.8 tarball |
| 09:31 |
|
afonit joined #evergreen |
| 09:32 |
dbs |
and 2.3.7 |
| 09:34 |
|
DPearl joined #evergreen |
| 09:36 |
eeevil |
yeah ... I'll pull 788 into its own chunk. soon |
| 09:36 |
paxed |
bah. character encoding problems in javascript. |
| 13:17 |
hopkinsju |
dbs: gotta run an errand, but will do! |
| 13:25 |
|
ericar joined #evergreen |
| 13:38 |
|
mcooper joined #evergreen |
| 13:52 |
csharp |
circ policy changes (in-db) are immediate, right? no need for autogen/opensrf restart? |
| 13:52 |
* csharp |
has apparently borked circ on his test server |
| 13:53 |
csharp |
same dataset, same ruleset on prod/test, same item, same patron, same, location, different rules are chosen |
| 13:54 |
csharp |
test is picking the default rule, prod selects the correct rule |
| 13:54 |
csharp |
"default rule" = id 1 |
| 13:54 |
csharp |
@monologue |
| 13:54 |
pinesol_green |
csharp: Your current monologue is at least 6 lines long. |
| 13:56 |
mcooper |
csharp: believe they are immediate … delete all rules and circs can't happen, w/o having to restart anything (if I recall correctly) ... |
| 13:56 |
csharp |
ok |
| 18:41 |
jeffdavis |
backups++ |
| 18:41 |
jeffdavis |
@karma backups |
| 18:41 |
pinesol_green |
jeffdavis: Karma for "backups" has been increased 3 times and decreased 0 times for a total karma of 3. |
| 18:41 |
Dyrcona |
Anyway, now I have a chance to test a C version of xpath. |
| 18:42 |
rfrasur |
backups needs more karma |
| 18:42 |
Dyrcona |
backups++ |
| 18:42 |
Dyrcona |
backups times elebenty! |
| 11:34 |
eeevil |
dbs: any thoughts on the end of bug 1187433? |
| 11:34 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 3, heat: 20) [High,Confirmed] https://launchpad.net/bugs/1187433 |
| 11:34 |
rfrasur |
paxed++ |
| 11:40 |
dbs |
eeevil: Still need to test it, just to be sure |
| 11:40 |
dbs |
but looks good |
| 11:41 |
dbs |
in the mean time, if any QP-knowledgeable folks would care to figure out why a search for "big : bad : groovy" results in 6 "text-search ':*' contains no lexemes" errors, that would be teh awesome :) |
| 11:41 |
rfrasur |
I just have to say, y'all are the sanest, least anger/anxiety/frustration-producing group of people that I deal with (excepting my family). It may be a very low bar, but thanks anyways. |
| 11:42 |
eeevil |
dbs: that's a fair trade ... I'll look |
| 11:45 |
dbs |
eeevil: I spent some time trying to protect empty queries from reaching QP in Search/Biblio.pm, but realized that testing with srfsh with queries like "" or ":*" weren't representative of what actually gets passed in from TPAC (" pref_ou(103)" and the like appended to the end) |
| 11:45 |
dbs |
So I think ultimately QP is the answer :/ |
| 11:46 |
|
jdouma joined #evergreen |
| 11:47 |
eeevil |
yeah ... I think I see where it's coming from. I'm trying to think of a reason why we would want to allow a bare ":" as an atom |
| 11:47 |
kmlussier |
Heads up. The web team meeting will be starting here in 13 minutes. |
| 11:48 |
dbs |
eeevil: in phrase-searches too? |
| 11:49 |
dbs |
(in the real world, most of the bare " : " come from copying/pasting a title into a search box) |
| 11:49 |
eeevil |
dbs: are the :s in "value" for you? (I'm sure you have this documented on a bug ... /me goes to look) |
| 11:50 |
dbs |
eeevil: no, there's no bug, I was researching / bashing my head yesterday |
| 11:51 |
dbs |
eeevil: and yes, the :s are in "value" |
| 11:53 |
* dbs |
recreates a local concerto test database - see "Critical entertainments : music old and new" as an example |
| 11:54 |
dbs |
"La canzone italiana del Novecento" includes 2 " : " segments in its title |
| 11:59 |
|
mcooper joined #evergreen |
| 12:01 |
bshum |
kmlussier: Hmm, time? :) |
| 12:01 |
* bshum |
doesn't know who else is even here... |
| 12:19 |
Rogan_ |
sounds good |
| 12:19 |
bshum |
+1 |
| 12:19 |
moodaepo |
kmlussier: I was thinking the same. +1 |
| 12:20 |
kmlussier |
#info moodaepo to continue working on test site |
| 12:20 |
kmlussier |
Though I think bshum has been working on this one too. |
| 12:20 |
kmlussier |
Who wants to give an update? |
| 12:20 |
bshum |
I'm multi-tasking :) |
| 12:20 |
moodaepo |
bshum has taken on doing a test site [ http://evergreener.net/ ] ..I've just been providing him with support right now. We did discuss plans on moving forward and will be emailing it to the list soon for feedback. |
| 12:20 |
moodaepo |
bshum++ |
| 12:21 |
kmlussier |
It's pretty! |
| 12:21 |
bshum |
The fun thing we learned while working on the wordpress site prototype is dealing with non-javascript-enabled browsers. |
| 12:21 |
bshum |
There are lots of pretty themes, but not all of them function well without javascript-enabled. |
| 12:23 |
moodaepo |
or even one hand :) |
| 12:23 |
kmlussier |
moodaepo++ |
| 12:23 |
bshum |
I'd volunteer, but my email isn't trustworthy right now. |
| 12:24 |
kmlussier |
#action moodaepo to e-mail link to test site to the list for feedback. |
| 12:24 |
kmlussier |
moodaepo: That's the general list, right? |
| 12:24 |
Rogan_ |
I would say yes. |
| 12:24 |
moodaepo |
kmlussier: Yup |
| 12:25 |
kmlussier |
Anything else before we move on to the next action item? |
| 13:28 |
rfrasur |
rock on |
| 13:36 |
|
kbeswick joined #evergreen |
| 13:37 |
|
b_sage joined #evergreen |
| 13:39 |
DPearl |
Event/trigger question. I have created a clone of the hold available email event (consortium-level) for a library that wants to include a special message in the email. When testing, the first try got the library's handler; the second try got the consortium handler. I can see why this might have happened, but it seems to me to be incorrect behavior (going up a level). Or is this desirable? |
| 13:42 |
bshum |
DPearl: So, in practice, you cannot have both a consortium level hold available and also a library specific one. |
| 13:42 |
bshum |
Because the event will fire off both. |
| 13:42 |
bshum |
or at least, that's been my experience. |
| 16:58 |
hopkinsju |
bshum: Did that answer your questoin? Looks like it's in the evergreen schema. |
| 16:58 |
bshum |
hopkinsju: Yes, that helps. Thanks. |
| 17:05 |
pastebot |
"hopkinsju" at 204.193.129.146 pasted "Ok, now this is weird..." (58 lines) at http://paste.evergreen-ils.org/31 |
| 17:07 |
gmcharlt |
Dyrcona: did you happen to make the binary MARC record available? I'm lhappy to add test cases for MARC::Charset |
| 17:08 |
Dyrcona |
gmcharlt: I didn't because I was able to get mostly what I needed from yaz-marcdump, plus I've been having fun with other things today. |
| 17:08 |
Dyrcona |
gmcharlt: I think this file is a mix of records in latin 1 and marc 8. |
| 17:08 |
gmcharlt |
I'd appreciate having it if you get a spare moment |
| 17:20 |
|
mllewellyn1 left #evergreen |
| 17:20 |
bshum |
dbs: Seems to me that tsvector_concat is something we can safely drop away if it's no longer in the code base. Like so many other functions that get stuck lying around. |
| 17:21 |
hopkinsju |
gmcharlt: *dum dum duuuuum* "$user",public |
| 17:21 |
gmcharlt |
hopkinsju: k, thought so -- when your test DB finishes resyncing, I suggest running the following before trying the (unmodified) upgrade script: |
| 17:21 |
gmcharlt |
ALTER DATABASE evergreen SET search_path TO evergreen, public, pg_catalog; |
| 17:22 |
bshum |
gmcharlt++ |
| 17:22 |
hopkinsju |
gmcharlt: Thank you, I will try that. |
| 17:22 |
hopkinsju |
Gonna have to let this go and check back later though. Gotta get my daughter to karate. |
| 20:26 |
rfrasur |
so they (whoever they are) may not understand what all that means, but can get a broad idea and have a little higher comfort level in talking w/ people re: more technical stuff. |
| 20:26 |
* rfrasur |
saw that with the feed as well. |
| 20:26 |
rfrasur |
I was all excited that 2015 was going to be in Grand Rapids...until it was 2009 or 10 |
| 20:26 |
bshum |
Heh |
| 20:28 |
bshum |
rfrasur, I'm going to be modifying the wordpress prototype for a moment. Want to test out something with a different theme. |
| 20:28 |
rfrasur |
I am legitimately excited about the direction the website is going, btw. I think it'll be much more accessible. |
| 20:28 |
rfrasur |
(and not in an ADA sort of way, but maybe that, too) |
| 20:28 |
rfrasur |
okie |
| 08:54 |
csharp |
circ_policies-- |
| 08:59 |
Dyrcona |
csharp: We think we're successfully limiting with limit sets. |
| 08:59 |
|
ericar joined #evergreen |
| 09:02 |
csharp |
Dyrcona: thanks - looks like my first problem is that the circ policy I'm expecting to be chosen isn't being chose |
| 09:02 |
csharp |
n |
| 09:03 |
csharp |
so now I'm playing with weights, which is pretty complex |
| 09:04 |
* csharp |
is *so* glad we have find_circ_matrix_matchpoint() to test with |
| 09:04 |
tsbere |
csharp: Between poking at our mail server I can probably answer questions about some of that for ya |
| 09:05 |
tsbere |
csharp: For note, easy way to limit by circ mod: Create a circ matrix line that matches the circ modifier and as little else as possible with no circulate flag or rules. Attach limits to *that* rule with fallthrough flag checked. |
| 09:08 |
csharp |
tsbere: thanks for that tip |
| 09:41 |
tsbere |
Then I would assume I was wrong. ;) |
| 09:41 |
csharp |
heh |
| 09:44 |
pinesol_green |
[evergreen|Mike Rylander] Only attempt to map copies once per hold - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fceea3d> |
| 09:44 |
paxed |
haha. testing some improvements for bug 1156545 - i guess a bill for $1234567.80 is a bit too much: ERROR: numeric field overflow |
| 09:44 |
pinesol_green |
Launchpad bug 1156545 in Evergreen "Currency symbol and format should not be in po-file translatable texts" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1156545 |
| 09:46 |
senator |
we have lots of fields defined as numeric(6,2), although depending on the currency that could be too limiting i suppose |
| 09:46 |
paxed |
it's unlikely the patron bill would hit that much. |
| 14:12 |
|
kmlussier joined #evergreen |
| 14:16 |
jeffdavis |
so, regarding bug 1187433 ... |
| 14:16 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 3, heat: 20) [High,Confirmed] https://launchpad.net/bugs/1187433 |
| 14:16 |
jeffdavis |
We're doing a 2.2->2.4 upgrade, so my understanding is I just need to integrate this commit into our db upgrade stuff: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=1b64d6e |
| 14:17 |
jeffdavis |
Assuming that's correct, I can try it out in a test environment tomorrow. |
| 14:21 |
|
kmlussier1 joined #evergreen |
| 14:24 |
|
jrshaw joined #evergreen |
| 14:26 |
|
kbeswick joined #evergreen |
| 15:06 |
jeffdavis |
It looked to me like the necessary changes from the other commits are in the upgrade script, but it's a long ticket and I get a little paranoid before major version upgrades. ;) |
| 15:08 |
jeffdavis |
s/ticket/bug/ |
| 15:09 |
bshum |
It's healthy to be mindful of potential pitfalls. |
| 15:24 |
jrshaw |
Oh the fun. Back to the 2.4 client Install... Went to lunch. The system hibernated. Powered up. corrupted system image. discarded the hiber-image and did a clean reboot. Full functionality has been restored. I can repeatedly start the Client and it works. Now to find a working 2.4 test server that works... |
| 15:25 |
jrshaw |
demo.ils.edoceo.com produces a "There was an error testing the hostname." error |
| 15:26 |
csharp |
jrshaw: so are your complaints purely about getting the client up and running, or are you installing a server too? |
| 15:28 |
jrshaw |
I'm taking this one step at a time. I've decided to work on Clint configuration since that would be a simpler and shorter process. just need to know how to interface the client to the test server. |
| 15:28 |
kmlussier |
jrshaw: demo.ils.edoceo.com is working for me. You may need to add a SSL Exception for the server. |
| 15:29 |
kmlussier |
Or, I should say, it would work if I had the right staff client version. |
| 15:30 |
jrshaw |
So you bumped into that problem (wrong client version) too... |
| 10:33 |
mmorgan1 |
seems like it's possible for a barcode scanner to feed in digits faster than they can register in evergreen |
| 10:34 |
rfrasur |
hmm, I haven't seen that but I'm not with the scanners much anymore either. |
| 10:36 |
mmorgan1 |
rfrasur: btw, regarding the upc, you may be able to program your barcode scanners not to recognize these, as long as your book barcodes aren't the same kind |
| 10:37 |
csharp |
mmorgan1: a simple test might be to scan the same barcodes into a text editor and see if the errors persist |
| 10:38 |
csharp |
in our experience, those kinds of mis-scans are the fault of the scanner itself FWIW |
| 10:38 |
csharp |
(or *ahem*, staff) |
| 10:38 |
rfrasur |
mmorgan1: you're right, we probably could. but, I'm the IT department (it's sorely lacking) and the everything else, and decided it was easier to move the barcodes away from the UPC (they're never on the back anymore) and explicitly teach the full staff re: barcodes in general. The obnoxious of the tutorial and the prospect of getting it again was a deterrent. |
| 10:40 |
csharp |
and "strict barcode" doesn't stop the creation of invalid barcodes - it just checks for them when scanning |
| 10:40 |
|
dboyle joined #evergreen |
| 12:49 |
|
zerick joined #evergreen |
| 13:00 |
|
mtcarlson joined #evergreen |
| 13:00 |
mcooper |
I've been trying to convince people that new is exciting and full of potential for the better part of a year =) |
| 13:05 |
b_bonner |
Hi all. Our staff is starting to test the OCLC number scheme change that is starting next month, and noticed something quite odd. If an 001 OCLC number is the new style with "on" followed by 10 digits (on3987654321), it is NOT searchable in the opac (keyword or identifier). However, it IS searchable if it is |
| 13:05 |
b_bonner |
on" followed by 11 or 12 digits (on39876543211). Can someone help reproduce this and see if it's not just us? |
| 13:05 |
b_bonner |
I've been able to change the oclc number on the same record back and forth between and can confirm this scenario on our system |
| 13:07 |
b_bonner |
TCNs 1283817 (10 digit) and 1283816 (11 digit) on catalog.kcls.org if you want our examples |
| 13:15 |
dbs |
b_bonner: looks like it should be indexed and retrievable via identifier|scn ... |
| 13:18 |
dbs |
b_bonner: but right now catalog.kcls.org only seems to be returning 500 server errors :/ |
| 13:19 |
dbs |
in theory, if it was running, http://catalog.kcls.org/eg/opac/results?query=identifier|scn:3987654321 would give you what you're looking for |
| 13:29 |
|
kmlussier joined #evergreen |
| 13:30 |
b_bonner |
it is strange that identifier search on 001 works on other length entries, just not on+10 |
| 13:30 |
dbs |
b_bonner: it seems likely that you have something set up locally to do special things that don't match the Evergreen out-of-the-box experience. Hard to help with that :/ |
| 13:32 |
b_bonner |
dbs: hmm, thanks. will keep digging. Can you do me a favor and try changing an 001 on your test system to "on54987654321" and see if it can find it via keyword or identifier search? |
| 13:35 |
b_bonner |
dbs: and if not, does 11 digit? (on39876543211) |
| 13:40 |
csharp |
b_bonner: you might also poke around in the metabib tables to see if entries for each of those records are present |
| 13:40 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier|scn:on54987654321 works |
| 13:41 |
dbs |
... but it's not getting (OCoLC)54987654321 as a 035$a like I would have expected. |
| 13:41 |
dbs |
possibly because we have an institutional ID set? hrm. |
| 13:42 |
b_bonner |
csharp: first thing I did. every thing looks identical between them in metabib.identifier_field_entry between them when 10 or 11 digits, just search failing on 10 |
| 13:42 |
csharp |
hmm |
| 13:44 |
b_bonner |
dbs csharp: query captured: http://pastebin.com/VpAteZRd |
| 13:44 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier|scn:on39876543211 also works |
| 13:45 |
dbs |
but really, the "on" should be stripped off |
| 13:45 |
b_bonner |
dbs: any results without the scn? |
| 13:45 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier:on39876543211 works fine too |
| 13:45 |
b_bonner |
we have an identifer set up (accession) on the 001 tag |
| 13:46 |
dbs |
Yeah, that's an out of the box thing |
| 13:46 |
b_bonner |
and without scn on the 10 digit? |
| 13:46 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier:on54987654321 works too |
| 13:47 |
dbs |
Note that our system is set up to replace the 001 with the bib ID each time, so the results will show 001 739015 |
| 13:47 |
dbs |
But you can see the 035 $a that were added. |
| 13:48 |
b_bonner |
dbs: yeah, that changes the scenario quite a bit |
| 13:48 |
* dbs |
tries an ocn prefix, that works too. |
| 13:48 |
dbs |
b_bonner: why? |
| 14:31 |
jeffdavis |
dbs: we don't have the 8 latest commits in rel_2_4 yet |
| 14:32 |
jeffdavis |
i'll try to integrate them after hours today |
| 14:32 |
dbs |
lemme tell you, it's nice to be down to 4,000 WARN messages today |
| 14:36 |
jeffdavis |
yeah, i'd like that fix - our test server osrfsys.log has 60K WARN messages from the past 36 hours |
| 14:36 |
jeffdavis |
or I guess those multiple fixes |
| 14:37 |
* jeffdavis |
adds rebase to todo list, says goodbye to any remaining time off this weekend ;) |
| 14:37 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1192710 was a pretty good one too |
| 14:37 |
pinesol_green |
Launchpad bug 1192710 in Evergreen "QP uses numeric cmp operator for comparing strings, fills logs with warnings" (affected: 1, heat: 6) [Medium,New] |
| 14:37 |
dbs |
not yet signed off or committed |
| 15:19 |
csharp |
dbs: holy moly |
| 15:19 |
bshum |
Maybe there's something wonky there that's taking too long to process out. |
| 15:19 |
dbs |
kmlussier: it would be fun to be able to poke at your system to see the SQL that's getting generated and to enable the timelog for that part slowness |
| 15:19 |
bshum |
Blah |
| 15:20 |
bshum |
But of course, my only test server is running the custom new code for patron UI. |
| 15:20 |
bshum |
So that throws a kink in my testing :( |
| 15:20 |
csharp |
hrmm - I just got the message too |
| 15:20 |
bshum |
timelog++ |
| 15:20 |
csharp |
lemme try the original title reported as an example |
| 15:20 |
kmlussier1 |
csharp, bshum: I get the confirmation message on 2.3 |
| 15:20 |
bshum |
So then it's just csharp :( |
| 15:21 |
bshum |
Maybe it's some weird local customization run amok? |
| 15:22 |
bshum |
kmlussier1: You tested it via the staff client right? On behalf of a patron? I think that's where we're looking. |
| 15:22 |
csharp |
hmm - the original example (with 250+ copies attached) *doesn't* show the message |
| 15:22 |
kmlussier1 |
Yes, I followed the steps in the bug report. |
| 15:23 |
csharp |
so maybe the holdings are a factor? |
| 15:27 |
pinesol_green |
Dyrcona: It's all parts's fault! |
| 15:28 |
|
dboyle joined #evergreen |
| 15:28 |
Dyrcona |
csharp: There is no such thing as a normal library. |
| 15:28 |
bshum |
Nice, I apparently crashed my test server trying to place a hold via the new patron UI. |
| 15:28 |
* bshum |
adds that to the long list of things to work out :( |
| 15:29 |
|
kmlussier1 joined #evergreen |
| 15:29 |
|
jboyer-isl joined #evergreen |
| 15:32 |
|
kmlussier joined #evergreen |
| 15:34 |
* Dyrcona |
imagines a dynamic battle for survival between kmlussier and her evil clone, kmlussier1. |
| 15:34 |
bshum |
Doesn't seem to be a parts problem either. Though I haven't found bibs with lots of holdings to try further yet. |
| 15:34 |
bshum |
Dyrcona++ # I would watch that movie. |
| 15:35 |
bshum |
... uptime 10 minutes for the test server. Well that's... interesting. |
| 15:35 |
Dyrcona |
You caused it to reboot itself? |
| 15:36 |
Dyrcona |
I'd check the logs very carefully. It likely has nothing to do with what you were doing in Evergreen. |
| 15:36 |
bshum |
Yeah |
| 15:59 |
|
edoceo joined #evergreen |
| 16:01 |
bshum |
Hmm, it does seem noticeably slower though when I do try it against bibs with large number of holdings. |
| 16:02 |
bshum |
And the time it took to go from Submit to successfully placed took longer I mean. |
| 16:02 |
kmlussier |
bshum: Yes, it was much slower for me too. My first test on the record with just a few copies went through very quickly. |
| 16:04 |
kmlussier |
bshum: Did you say you had the alternate patron editor on the client where you were testing this? |
| 16:04 |
bshum |
kmlussier: I am using that, yeah. |
| 16:05 |
bshum |
kmlussier: But it's not very different. The issue I encountered previously was because the server suffered some mysterious reboot :( |
| 16:05 |
kmlussier |
I was just noticing that the catalog search/place holds screen loads in a different tab instead of being embedded in that patron frame. I wasn't sure if that would make a difference. |
| 13:27 |
tsbere |
That largely falls into login type defs, though |
| 13:27 |
bshum |
Heh |
| 13:27 |
bshum |
Gotcha. |
| 13:27 |
jihpringle |
i think part of the problem was in earlier versions of our testing server I wasn't getting the red bar for staff but I do now |
| 13:28 |
jihpringle |
thanks all |
| 13:36 |
* rfrasur |
has conquered the state system and reported and needs chocolate. |
| 13:37 |
rfrasur |
@love chocolate |
| 13:37 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur loves chocolate. |
| 14:33 |
kmlussier |
Sure. It probably won't happen until after ALA and my subsequent vacation. |
| 14:33 |
gmcharlt |
kmlussier: would you prefer to report back during the August meeting, then? |
| 14:34 |
kmlussier |
No, that gives a couple of weeks for discussion. I should have something to report. |
| 14:34 |
gmcharlt |
OK |
| 14:34 |
gmcharlt |
moving on |
| 14:34 |
gmcharlt |
#topic Announcement: Conference call for discussing organizing testing efforts |
| 14:35 |
gmcharlt |
sborger: you have the floor |
| 14:35 |
sborger |
Rogan, Andrea and I are planning a conference call on July 2 to further discuss organizing test efforts. |
| 14:35 |
sborger |
I figured that I had some very basic questions about where to get started and how to get my local staff involved so others probably do as well. |
| 14:35 |
sborger |
We will come up with a plan and share it at the next board meeting. |
| 14:36 |
gmcharlt |
#info Shauna, Rogan, and Andrea are planning a conference call on July 2 to further discuss organizing test efforts. |
| 14:36 |
gmcharlt |
any questions for sborger? |
| 14:36 |
sborger |
Let me know if you are interested in joining the conference call right away and keep in mind that we will most likely look for volunteers in the future as well. |
| 14:37 |
Rogan |
And the goal is to expand involvement so some of it may seem simple but anything that furthers the community through engagement and the work is worthy I think. |
| 14:38 |
montgoc1 |
What time on July 2? |
| 14:42 |
kmlussier |
Just a general comment. I've been very pleased with teh amount of communication with this release. Thanks Dan! |
| 14:42 |
kmlussier |
dbwells++ |
| 14:42 |
yboston |
I just wanted to say thanks for trying out a new approach, not that the older approaches were bad |
| 14:43 |
dbwells |
Thanks, all. So far so good, but the only real test will be the actual release :) |
| 14:43 |
gmcharlt |
thanks, again |
| 14:43 |
gmcharlt |
moving on |
| 14:43 |
gmcharlt |
#topic Grants and fundraising |
