| # | Time | Nick | Message |
|---|
| # | 01:16:01 | jeffdavis has joined #evergreen |
| # | 01:45:47 | elene has joined #evergreen |
| # | 01:47:01 | elene | hi everyone. my test installation of evergreen 2.1.1 has strange problem |
| # | 01:47:47 | elene | everything worked fine, but I just imported bunch of records from Staff Client Batch Import/Export |
| # | 01:48:02 | elene | the records included the holdings in 852 |
| # | 01:48:17 | elene | but now I can no longer search in OPAC |
| # | 01:48:43 | elene | the system starts searching, moves to the results page, but suddenly goes back to the initial homepage |
| # | 01:48:43 | elene | \ |
| # | 01:49:03 | elene | Also, autogen works fine, but at the end it complains: |
| # | 01:49:19 | elene | Refreshing proximity of org units |
| # | 01:49:19 | elene | Successfully updated the organization proximity |
| # | 01:49:19 | elene | Creating combined JS... |
| # | 01:49:36 | elene | "/openils/bin/autogen.sh: line 170: colrm: command not found" |
| # | 01:54:14 | elene | I restarted services but nothing seems to help |
| # | 01:54:38 | elene | Do I have to reboot after every batch import? |
| # | 03:01:09 | elene | I did a reboot but OPAC still goes back to home after every search keyword |
| # | 03:01:38 | elene | And autogen still shows openils/bin/autogen.sh: line 170: colrm: command not found" error |
| # | 03:29:53 | elene | I resolved this strange issue by installing bsdmainutils package in ubuntu |
| # | 03:31:03 | elene | Now autogen runs successfully and everything seems to work fine. I am wondering where my original colrm go, since I had not touched the system other than importing records from Staff Client :) |
| # | 07:45:36 | fortin has joined #evergreen |
| # | 07:54:41 | collum has quit IRC |
| # | 07:54:47 | hopkinsju has joined #evergreen |
| # | 07:58:36 | collum has joined #evergreen |
| # | 08:01:10 | finnx has quit IRC |
| # | 08:04:10 | kivilahtio has quit IRC |
| # | 08:05:25 | kivilaht1o has quit IRC |
| # | 08:06:21 | timhome has joined #evergreen |
| # | 08:11:39 | akilsdonk has joined #evergreen |
| # | 08:25:16 | sylvar_ is now known as sylvar |
| # | 08:26:27 | hopkinsju has quit IRC |
| # | 08:29:19 | _bott_ has quit IRC |
| # | 08:30:16 | _bott_ has joined #evergreen |
| # | 08:37:43 | Dyrcona has joined #evergreen |
| # | 08:47:30 | Shae has joined #evergreen |
| # | 08:52:15 | kmlussier has joined #evergreen |
| # | 09:04:05 | hopkinsju has joined #evergreen |
| # | 09:27:58 | jenny1 has joined #evergreen |
| # | 09:28:04 | tspindler has joined #evergreen |
| # | 09:37:55 | Dyrcona thinks the solution to bug 939535 was too easy. |
| # | 09:37:55 | pinesol_green | Launchpad bug 939535 in OpenSRF "Support Callback Data in javascript OpenSRF requests" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/939535 |
| # | 10:36:23 | bshum | berick++ # copy location search group sounds fascinating! |
| # | 10:38:06 | berick | masslnc++ |
| # | 10:39:32 | tsbere | mvlc_members-- # They can't agree to anything on copy locations |
| # | 10:40:07 | bshum | Is it teen or YA? (or both?) :) |
| # | 10:40:20 | Dyrcona | both. |
| # | 10:40:20 | tsbere | Oh, we solved *that* with "Young Adult/Teen" |
| # | 10:40:33 | bshum | Ha |
| # | 10:40:33 | tsbere | That was easy. |
| # | 10:40:45 | bshum | That didn't even make it to the table I think. |
| # | 10:40:53 | Dyrcona | After 30 years or so, you'd think they'd have this consortium thing down. |
| # | 10:41:04 | tsbere | Getting them to agree on half the other wording, or to come up with a process for creating/changing the things? That is hard. |
| # | 10:47:19 | tsbere | :( |
| # | 10:47:51 | tsbere can't get the data stash to work with the "minimal" modification methods, and apparently has to go with the re-write |
| # | 10:50:35 | tspindler | tsbere:drycona: we still hav issues with juv vs. childrens |
| # | 10:50:55 | tspindler | or j or jj or whatever |
| # | 10:51:55 | tsbere | tspindler: We went with human readable names. If we were going with abbreviations we would still be in trouble, though. <_< |
| # | 10:55:21 | Dyrcona | @love git |
| # | 10:55:21 | pinesol_green | Dyrcona: But Dyrcona already loves git! |
| # | 10:55:28 | tspindler | tsbere: some of our libraries seem to like human readable and some not, they want to fit it on a spinde label |
| # | 10:58:39 | tsbere | tspindler: When we first started populating them we had libraries wanting "Upstairs: blah" and "Downstairs: blah" variants. |
| # | 11:00:03 | tsbere | phasefx_: Git blame is blaming you for the partial implementation that later xulrunners don't like. Just so you know :P |
| # | 11:00:41 | elene has quit IRC |
| # | 11:00:51 | elene has joined #evergreen |
| # | 11:06:38 | akilsdonk has quit IRC |
| # | 11:08:34 | moodaepo | elene++ # Figuring things out when no one's around! |
| # | 11:49:57 | tspindler | anyone use the authority linker i ran authority_control_fields.pl but it never seemed to link any records |
| # | 11:55:10 | kmlussier | berick: Are there any new permissions for https://bugs.launchpad.net/evergreen/+bug/939570? |
| # | 11:55:10 | pinesol_green | Launchpad bug 939570 in Evergreen "Copy Location Search Groups" (affected: 1, heat: 6) [Undecided,New] |
| # | 11:56:35 | berick | kmlussier: yes. ADMIN_COPY_LOCATION_GROUP |
| # | 11:56:44 | kmlussier | ok thanks! |
| # | 11:58:20 | Dyrcona | kmlussier: do you need me to grant that to a specific account, or can you take care of it? |
| # | 11:58:39 | kmlussier | Dyrcona: I got it. |
| # | 11:59:08 | Dyrcona | k. thought you have the admin password. |
| # | 12:05:25 | denials | tspindler: I've run it, but not for a while. I wrote it in the 2.0 timeframe, it's possible that 2.1 / 2.2 introduced changes that broke it. |
| # | 12:07:08 | denials also notes that 2.2 still has the same limitation of only sorting by the 1xx $a subfield, which is a pretty limited form of alphabetization; should probably reply to self about that in the thread from a week or two ago |
| # | 12:09:37 | denials | mebbe we need to generate a column in are via authority.normalize_heading() instead of just using it as a constraint mechanism... |
| # | 12:11:12 | denials | then we could sort via that column, at least for the "Maintain authorities" UI. Not sure what to do about the right-click on a controlled field UI. maybe offer options... |
| # | 12:11:57 | denials | "Show matching primary entries" / "Show matching see from / see also / equivalency entries" or something like that |
| # | 12:16:48 | youdonotexist has joined #evergreen |
| # | 12:18:40 | luisb has joined #evergreen |
| # | 12:20:31 | tspindler | denials: yes, i tried it on 2.2 alpha so that may be the case |
| # | 12:22:11 | denials | tspindler: the thing to do may be to pull together a set of authority records that _should_ link to the bib entries in Open-ILS/tests/datasets/concerto.sql - then we could load those authority records, run authority_control_fields.pl, and find out what is happening (and fix it, and then we have a manual test case (at minimum) to run for the future) |
| # | 12:25:12 | akilsdonk has joined #evergreen |
| # | 12:28:42 | elene_ has joined #evergreen |
| # | 12:31:06 | elene has quit IRC |
| # | 12:31:06 | elene_ is now known as elene |
| # | 12:35:23 | elene_ has joined #evergreen |
| # | 12:37:26 | elene_ has quit IRC |
| # | 12:37:28 | elene has quit IRC |
| # | 12:39:06 | elene_ has joined #evergreen |
| # | 12:41:07 | bshum | Well, first speed bump for us testing our 2.1-2.2 process |
| # | 12:41:49 | bshum | I could start a thread somewhere I suppose |
| # | 12:56:14 | elene_ has quit IRC |
| # | 12:56:17 | elene has joined #evergreen |
| # | 12:58:29 | elene has quit IRC |
| # | 12:59:39 | elene has joined #evergreen |
| # | 13:01:04 | dbwells_ is now known as dbwells |
| # | 13:11:54 | elene has quit IRC |
| # | 13:13:12 | elene has joined #evergreen |
| # | 13:17:38 | elene has quit IRC |
| # | 13:23:02 | elene has joined #evergreen |
| # | 13:23:28 | tspindler | denials: I think the authority linking does work, i looked at your code and i didn't identify any record set or anything, i ran for the firs t100 records and seems to have done some linking at least on the couple of records i checked |
| # | 13:23:28 | elene has quit IRC |
| # | 13:25:33 | elene has joined #evergreen |
| # | 13:26:58 | tspindler | another questions related to permissions, what permission is required to view authority records, I just gave someone VIEW_AUTHORITY_RECORD_NOTES and they get permission denied when clicking on action in the authority browse (manage authorities) |
| # | 13:27:22 | tspindler | gave them every authority permission in fact |
| # | 13:27:55 | tsbere | tspindler: I assume the permission you just mentioned is for viewing authority notes, not authorities ;) |
| # | 13:28:55 | tsbere | tspindler: Otherwise, looks like *reading* authority information likely isn't protected. Creating looks like it requires the <whatever>_MARC permissions? |
| # | 13:29:15 | tspindler | tsbere: yes I assumed that also but I also gave them all the create, update, delete ietc. |
| # | 13:29:25 | tspindler | tspere: i'll double check that |
| # | 13:37:44 | elene has quit IRC |
| # | 13:39:21 | elene has joined #evergreen |
| # | 13:42:44 | bshum | Hmm, doesn't seem that call number prefix/suffix gets added to the label_sortkey properly |
| # | 13:42:58 | bshum | Which moves it to strange positions within a shelf browser |
| # | 13:45:05 | denials | bshum: which call number prefix / suffix? the one from copy location, or the other one? (also, I'm not 100% sure that prefixes are meant to be part of the sortkey...) |
| # | 13:45:32 | bshum | denials: That's what I was wondering too, but these appear to be prefix/suffix assigned from asset.call_number_prefix, etc. |
| # | 13:45:35 | bshum | Not the copy locations one |
| # | 13:45:46 | bshum | Which according to the 2.1 DIG doc says that those apply only to spine labels? |
| # | 13:46:40 | bshum | But yeah, these are the ones for the volumes and if the purpose is to reduce repetitious entry / making things uniform… breaking out a prefix like "REF" should probably be included in the label_sortkey |
| # | 13:46:43 | denials | bshum: pretty much |
| # | 13:47:00 | bshum | Or at least, I think it should in our case. |
| # | 13:47:22 | denials | bshum: hmm. but then you would be splitting up "REF QA 76" from "QA 76" |
| # | 13:47:46 | denials | and the idea of the call number browser is to support serendipitous discovery of items on the same subject, IMO |
| # | 13:47:56 | bshum | Hmm |
| # | 13:48:01 | denials | not so much to faithfully render a reproduction of the physical env |
| # | 13:48:01 | bshum | Interesting problem then. |
| # | 13:48:14 | denials | otherwise, you would want to split up by library as well |
| # | 13:48:44 | bshum | I get the feeling most people use it when scoped, but yeah I could see that being confusing if looking at system level or consortium |
| # | 13:49:05 | denials | precisely |
| # | 13:49:30 | bshum | I'll suggest that first scenario to my catalogers and see what they say, but I expect them to be unhappy that it's not a true representation of their physical map of items. |
| # | 13:49:33 | denials | tack "BR1" onto the start of the sortkey for all BR1-owned volumes, etc :) |
| # | 13:49:39 | bshum | -= THIS MESSAGE NOT LOGGED =- |
| # | 13:54:51 | elene has quit IRC |
| # | 13:54:58 | bshum | Surprise |
| # | 13:55:16 | bshum | denials++ # they like your reasoning and willing to let it slide. |
| # | 13:55:32 | bshum | Though we'll have to see what the libraries think in general. |
| # | 14:04:36 | tsbere | Working on XULRunner 10 compatibility for the staff client. So far? 17 files changed, 254 insertions(+), 1190 deletions(-) |
| # | 14:06:53 | Dyrcona | XulRunner 10 and then WebSocket, baby! |
| # | 14:07:29 | bshum | tsbere++ |
| # | 14:07:36 | denials | tsbere++ |
| # | 14:08:04 | denials looks at the calendar, thinks "ugh, Feb. 27 deadline for GSoC application is approaching crazy fast" |
| # | 14:08:08 | tsbere | Bad news: No Venkman or DOM Inspector for XULRunner 10 (I think they both stop at 8 right now) and Chrome List doesn't seem to exist for 4+ :( |
| # | 14:13:30 | bshum | Aha |
| # | 14:15:33 | jamesrf | tsbere++ |
| # | 14:16:35 | jamesrf | we were just talking yesterday about trying to use SPDY with the staff client so that would be a good step (SPDY is in FF11 apparently) |
| # | 14:50:43 | csharp | well, I've successfully recreated an error we've been seeing a lot of in the logs: http://paste.ubuntu.com/854448/ |
| # | 14:51:06 | csharp | it is generated when visiting this URL: http://gapines.org/opac/en-US/skin/default/xml/rresult.xml?tp=&t=&rt=isbn&adv=9780521897334&d=2&c=20 |
| # | 14:58:28 | csharp | Chromium's JS console reveals this URL to be the cause of the error, looks like: http://gapines.org/opac/extras/unapi?id=tag:evergreen-opac:biblio-record_entry/5526713[10]/PINES/2&format=holdings_xml-full&locale=en-US&dojo.preventCache=1330026959862 |
| # | 15:04:55 | denials | csharp: http://gapines.org/opac/extras/unapi?id=tag:evergreen-opac:biblio-record_entry/5526713[10]/PINES/2&format=marcxml&locale=en-US&dojo.preventCache=1330026959862 works. |
| # | 15:05:10 | denials | methinks jamesrf had a bug & patch for something like this |
| # | 15:05:24 | denials | (the -full / -uris variants not working, that is) |
| # | 15:14:16 | denials has quit IRC |
| # | 15:14:16 | denials has joined #evergreen |
| # | 15:27:44 | jamesrf | this looks like a different problem, if you remove the 2 after pines it seems to work |
| # | 15:29:23 | plgk has joined #evergreen |
| # | 15:33:20 | jamesrf | it's lp 898427 for reference |
| # | 15:33:20 | pinesol_green | Launchpad bug 898427 in Evergreen "holdings_xml-uris is broken as is holdings_xml-full" (affected: 1, heat: 6) [Undecided,Fix committed] https://launchpad.net/bugs/898427 |
| # | 15:33:53 | plgk | Can anyone tell me if there are osrf calls available for batch export/import. I checked the ../Application/Vandelay.pm. I didn't see anything at a glance. |
| # | 15:50:59 | jamesrf | csharp: it looks like what is happening is that SuperCat ends up calling select * FROM actor.org_unit_descendants(1,2); |
| # | 15:51:36 | jamesrf | so it depends in this case if we want when you add PINES/2 what should that be returning? should it return the same as PINES/0? |
| # | 15:56:02 | jamesrf | i guess it should just return the same |
| # | 15:56:52 | jamesrf | so either SuperCat.pm needs to not make that query if the depth > the selected ou's depth, |
| # | 15:56:59 | jamesrf | or actor.org_unit_descendants should return the same as the highest depth if it's higher than that depth |
| # | 15:58:38 | enhancin | Is there a way to change the what library shows up by default in the Holdings Maintenance area? |
| # | 16:05:51 | tspindler has quit IRC |
| # | 16:07:42 | akilsdonk has quit IRC |
| # | 16:11:30 | jenny1 has quit IRC |
| # | 16:13:28 | moodaepo thinks that Lynda on the mailing list with the online 'only' library might just be better off using Vufind/Blacklight but will not say anything 'yet' |
| # | 16:13:41 | enhancin | also...if i change something in actor.org_unit_setting a staff client reset should be good enough? |
| # | 16:14:45 | jamesrf | enhancin: yes although some of them you don't need to |
| # | 16:15:02 | enhancin | the format.date...but it didn't seem tofix it really |
| # | 16:15:22 | enhancin | it was set to mm-dd-yyyy and all my dates were yyyy-mm-dd..the months are showing up as 00 or 59 so I figured that was the issue |
| # | 16:16:30 | jamesrf | enhancin: are you using 2.0? |
| # | 16:16:36 | enhancin | 2.1 |
| # | 16:17:03 | jamesrf | hmm yeah sorry don't know :/ |
| # | 16:17:21 | enhancin | it's alright. just one of those weird things |
| # | 16:19:17 | enhancin | know how to change the default library for the Holdings Maintenance area though? |
| # | 16:19:23 | denials | enhancin: yyyy-MM-dd mebbe? |
| # | 16:19:30 | enhancin | ohh lemme try that |
| # | 16:19:43 | enhancin | oh man is mm minute?! |
| # | 16:19:52 | enhancin | that would be hilarious |
| # | 16:20:08 | denials looks at "man date", no, don't think so |
| # | 16:20:18 | denials | i'll check what we have |
| # | 16:20:34 | enhancin | hm M is minute for date |
| # | 16:20:49 | denials | also note that some of the date formats come from your workstation environment |
| # | 16:20:52 | enhancin | Evergreen wants MM |
| # | 16:21:16 | enhancin | it must use a perl date format or something? it fixed it |
| # | 16:21:19 | enhancin | now i see months |
| # | 16:21:34 | denials | 153 | 1 | format.date | "yyyy-MM-dd" |
| # | 16:22:01 | enhancin | yep. that's what I changed it to and now it works. silly. i'm not sure why it was that way. |
| # | 16:22:06 | enhancin | denials++ |
| # | 16:23:08 | denials | section 15.9.1.15 Date Time String Format |
| # | 16:23:31 | denials | of the ecmascript 262 edition 5.1 March 2011 specification |
| # | 16:23:35 | denials | (JavaScript) |
| # | 16:23:53 | enhancin | oh, duh, i knew the staff client did a lot of javascript i should have figured that |
| # | 16:23:57 | denials | http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf if you want a copy :) |
| # | 16:24:22 | enhancin | haven't done javascript in probably...6 years...jquery but not javascript |
| # | 16:27:04 | enhancin | but i will save this. looks handy. I keep a ton of pdfs like this around |
| # | 16:29:32 | collum has quit IRC |
| # | 16:42:36 | kmlussier has left #evergreen |
| # | 16:43:42 | Shae has quit IRC |
| # | 16:48:56 | luisb has quit IRC |
| # | 16:56:08 | tsbere is up to 20 files changed, 403 insertions(+), 1283 deletions(-) |
| # | 16:56:28 | tsbere | Which isn't really a milestone itself. The milestone is that I CAN LOG IN AND DO STUFF! :D |
| # | 16:58:08 | jeff | tsbere: what are you hacking on? |
| # | 16:58:20 | tsbere | jeff: XULRunner 10 |
| # | 16:58:26 | jeff | fun! |
| # | 16:58:34 | jeff | tsbere++ |
| # | 17:01:20 | tsbere | not 100% operational yet, though. <_< |
| # | 17:04:00 | berick chuckles at xulrunner 1.9.. wait, no, 3.6, wait, no 10! |
| # | 17:04:25 | berick | tsbere++ # that can't be fun |
| # | 17:05:14 | tsbere | Best part so far? All of my changes are compatible with 1.9/3.6 :D |
| # | 17:05:35 | berick | very nice |
| # | 17:05:38 | tsbere | Which means we should have 1.9 - 10.* and beyond support when I am done :D |
| # | 17:07:06 | phasefx_ | tsbere++ we're still keeping remote xul? |
| # | 17:07:36 | tsbere | phasefx_: I made it work. Without whitelisting. |
| # | 17:07:42 | phasefx_ | rock |
| # | 17:08:13 | tsbere | phasefx_: Though now all of those urls look like 'oils://remote/xul/stamp/server/....' instead of just /xul/stamp/server/.... |
| # | 17:08:37 | phasefx_ | cool deal |
| # | 17:09:07 | berick | tsbere: you're dying to work on dojo-1.7 compatibility, too, right? |
| # | 17:09:08 | berick ducks |
| # | 17:09:57 | tsbere | berick: I was just going to replace all the dojo config interfaces with non-dojo config interfaces and call it "compatible" ;) |
| # | 17:10:25 | berick | haha |
| # | 17:10:31 | denials | anyone disagree with "Overhaul aged infrastructure (Perl)" and "Overhaul aged infrastructure (JavaScript)" and "Overhaul aged infrastructure (Staff client)" as top GSoC priorities? :) |
| # | 17:10:55 | denials | at this rate I don't think we'll even have an application |
| # | 17:11:17 | phasefx_ | overhaul aged infrastructure (MARC) |
| # | 17:11:24 | denials | phasefx++ |
| # | 17:11:52 | tsbere | denials: I would be more likely to slap "Android interface" on there, just because. Staff or patron. |
| # | 17:11:57 | denials | tsbere: sure |
| # | 17:12:22 | denials | that was a wildly hoped-for result, and a heavily applied-for project |
| # | 17:12:56 | denials | -= THIS MESSAGE NOT LOGGED =- |
| # | 17:13:49 | denials | then again, /me leaves a lot to be desired |
| # | 17:14:47 | berick | tsbere: for android, you want to see a patron UI, basically a modile catalog? |
| # | 17:14:54 | berick | er, mobile |
| # | 17:15:37 | denials | -= THIS MESSAGE NOT LOGGED =- |
| # | 17:16:06 | denials | android on x86 for staff clients |
| # | 17:16:37 | berick | denials: right? just use tablets.. |
| # | 17:18:19 | Dyrcona considers doing a client for OpenMoko with mobile Qt, but that will disappear into the heap of "ten million other things that Dyrcona is doing." |
| # | 17:18:51 | denials | berick: tablets with USB connectivity for barcode scanners, and don't forget receipt printers and crap like that |
| # | 17:19:21 | enhancin | (hote to interrupt) is there a way to set the default branch in Holdings Maintenance? |
| # | 17:19:27 | Dyrcona | receipts are so last millennium 8) |
| # | 17:19:49 | tsbere | berick / denials: For "Staff Client" use I will be happy if I can get extension mode working with FF 4+. I have FF8 on my phone with extension support ;) |
| # | 17:20:06 | tsbere | enhancin: Log in somewhere else? |
| # | 17:20:44 | tsbere | enhancin: I think that interface also has a clue about saving the last used. |
| # | 17:21:34 | enhancin | hm. i've just had reports of wanting that defaulted because of people having to change it every time..does it go off of the workstation or off of the local cache on the computer(or both)? |
| # | 17:27:45 | denials | enhancin: is that great big dropdown menu right under the bold "Holdings Maintenance" sticky? |
| # | 17:28:13 | Dyrcona has quit IRC |
| # | 17:28:59 | denials tries it - yes, seems to be sticky here. |
| # | 17:29:26 | denials set it to something, quit the client, restarted, and it was still set to "something" as a default |
| # | 17:40:01 | enhancin | sweet. thanks |
| # | 18:10:20 | alynn26 has joined #evergreen |
| # | 18:15:12 | csharp | denials: jamesrf: thanks for the replies! had to run off just after sharing that - I'll investigate |
| # | 18:36:11 | finnx has joined #evergreen |
| # | 18:45:10 | hopkinsju has quit IRC |
| # | 18:56:22 | luisb has joined #evergreen |
| # | 19:00:12 | luisb has quit IRC |
| # | 19:15:11 | fortin has quit IRC |
| # | 19:20:59 | luisb has joined #evergreen |
| # | 19:22:39 | youdonotexist has quit IRC |
| # | 20:03:27 | youdonotexist has joined #evergreen |
| # | 20:25:17 | hopkinsju has joined #evergreen |
| # | 20:59:06 | cpl_ablair has joined #evergreen |
| # | 21:02:26 | cpl_abalir has joined #evergreen |
| # | 21:08:23 | cpl_abalir has quit IRC |
| # | 21:08:26 | cpl_ablair has quit IRC |
| # | 22:35:09 | luisb has quit IRC |
| # | 22:35:46 | finnx has quit IRC |
April 10-13