| # | Time | Nick | Message |
|---|
| # | 00:03:48 | mrpeters-isl has quit IRC |
| # | 02:12:46 | dbwells has quit IRC |
| # | 03:20:17 | dbwells has joined #evergreen |
| # | 03:31:05 | charltgm has joined #evergreen |
| # | 03:34:22 | charltgm__ has quit IRC |
| # | 04:31:29 | dbwells has quit IRC |
| # | 05:40:46 | dbwells has joined #evergreen |
| # | 06:41:19 | artunit has quit IRC |
| # | 07:21:11 | artunit has joined #evergreen |
| # | 07:21:49 | dbwells has quit IRC |
| # | 07:49:06 | artunit_ has joined #evergreen |
| # | 07:51:06 | artunit has quit IRC |
| # | 07:51:15 | artunit_ is now known as artunit |
| # | 07:57:43 | sfortin has joined #evergreen |
| # | 08:26:20 | kmlussier has joined #evergreen |
| # | 08:30:33 | dbwells has joined #evergreen |
| # | 08:41:27 | csharp | jeff: so you're having success with jasperreports & Evergreen? (looking at code4lib) |
| # | 08:59:07 | akilsdonk has joined #evergreen |
| # | 09:07:36 | jenny has joined #evergreen |
| # | 09:15:10 | dbs has joined #evergreen |
| # | 09:15:10 | dbs has joined #evergreen |
| # | 09:17:36 | dbwells has quit IRC |
| # | 09:22:25 | bshum | csharp: Good call about the pgxml.sql thing. Most people don't realize that they have to create the database for evergreen table along with all the contribs. I think there's a wiki page about this topic. |
| # | 09:23:00 | bshum | csharp: Ah, yes, here we go: http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-admin:maintenance:backups |
| # | 09:23:17 | bshum | The section entitled "backing up the Evergreen database" |
| # | 09:23:50 | bshum | moodaepo had rewritten that recently because it was hopelessly outdated, so it should be better now. |
| # | 09:24:02 | jeff | csharp: yes. i'll probably have a live demo up next week. |
| # | 09:24:43 | berick | dbs++ # pg replication post |
| # | 09:25:02 | jeff | csharp: as with many things, much of the challenge in this working for others will be making things more general purpose. our stat cat for patron home township probably has a different ID than yours, etc. |
| # | 09:27:59 | csharp | jeff: that's great, though - thanks for being willing to demo |
| # | 09:28:20 | csharp | I have downloaded jasperreports before, but didn't get very far with it |
| # | 09:28:35 | jeff | the report defs are xml, and will be in git. once loaded into the jasperserver web interface, they can be exported to a zip and then re-imported elsewhere. |
| # | 09:28:45 | csharp | very cool |
| # | 09:29:56 | jeff | also, we have 39 variations for Traverse City in our addresses. |
| # | 09:30:13 | jeff | mostly pre-dating evergreen, i'm guessing -- since zip code auto-fill reduces mistakes. |
| # | 09:30:20 | Dyrcona has joined #evergreen |
| # | 09:35:11 | bshum | Heh, csharp++ :) |
| # | 09:41:51 | phasefx | in the staff client, we add a CSS class 'no_copies' to record result rows in the OPAC for records with no copies, unless they're transcendant. I think we need to not do it for records with targeted URI's |
| # | 09:42:21 | phasefx | also, what is the use restriction thing for 856's? |
| # | 09:45:32 | dbs | phasefx: "use_restriction" is really a mislabelled "public note" |
| # | 09:45:41 | phasefx | hrmm, there's an 856 field for use restriction, that's probably a free text note, and there's... yeah |
| # | 09:46:09 | phasefx | and it gets used the same way on asset.uri? |
| # | 09:46:25 | phasefx | information just gets copied over |
| # | 09:46:30 | dbs | I should have recommended a fix to that way back when eeevil was first creating the asset.uri functionality but I just wanted the functionality |
| # | 09:47:39 | dbs thinks we should skip 2.1 and just go straight to 2.2, apropros of nothing |
| # | 09:48:18 | berick | heh |
| # | 09:50:01 | Dyrcona agrees with dbs since he's already running what will become 2.2. :p |
| # | 09:50:10 | dbs | George at the OpenLibrary is asking me about the openlibrary integration stuff, and I have to say "well, it was integrated into the core Evergreen on June 21, but that missed the 2.1 RC by a couple of days, so it won't be generally available until 2.2, which probably means 2012 sometime..." |
| # | 09:50:35 | berick | yeah... |
| # | 09:51:02 | berick is all for time-based releases now |
| # | 09:51:11 | berick | quarterly or tri-annual |
| # | 09:51:53 | Dyrcona | -= THIS MESSAGE NOT LOGGED =- |
| # | 09:54:52 | dbs | Dyrcona: yeah. when the focus is on not letting anything hit master until it has been QAed, that becomes a lot more possible |
| # | 09:55:13 | dbs | also, having you guys run into things that might not have been QAed enough also helps :) |
| # | 09:55:19 | Dyrcona | -= THIS MESSAGE NOT LOGGED =- |
| # | 09:55:21 | berick | indeed |
| # | 09:55:30 | csharp | fwiw from the sys admin perspective, I'm all for timed releases, but if they are any faster than every 6 months, we (the EG support community) might want to reconsider the EOL policy |
| # | 09:56:30 | Dyrcona | csharp: true. more often than every 6 months is definitely too fast for some folks out there. |
| # | 09:56:32 | dbs | I'm also really interested in getting a plan together for TT OPAC to actually get integrated into master. I'm not sure what steps need to be taken to make that happen |
| # | 09:56:53 | dbs | Dyrcona: well, every 6 months is fine, but we might need to go back to supporting 3 releases instead of just 2 |
| # | 09:56:56 | csharp | PINES can really only do 2 upgrades a year at the most, I think, and I would hate to feel like we're running an about-to-be-EOL'ed version all the time |
| # | 09:57:17 | Dyrcona | dbs: i've been meaning to look at tt opac and some of the working branches that affect it, if they haven't already been merged. |
| # | 09:57:35 | dbs | or for quarterly releases, support the last 6 releases? yeesh :) |
| # | 09:58:24 | senator | i have a strong desire to merge equinox work and conifer work on tt opac before any divergence gets any messier (so maybe next week?) |
| # | 09:58:28 | dbs | Dyrcona: my goals for TT OPAC are still fairly minimal: I just want to offer a better basic catalogue than we currently have, and I think we're pretty much there |
| # | 09:58:30 | berick | well, quarterly releases now are basically the difference between 1.6.1 and 1.6.2 from days of yore |
| # | 09:58:32 | senator | that does not constitute a plan but at least it's a step |
| # | 09:58:33 | csharp | Evergreen_LTS++ |
| # | 09:59:38 | Dyrcona | we're looking to grow the developer community, so support for more past releases may be possible from a community standpoint. |
| # | 10:01:20 | Dyrcona | all right, i have a patron's holds to mangle....be back in a few. |
| # | 10:02:44 | yboston has joined #evergreen |
| # | 10:04:42 | jeff | director has a login to our jasper reports server. no going back now! |
| # | 10:04:49 | csharp | heh |
| # | 10:06:38 | berick watches the bar charts and pie graphs fly |
| # | 10:13:10 | dbs assumes the director will log in once, and then send email to jeff asking jeff to set up specific reports for him/her |
| # | 10:16:53 | asimon has joined #evergreen |
| # | 10:18:53 | asimon | I have an issue with permission groups. The two org types at the bottom of our hierarchy are Building and Collection. Building can have users but Collection cannot. Each permission in a permission group |
| # | 10:19:39 | asimon | defaults to Collection, and I cannot change it. I have refreshed or org hierarchy, restarted Evergreen, restarted Apache, all to no avail. What am I missing? |
| # | 10:21:06 | asimon | FYI: I am logged in as admin when this behavior occurs. |
| # | 10:22:04 | bshum | Collection and Building are Org Unit types? |
| # | 10:22:19 | bshum | (that's unrelated to permission groups, two different concepts) |
| # | 10:22:28 | Dyrcona | asimon: I've seen something similar. When you have two different ou_types at the same depth, you can only choose one from the list. Not to worry, though, everything still works since its using the ou depth and not the the ou type. |
| # | 10:22:38 | asimon | bshum: That is correct. |
| # | 10:23:09 | asimon | Dyrcona: Building is the parent of Collection. |
| # | 10:23:12 | Dyrcona | We have System and Office at depth 1 and can only choose Office from the list, but permissions still work as expected because it uses depth. |
| # | 10:23:26 | Dyrcona | asimon: they have the same depth? |
| # | 10:23:45 | bshum | Sounds like a workstation login |
| # | 10:24:05 | bshum | Perhaps if they're registered at Collection, that's why they're "default" is that. |
| # | 10:24:24 | asimon | bshum: I have logged out and logged back in but the behavior persists. |
| # | 10:24:48 | asimon | bshum: I am trying to set permissions at the group level, not the user level. |
| # | 10:25:19 | jeff | dbs: intent here is still that we'll be creating report templates, but doing no running or post-processing of reports. also, we or the users can schedule/email/etc. so in theory, gaining much, and people can still use the evergreen reporter if they need/choose. |
| # | 10:25:28 | dbwells has joined #evergreen |
| # | 10:26:09 | Dyrcona | asimon: can you paste the content of your actor.org_unit_type table to lisp paste or somewhere? |
| # | 10:26:39 | asimon | Dyrcona: Coming right up. |
| # | 10:27:35 | bshum | Also, while you're at it, might be handy to see what permission.grp_tree says |
| # | 10:29:26 | bshum | General query: There was a question posted to the Evergreen Facebook page yesterday... |
| # | 10:29:41 | Dyrcona | Evergreen has a facebook page? |
| # | 10:29:43 | bshum | "Dear sir, I have some question about Evergreen ILS. Is it possible to use Evergreen ILS for the circulation of e-book or other electronics resources? (which the system can get the e-book back from patron when due date for this item)" |
| # | 10:29:54 | bshum | Dyrcona: Yes, there is one :) |
| # | 10:30:00 | Dyrcona doesn't have a facebook page. |
| # | 10:30:16 | Dyrcona doesn't trust the Zucker.... |
| # | 10:30:29 | bshum | I believe the answer to that is not yet. But of course, just verifying it. |
| # | 10:30:40 | asimon | Dyrcona: I see that four of my org types do have the same depth! Can I simply change the depths for the duplicates and restart Evergreen? |
| # | 10:31:20 | Dyrcona | asimon: depends. you can really mess up the org tree if you make changes willy nilly. |
| # | 10:31:41 | Dyrcona has been there, done that. |
| # | 10:32:22 | akilsdonk has quit IRC |
| # | 10:34:14 | asimon | Dyrcona: So have I. However, this is a test system. I think I'll try it, unless somene else can verify that this would break Evergreen. |
| # | 10:35:00 | bshum | For whatever it's worth, don't go too deep in depths. |
| # | 10:35:10 | Dyrcona | asimon: it could. just remember to run autogen.sh or cache-generator.sh afterward, and you'll need the -u option to recalculate proximity in the database. |
| # | 10:35:18 | akilsdonk has joined #evergreen |
| # | 10:35:22 | bshum | Freaks people out when you have five columns of depth in the OPAC search screen when you're at the bottom level. |
| # | 10:35:44 | Dyrcona | cache-generator.sh if you're testing master, autogen.sh otherwise. |
| # | 10:36:22 | asimon | bshum: Well, I would end up with seven depths (counting from 0, of course). |
| # | 10:38:36 | asimon | bshum: Consortium, Region, District, Group, Institution, Building, Collection. We are using VuFind for our public interface, so the Evergreen OPAC display is not important. |
| # | 10:38:47 | Dyrcona | asimon: anything with a depth lower than 0, most likely should have a parent 1 depth higher. |
| # | 10:39:16 | asimon | Dyrcona: That's what I thought as well. |
| # | 10:39:44 | kmlussier | bshum: Would be awesome if it could circ e-books! Glad you picked up on that question; I was going to answer it this morning, but then it slipped off my radar. |
| # | 10:39:45 | bshum | What are your copy locations like with an org type like that? (I would have thought Building/Collection would be more fitting under that category) |
| # | 10:40:43 | bshum | kmlussier: I don't think Evergreen has that capability (yet). At most, we could link to another system that did have it. Maybe hook into digital library stuff (like what Islandora proposed?) |
| # | 10:41:19 | bshum | kmlussier: I mean, you could play pretend with fake items associated with digital objects, but there's no mechanism that I know of. |
| # | 10:41:36 | asimon | bshum: We will convert our code-based copy locations to unique text following record load. |
| # | 10:42:25 | asimon | bshum: We want to be able to search by collection in VuFind. |
| # | 10:42:51 | kmlussier | bshum: as far as I know, there's nothing like that yet. Just linking into things like Overdrive. |
| # | 10:44:02 | kmlussier | bshum: But I think it's a great idea. It would be difficult to get content though unless there were a lot of DRM built in. |
| # | 10:44:18 | bshum | kmlussier: A whole other issue unto itself ;) |
| # | 10:46:17 | bshum | asimon: Hmm, just felt like a messy ou_type config to me. But whatever works conceptually for end users I suppose. |
| # | 10:46:23 | Dyrcona | Quick Q: The target of a Volume hold is the asset.call_number.id right? |
| # | 10:46:30 | bshum | asimon: What defines a collection usually? |
| # | 10:46:33 | Callender has quit IRC |
| # | 10:46:38 | bshum | Dyrcona: That sounds correct to me. |
| # | 10:46:52 | Dyrcona | i'll check the code. don't mind me. |
| # | 10:47:05 | Dyrcona | bshum: thanks just the same. |
| # | 10:47:10 | asimon | bshum: Adult, Juvenile, Young Adult, Bookmobile |
| # | 10:48:00 | Dyrcona | asimon: Adult, Juvienil, Young Adult, should maybe be copy locations. |
| # | 10:48:12 | Dyrcona | asimon: the default comes with a bookmoblie ou type. |
| # | 10:48:31 | Dyrcona wishes he could spel in IRC. :) |
| # | 10:49:16 | asimon | Dyrcona: There are many copy locations within each collection: e.g., Juvenile Reference, Juvenile Non-Fiction, Juvenile Fiction, Juvenile DVD, etc. |
| # | 10:50:57 | bshum | So the idea is being able to search all Juvenile copy locations at once using an org unit? |
| # | 10:53:00 | asimon | bshum: Yes. |
| # | 10:54:41 | bshum | asimon: I see. I just worry about managing something like what you've proposed so far. |
| # | 10:54:48 | moodaepo | asimon: Have you done an import of your Evergreen data into Vufind? (guessing yes) |
| # | 10:56:04 | asimon | bshum: We're coming from an Innovative Millennium system where we used this concept successfully. |
| # | 10:56:36 | asimon | modaepo: Yes. As I pointed out earlier, this is a test system. |
| # | 10:56:52 | moodaepo | I have been told that moving concepts from one ILS to another might not be the best thing to be doing : ) |
| # | 10:56:57 | Dyrcona | asimon: you might want to talk to tspindler, but he only shows up when there are meetings. |
| # | 10:57:36 | Dyrcona | asimon: i think his consortium is planning something similar and they come from Millennium. |
| # | 10:57:45 | moodaepo | So in our test Vufind instance the collections got put into the genre facet |
| # | 10:58:11 | moodaepo | I haven't tried but couldn't we just modify Vufind to allow searching on that facet? |
| # | 11:00:14 | asimon | moodaepo: I'll run this by our group. Thanks for your suggestion. |
| # | 11:00:15 | kmlussier | Dyrcona: no, I don't think tspindler is planning to use collections anymore. But NOBLE is. |
| # | 11:00:35 | Dyrcona | kmlussier: ah. thanks. |
| # | 11:00:49 | Dyrcona | don't see anyone from NOBLE around much either. |
| # | 11:01:46 | kmlussier | mmorgan from NOBLE comes in periodically. I think the main problem they've found with using collections in the hierarchy is that it forces items to go into transit when they are just moving from the collection to the library. |
| # | 11:02:02 | moodaepo | If you want to look at our test instance (which might be up/down/changes when observed) but it's probably what you have on your instance - http://egview.mnpals.net/vufind/ |
| # | 11:02:19 | moodaepo | kmlussier++ |
| # | 11:03:27 | bshum | kmlussier: Oh that sounds brutal. |
| # | 11:03:52 | asimon | After changing the org type depths, I am now able to successfully assign the Building Depth to Group Permissions. Thank all of you who responded for your help. |
| # | 11:03:55 | Dyrcona | bshum: guess it depends on your workflow. |
| # | 11:03:58 | bshum | So they'd need a workstation at every level? |
| # | 11:04:05 | bshum shudders |
| # | 11:04:41 | gmcharlt | jumping in late and haven't read all of the scrollback, but another possibility is having some of the common copy locations live higher in the OU hierarchy |
| # | 11:04:42 | bshum | Maybe floating collections would be helpful. Not that I know how those work yet. |
| # | 11:05:07 | gmcharlt | e.g., have consortial-level Adult and Juvenile collections |
| # | 11:09:33 | kmlussier | gmcharlt: In the case of some of our consortia, they were looking for a way to allow libraries to have shelving locations like picture books, children's DVD's, etc., but to also allow them to be searched as one group as "all children's materials." |
| # | 11:10:40 | kmlussier | gmcharlt: They were looking at adding the collections level of the hierarchy to do this, but then came across the in-transit problem. Another approach we were looking into was to find a way to group together several copy locations into one search scope. |
| # | 11:10:46 | phasefx | copy location lassos :) |
| # | 11:11:06 | bshum | phasefx: I was just thinking that might be cool... |
| # | 11:11:14 | kmlussier | phasefx++ That would be perfect! |
| # | 11:12:17 | phasefx | ++ whoever does it :) |
| # | 11:13:49 | kmlussier | phasefx: You weren't volunteering? ;-) |
| # | 11:13:56 | phasefx grins |
| # | 11:16:35 | asimon | kmussier: When do in-transit items move from the collection to the library? |
| # | 11:18:47 | asimon | kmlussier: Sorry about the typo. When do in-transit items move from the collection to the library? |
| # | 11:18:48 | phasefx | org lassos are my type of hackery though (negative id's changing the behavior) |
| # | 11:19:04 | kmlussier | asimon: You may want take a look at this thread http://georgialibraries.markmail.org/thread/6l3bf5yvr5myds3c |
| # | 11:19:31 | asimon | kmlussier: Thanks. I will. |
| # | 11:21:30 | youdonotexist has joined #evergreen |
| # | 11:22:42 | asimon | kmlussier: Our copies have the owning library and the circulating library set the same. This should fix the in-transit problem, no? |
| # | 11:23:27 | kmlussier | asimon: No, they were trying that particular setup because they found it would fix the in-transit issue. |
| # | 11:24:17 | kmlussier | asimon: If the copy is owned by the collection, but the collection does not have users, then it cannot be a pickup location. |
| # | 11:24:31 | bshum | Working on that strange my account problem from awhile back for one of our patrons. This was a screenshot they forwarded to me: http://ur1.ca/4tbti |
| # | 11:24:34 | bshum | That's firebug at the bottom right? |
| # | 11:25:12 | gmcharlt | kmlussier: just to be clear, a copy location as such couldn't be a pickup location anyway |
| # | 11:25:20 | kmlussier | asimon: When the patron places a hold on the the copy, they need to designate the building as a pickup location. So when the workstation scans in the copy, it sends it into transit to the building. |
| # | 11:25:24 | gmcharlt | since pickup locations are coming from the list of org units, not copy locations |
| # | 11:25:43 | csharp | bshum: yep |
| # | 11:26:19 | kmlussier | gmcharlt: No, it couldn't, But because the collection is part of the hierarchy, the system wants to send it into transit when it is scanned in. |
| # | 11:26:23 | csharp | bshum: have you ruled out autogen.sh as a cause? (meaning that a cache clear will likely solve it) |
| # | 11:27:00 | bshum | csharp: Now see, the patron claims they don't run a cache (due to their work in website design), and I did ask them to perform a hard refresh. |
| # | 11:27:08 | bshum | csharp: That was my first guess too. |
| # | 11:28:17 | csharp | hmm |
| # | 11:28:18 | bshum | kmlussier: That's been loads of fun for some of our branch libraries that were used to sharing items equally between them. We've been exploring whether floating collections would help them or not. |
| # | 11:28:49 | bshum | But then we weren't sure whether floating would mean the item could become lost somewhere else in the consortium. |
| # | 11:28:50 | csharp always doubts patrons' self-assessment of technical knowledge, even when they seem to have some ;-) |
| # | 11:29:07 | bshum | csharp: Well, he sent me the about.xul file from Firefox when I asked him for details about his plugins. |
| # | 11:29:12 | bshum | csharp: So... yes. |
| # | 11:30:03 | bshum | Thus far, I haven't been able to replicate the problem. |
| # | 11:30:14 | bshum | It's... strange. |
| # | 11:30:15 | kmlussier | bshum: How would floating collections help with that? I don't really know much about floating collections at the moment. |
| # | 11:30:54 | bshum | kmlussier: From my understanding, a copy marked as floating would not be sent back to home after it was done for reshelving, but instead stay wherever it's checked in. |
| # | 11:31:02 | Dyrcona doubts anyone's self-assessment of knowledge on any matter, even his own. |
| # | 11:31:22 | csharp | it's gotta be something in his browser - if he's got a web development setup that is atypical, that may be the issue |
| # | 11:31:52 | bshum | csharp: Pretty much where I'm at. I asked him to verify that he's tried using it with no plugins enabled. Or using a completely different browser. |
| # | 11:31:58 | dbs | bshum: can't remember if I asked, but if dude(tte) has firebug, have they disabled cookies or something like that? |
| # | 11:31:58 | csharp | Dyrcona: hear, hear! |
| # | 11:32:14 | bshum | dbs: I don't think you asked me that. But I can ask the patron. |
| # | 11:32:29 | bshum | dbs: Losing cookies would seem bad now that you mention it. |
| # | 11:32:46 | Dyrcona | bshum: noscript is a biggie too. they need to allow scripts for the catalog to work at all. |
| # | 11:32:50 | asimon | kmlussier: The owning library and circulating library are the building, not the collection. |
| # | 11:33:13 | bshum | Dyrcona: As far as I know, this was the only screen they weren''t able to access. The other parts of my account worked fine for them. (seeing fines, etc.) |
| # | 11:33:28 | Dyrcona | ok. just saying for the sake of the logs. :) |
| # | 11:33:32 | bshum | Dyrcona: They are just unable to render anything that they have checked out. |
| # | 11:33:38 | bshum | Right, logs :) |
| # | 11:34:19 | csharp | I'm pretty sure fmall.js is created by autogen.sh, in case that isn't obvious ;-) |
| # | 11:34:40 | asimon | kmlussier: and users are assigned to the building, not to the collection. |
| # | 11:35:24 | dbs | oy, with all those toolbars and weather plugins and things |
| # | 11:35:31 | dbs finally looks at the screenshot |
| # | 11:35:38 | dbs | you know |
| # | 11:35:40 | dbs | 66 items |
| # | 11:35:45 | csharp | heh |
| # | 11:35:45 | dbs | I bet it's just timing out |
| # | 11:35:58 | bshum | It is a long list. |
| # | 11:36:35 | csharp | PINES limits patrons to 50 checkouts - in case that contributed to design paramters |
| # | 11:36:56 | bshum | I was able to view the entire list when checking it. But I'm a bit closer to our servers. |
| # | 11:37:28 | dbs | yeah. latency could be screwing him over |
| # | 11:37:29 | bshum | I think we tried once here with someone who had over 100 items checked out to them and it seemed fine. But maybe not in the field. |
| # | 11:37:32 | kmlussier | asimon: In your set up, the owning and circulating library are the building? Then it probably would avoid the in-transit issue. |
| # | 11:37:53 | Dyrcona | bshum: tell the patron to try it in Safari. :p |
| # | 11:38:11 | bshum | Dyrcona: On his dinky powerbook? |
| # | 11:38:14 | bshum | ;) |
| # | 11:38:25 | bshum | I did suggest that actually. |
| # | 11:38:51 | Dyrcona | bshum: he's not faithful if he's gotten a new Mac in at least 3 years, and uses anything but Apple software on it. |
| # | 11:39:00 | Dyrcona | j/k |
| # | 11:39:19 | bshum | I still can't wrap my head around Safari use. |
| # | 11:39:22 | Dyrcona | that if should be unless. |
| # | 11:39:31 | bshum | Personally that is. |
| # | 11:39:36 | Dyrcona | I use Safari on my Mac Book. |
| # | 11:39:50 | Dyrcona | Firefox on Ubuntu. |
| # | 11:39:51 | bshum | Have you seen my strange bookbag bug about Safari? |
| # | 11:40:06 | bshum | (unrelated to everything else) |
| # | 11:40:15 | Dyrcona | bshum: no. but I haven't encountered any problems with the catalog on safari, yet. |
| # | 11:40:42 | bshum | Oh and thanks dbs, csharp, Dyrcona, and others for trying to help me think through this OPAC quirk for the patron. |
| # | 11:44:10 | Dyrcona | actually looks like he retrieved fmall.js ok, but something else blew up. |
| # | 11:52:01 | charltgm has quit IRC |
| # | 11:52:30 | charltgm has joined #evergreen |
| # | 12:03:28 | dbwells | asimon: Unless you have a circ station for every org unit which "can have volumes", you will deal with bogus transits. For instance if both "Children's" and "Children's DVDs" are org units, and your circ desk is registered as "Children's" all checkins of DVDs at that desk will try to transit to "Children's DVDs". As far as I know (and as noted in the thread posted), there is no simple... |
| # | 12:03:29 | dbwells | ...solution to that. |
| # | 12:11:55 | Callender has joined #evergreen |
| # | 12:13:34 | dbwells | berick: (or anyone else) I have a question about how Vandelay is supposed to work in 2.0. If I check one of the "Merge" boxes but leave "Auto-Import" unchecked when doing a file upload, the records which do not merge go ahead and import themselves as new records anyway. This seems unexpected to me. I have code which changes that behavior in testing on our system, but wanted to understand... |
| # | 12:13:36 | dbwells | ...the intentions before I go ahead with making a bug of it. |
| # | 12:15:41 | berick | dbwells: yes, that's a bug. it's fixed in master, as a result of the latest vandelay work, but still needs repairing in 2.0 |
| # | 12:15:53 | berick | so, ++ to fixing |
| # | 12:30:45 | jenny has left #evergreen |
| # | 12:32:34 | dbwells has quit IRC |
| # | 12:33:38 | dbwells has joined #evergreen |
| # | 12:38:51 | dbwells | berick: Right. So obviously Vandelay just underwent fairly sweeping changes which I have only tiptoed into at this point. Is something which, in your opinion I should try to look into to ensure we are using the "same" fix, or are these essential diverging at this point? I will definitely look at the new code in any case, but would like to know your opinion in case I get overwhelmed. |
| # | 12:40:40 | dbwells runs to lunch, will check back later |
| # | 12:43:37 | berick | dbwells: in the newer code, a new record can only be created if the option is selected and the record has /no/ matches in the DB. the new code is much more flexible about controlling how matches are configured, though |
| # | 12:43:51 | berick | doing the exact same thing in 2.0 might be too strict |
| # | 12:43:56 | berick | but I think you could get close |
| # | 12:44:59 | berick | dbwells: reviewing import_record_list_impl() in master should give you a good sense of the possible outcomes |
| # | 12:45:45 | berick | there are basically 5 possible outcome branches in the code |
| # | 12:49:05 | berick | biaf |
| # | 12:54:18 | charltgm_ has joined #evergreen |
| # | 12:56:35 | charltgm has quit IRC |
| # | 13:33:04 | bshum | Heh, sysadminday.com -- Happy System Administrator Appreciation Day to you all :) |
| # | 13:38:59 | kmlussier | bshum: 2 reasons for you to celebrate today! :-) |
| # | 13:39:24 | bshum | kmlussier: It's an amusing coincidence, of course. |
| # | 13:39:55 | kmlussier | bshum: Biblio could show their appreciation by giving you your birthday off! |
| # | 13:41:11 | dbwells | berick: Took a look, and the changes in master as far as this bug is concerned were easy to follow. The only significant difference between master and my test code is that 'vlUploadQueueAutoImport' in rel_2_0 seems to now be called 'vlUploadQueueImportNoMatch' in master. I think it seem sensible for the sake of both clarity and future bug backports to rename this variable in rel_2_0 as... |
| # | 13:41:13 | dbwells | ...well, so I'll make that change in my branch and get it pushed for review this afternoon. Thanks. |
| # | 13:41:14 | bshum | Hmm, for standing penalty/messages, there appears to be a dropdown selector in the upper right hand corner of the screen. Ours doesn't seem to have anything in it. Bug? |
| # | 13:41:32 | bshum | When applying new ones that is. |
| # | 13:41:39 | phasefx | you have some defined? |
| # | 13:41:57 | berick | dbwells++ |
| # | 13:42:01 | berick | sounds good |
| # | 13:42:07 | phasefx | bshum: Admin->Local->Standing Penalties? |
| # | 13:42:27 | bshum | phasefx: Looks like we have mostly defaults in there. |
| # | 13:42:53 | phasefx | should be none by default, that interface (and that drop-down) are for custom penalties |
| # | 13:43:02 | phasefx | that admin interface, that is |
| # | 13:43:11 | bshum | Oh, maybe they're legacy from before we were on 2.0 |
| # | 13:43:29 | bshum | I have 14 entries in that table, config.standing_penalty |
| # | 13:43:33 | phasefx | what sort of things are you seeing in there? |
| # | 13:43:38 | bshum | Let's see |
| # | 13:43:39 | phasefx | oh |
| # | 13:43:46 | bshum | PATRON_EXCEEDS_FINES, etc. |
| # | 13:43:52 | bshum | STAFF_C, STAFF_CH |
| # | 13:43:56 | phasefx | anything with an id over 100? |
| # | 13:44:00 | bshum | No. |
| # | 13:44:07 | bshum | That must be the reason then |
| # | 13:44:09 | phasefx | yeah, that's what you need, custom penalties |
| # | 13:44:16 | bshum | Interesting. |
| # | 13:44:19 | phasefx | if you want something to show up in that drop-down |
| # | 13:44:29 | phasefx | if you don't need the penalties, you don't need them :) |
| # | 13:44:36 | bshum | Well, that's a very cool option actually. |
| # | 13:44:43 | phasefx | custom block reasons, etc. |
| # | 13:44:45 | bshum | Someone was asking us about how to setup a hold block only. |
| # | 13:44:47 | phasefx | good for reporting |
| # | 13:44:49 | bshum | Guess that would be a custom block |
| # | 13:44:57 | bshum | *could be |
| # | 13:45:13 | phasefx | yeap |
| # | 13:45:33 | bshum | What are the sub-100's used for then? System-related I'm assuming |
| # | 13:46:32 | phasefx | some of them are system generated.. the STAFF_C, etc. do get used by that Apply Penalty dialog, but based on the other widgets int here |
| # | 13:52:27 | bshum | Neat. Thanks phasefx. Guess we'll experiment a little. |
| # | 13:53:54 | asimon | dbwells: If a copy's circulating library and owning library are the same as a terminal's registered org unit, the item will not go in transit when checked in, correct? |
| # | 13:54:38 | gdunbar has quit IRC |
| # | 13:55:21 | phasefx | what's div/css/dojo equivalent of a xul hbox? |
| # | 13:56:38 | phasefx has <div> <button/> <div/> </div> and he just wants the two inner elements to line up side-by-side rather one above the other |
| # | 13:58:29 | berick | phasefx: does the second <div/> have to be a div? could it be a span and/or its contents shoved into a span w/ the <button/> |
| # | 13:58:41 | phasefx tries a span |
| # | 13:58:55 | dbs | span instead of div |
| # | 13:59:05 | phasefx | kind of thought span's always had to be inside a div or some other container |
| # | 13:59:23 | phasefx | but, I guess I could do <div> <span> e1 e2 </span> </div> eh? |
| # | 13:59:26 | dbs | <div> <button /> <span /> </div> |
| # | 13:59:39 | phasefx | oh, yeah, I tried that one already |
| # | 14:00:11 | phasefx | that e2 happens to be a dijit; probably important |
| # | 14:02:13 | phasefx | sadly, I can't even get openils.Util.show/hide to affect it <scratches head> |
| # | 14:02:43 | dbwells | asimon: That is correct, though only the circulating library matters as far as transits are concerned, if I am thinking clearly. |
| # | 14:03:20 | berick | phasefx: e2 will get turned into a div by dojo, then, most likel |
| # | 14:03:21 | berick | y |
| # | 14:03:41 | berick | you could put a div inside a span, and make the div the dijit dom node |
| # | 14:03:52 | dbs | might need to pull in a layoutcontainer / contentpane |
| # | 14:03:59 | berick | <span><div id='my-diji-id'/></span> |
| # | 14:04:02 | berick | yeah, perhaps |
| # | 14:04:20 | dbs | well, strictly speaking spans aren't allowed to contain block-level elements. bwahahaha |
| # | 14:04:22 | phasefx was wrong about show/hide at least |
| # | 14:06:25 | phasefx plays with layoutcontainer |
| # | 14:10:59 | RBecker has quit IRC |
| # | 14:12:01 | phasefx | weird, my dojo.require can't find dijit.layout.ContentPane |
| # | 14:14:38 | dbs hums a blues progression... "I got me the Dojo blueeeees" |
| # | 14:15:03 | phasefx | working now.. only thing I really changed was double-quotes to single quotes.. inline javascript |
| # | 14:15:46 | dbs | hah |
| # | 14:16:08 | dbs | @blame XMLENT |
| # | 14:16:08 | pinesol_green | dbs: Error: "blame" is not a valid command. |
| # | 14:16:17 | RBecker has joined #evergreen |
| # | 14:16:27 | phasefx | really? eww |
| # | 14:18:32 | phasefx | http://paste.lisp.org/display/123652 |
| # | 14:19:19 | phasefx | using layoutcontainer/contentpane, with layoutAlign=left and layoutAlign=right.. still showing one above the other :( |
| # | 14:24:15 | RBecker has quit IRC |
| # | 14:32:23 | RBecker has joined #evergreen |
| # | 14:41:56 | phasefx is missing CSS and a dojo theme, that's his main problem |
| # | 14:42:03 | dbs | heh |
| # | 14:42:11 | artunit has quit IRC |
| # | 14:42:24 | dbwells has quit IRC |
| # | 14:45:07 | dbwells has joined #evergreen |
| # | 14:45:41 | jenny has joined #evergreen |
| # | 14:48:40 | artunit has joined #evergreen |
| # | 15:16:03 | bshum | Hmm, just to verify some thinking (trying to undo something bad that just happened to our bibs) |
| # | 15:16:29 | dbs blames an old version of MARC::Record / MARC::Charset / MARC::File::XML |
| # | 15:16:33 | bshum | The index biblio_record_unique_tcn is checking for unique values only on biblio.record_entry lines that are not deleted |
| # | 15:16:39 | bshum | "WHERE deleted = false OR deleted IS FALSE;" |
| # | 15:16:52 | tsbere | That seems rather redundant |
| # | 15:17:01 | dbs | it was required for PostgreSQL 8.4, at least |
| # | 15:17:14 | bshum | So that means that it is possible to have multiple tcn_value entries that are the same for various bibs as long as they aren't marked deleted = false |
| # | 15:17:16 | tsbere | "WHERE NOT deleted" didn't work? |
| # | 15:17:17 | dbs | = false != IS FALSE |
| # | 15:17:24 | dbs | -= THIS MESSAGE NOT LOGGED =- |
| # | 15:17:46 | dbs | yeah, there's an old thread about it, james fournie tracked down the problem, lead to horrible plans without that equivalence |
| # | 15:17:59 | dbs | bshum: no |
| # | 15:18:16 | dbs | that sounds totally backwards |
| # | 15:18:47 | dbs | huh |
| # | 15:18:49 | bshum | dbs: That's what I was thinking, but I've not inspected these tables too closely yet. |
| # | 15:19:12 | bshum | What happened is cataloging asked me to mark a range of bibs as deleted for them, claiming that they were dead records that we didn't need |
| # | 15:19:20 | bshum | But what they really wanted to do was to re-import them again |
| # | 15:19:52 | bshum | So now I'm inspecting what they tried to import and what I was asked to delete |
| # | 15:19:58 | bshum | And the tcn_values are a match |
| # | 15:20:12 | bshum | Which is why I can't seem to resurrect the mistakenly deleted bibs |
| # | 15:20:50 | bshum | Since the unique test is against non-deleted bibs, not all bibs. |
| # | 15:21:06 | dbs | bshum: so the backwards bit is |
| # | 15:21:21 | dbs | "it is possible to have multiple tcn_value entries that are the same for various bibs as long as they __are__ marked deleted = false" |
| # | 15:21:31 | dbs | (you said "aren't") |
| # | 15:21:51 | dbs | Yes, I agree with your final statement |
| # | 15:22:01 | bshum | Sorry, yes, that is correct. |
| # | 15:22:06 | bshum | Okay. |
| # | 15:22:22 | bshum | Thanks dbs, I did write the wrong thing earlier |
| # | 15:22:26 | dbs | Specifically, you can have tcn_value = 1 for exactly 1 non-deleted bib, and tcn_value = 1 for as many deleted bibs as you can fit into a single row |
| # | 15:22:32 | dbs | bshum: you made me think :) |
| # | 15:22:59 | bshum | So their plan should have worked fine. |
| # | 15:23:11 | bshum | Just creating lots of extra entries |
| # | 15:23:38 | dbs | yeah, sounds like they want an overlay? |
| # | 15:23:40 | tsbere | seems like the wrong way for them to do it |
| # | 15:23:43 | bshum | Alright, guess cataloging and me will need to stick our heads together... |
| # | 15:23:59 | bshum | I don't know they didn't overlay. |
| # | 15:24:05 | bshum | They seem to distrust it. |
| # | 15:24:18 | bshum | I'll advise them to pursue that in the future. |
| # | 15:25:02 | bshum | tsbere: It definitely seemed wrong to me after I got the full story. |
| # | 15:25:38 | dbs | It's quite possible overlay is broken, but in that case the fix is to fix overlay :) |
| # | 15:27:14 | sfortin has quit IRC |
| # | 15:27:35 | bshum | dbs: I think it may also be the approach to overlay |
| # | 15:27:51 | bshum | During the conference, I asked others about it, and they had mixed feelings about 2.0 vandelay and it's ability to overlay properly. |
| # | 15:28:29 | bshum | I think it's an issue between what our catalogers wish it was doing, vs. what it can actually do. |
| # | 15:28:52 | kmlussier | bshum: Upgrade to master. :-) |
| # | 15:28:52 | bshum | But I'll try to gather some more specific details. |
| # | 15:29:16 | bshum | kmlussier: ... master. Did anyone ever fix the i18n problems that moodaepo pointed out I wonder? |
| # | 15:32:58 | moodaepo | kmlussier: bshum: No fix I just pulled rel_2_1 since you'd found the problem was just with master |
| # | 15:35:14 | moodaepo | Since Dyrcona runs master wonder if he has encountered the errors "make install_all_locales" - http://paste.lisp.org/display/123370 |
| # | 15:35:50 | Dyrcona doesn't install translations. |
| # | 15:35:54 | bshum | Maybe they only speak en-US in MA :) |
| # | 15:36:47 | Dyrcona | "We" speak other languages, but the catalog only does en-US. |
| # | 15:42:52 | bshum | That works I guess. |
| # | 15:49:08 | asimon has quit IRC |
| # | 15:50:47 | dbs wonders if those errors moodaepo encountered were reported in a bug |
| # | 15:51:18 | moodaepo | dbs: bshum and I were just talking about filing one since I hadn't previously |
| # | 15:51:38 | dbs | also - someone (ahem) should add "make install_all_locales" part of the build steps so that testing.evergreen-ils.org can keep an eye on things like that broken SQL file |
| # | 15:52:15 | moodaepo has a meeting now and will file it if bshum get's his catalogers all fixed and beats me to it as usual. |
| # | 15:52:46 | bshum | moodaepo: I'll let you file it. |
| # | 15:53:37 | dbs bets the problem is oils_i18n_gettext('b',$$LC subject headings for children's literature$$,'at','name') |
| # | 15:53:51 | bshum | dbs: It is. |
| # | 15:54:00 | bshum | dbs: Removing that line takes care of half of the problem. |
| # | 15:54:06 | bshum | The other half is some line in authority.js |
| # | 15:54:21 | dbs | in that $$ isn't recognized as a string delimiter by the script (because we're talking python, not SQL, for i18n) |
| # | 15:55:19 | moodaepo | bshum++ # also have a good weekend birthday |
| # | 15:55:28 | moodaepo runs off to the meeting for reals |
| # | 15:56:52 | dbs wonders if the line in authority.js is "AUTHORITY_FIELD_METADATA": "${3} (${1} ‡${2}) ${4}" (JSON not liking the double-dagger; \u2021 might work) or the other line with the escaped double-quotes |
| # | 15:57:19 | dbs | ah, it's the double-dagger |
| # | 16:00:08 | dbs pokes around |
| # | 16:14:46 | jeff | anyone using Envisionware PC Reservation with Date of Birth based age restrictions? |
| # | 16:15:00 | jeff | "area X is only for ages X to Y", etc? |
| # | 16:15:49 | jeff | (what does this look like jeff, #envisionware-support?) |
| # | 16:17:29 | dbs | for moodaepo / bshum: user/dbs/fix-i18n-build in working repo should handle the problems |
| # | 16:17:48 | dbs | specifically, commit 8f47b79befdd1d7c92406ec24ef1c8b06f2bc1b2 |
| # | 16:19:57 | collum has quit IRC |
| # | 16:26:40 | jeff | alas, i don't think we have a "what products/services are you using with evergreen" |
| # | 16:35:40 | bshum | jeff: We're using that program for two of our libraries, but I don't think they're using those fields. |
| # | 16:59:31 | akilsdonk has quit IRC |
| # | 17:13:47 | csharp | we need moar PINES local system admins in this channel - they could help jeff with his PC Res issue... |
| # | 17:16:49 | dbs | jeff: there was a wiki page with the results of the hardware/software survey from a couple of years ago |
| # | 17:17:21 | dbs | http://open-ils.org/dokuwiki/doku.php?id=faqs:evergreen_compatible_products_results_survey |
| # | 17:28:13 | Dyrcona has quit IRC |
| # | 17:31:51 | yboston has quit IRC |
| # | 17:42:07 | edoceo has quit IRC |
| # | 17:47:06 | JMCraig has joined #evergreen |
| # | 17:49:07 | dbwells has quit IRC |
| # | 17:49:15 | dbwells_ has joined #evergreen |
| # | 17:49:17 | dbwells_ is now known as dbwells |
| # | 17:50:11 | agJohn has quit IRC |
| # | 17:50:17 | JMCraig is now known as agJohn |
| # | 17:53:13 | kmlussier has quit IRC |
| # | 17:56:34 | dbs has quit IRC |
| # | 18:05:32 | jenny has left #evergreen |
| # | 18:35:35 | edoceo has joined #evergreen |
| # | 19:19:44 | dbwells has quit IRC |
| # | 19:30:30 | charltgm__ has joined #evergreen |
| # | 19:33:01 | youdonotexist has quit IRC |
| # | 19:33:40 | charltgm_ has quit IRC |
| # | 20:28:56 | dbwells has joined #evergreen |
| # | 20:55:51 | dbwells has quit IRC |
| # | 22:05:22 | dbwells has joined #evergreen |
| # | 22:10:14 | dbwells has quit IRC |
| # | 22:14:28 | edoceo has quit IRC |
| # | 22:17:05 | edoceo has joined #evergreen |
| # | 23:19:11 | dbwells has joined #evergreen |
| # | 23:38:13 | jeff | csharp: yeah, drag those admins in here! ;-) |
| # | 23:39:01 | jeff | csharp: we'll see what envisionware says. evergreen seems to be returning the dob as expected, age-based validation rules just don't seem to be taking effect in our initial testing. |
April 10-13