From m.e.phillips at durham.ac.uk Thu Jan 3 16:07:43 2013 From: m.e.phillips at durham.ac.uk (PHILLIPS M.E.) Date: Thu, 3 Jan 2013 16:07:43 +0000 Subject: [Umlaut-general] Making changes to library holdings display Message-ID: Hello, We're still working away on Umlaut when we get the chance, and liking it more and more. I submitted a very minor pull request on GitHub just now: I hope I've gone about it the right way. I'd just like a quick pointer in the right direction. We have written a service adaptor for our Millennium ILS so that we can display holdings information about print copies in Umlaut. For example, see http://bit.ly/S6OLW4 for a book with lots of copies. At present the service adaptor basically creates a new service response for every item which it finds attached to the bib records retrieved by the OPAC search, just like the Horizon adaptor which Jonathan wrote. The app/views/resolve/_holding.html.erb file is still the same as the standard Umlaut one, written for Jonathan's requirements, except I have made some small tweaks just to prove I know how to edit it. What I would like to do is a rather more drastic change, so that we can present a rather more compact display to the user. I would like to be able to show a row in the table for each library which holds copies, and on that row give the classmark (assuming all copies in that library have the same classmark) and then instead of the text "Available" I would like to be able to say things like 6 copies available, 2 on loan 1 copy available 3 copies on loan (first due 23-01-2013) I am confident enough about programming in Ruby to generate these strings, and I can see it would be quite easy to implement this in my millennium.rb service adaptor, by replacing the text returned in the :status key, but there may be better ways to do this. Going beyond that initial aim, I am thinking that for vaguer matches, where the adaptor might retrieve several bib records, I would like the results grouped by bib record, rather than being a long list of items. For example, see http://bit.ly/VkXPmS where an OpenURL has matched multiple editions of a book. I would like to try displaying it in this sort of way: 3rd ed., 2000 -- Bill Bryson Library 005.133PER WAL 1 copy available -- St. Mary's College Library 005.133WAL 1 copy available 2nd ed., 1996 -- Bill Bryson Library 005.133PER WAL 4 copies available -- St. Aidan's College Library 510.78 WAL 1 copy available To do this I think I would need to make the service response from millennium.rb return a single response per bib record, with keys such as the current :edition_str :match_reliability :url A new element of the response would be an array of libraries or locations, each of which would have keys such as the current :collection_str :status :call_number (we do not have any easy way of creating a request link, sadly, as our OPAC is not amenable to this). What I would like to ask is, should I just rewrite my millennium.rb file to generate a different structure in the service response, of type "holding", and put a new _holding.html.erb in place to render it, or should I invent a new service response type (such as holding_summary?) to avoid clashing with data structures invented by Jonathan for his Horizon-based holding response type. I am just wondering which would be more maintainable longer term. Would we meet any problems if we meddled with the "standard" holding response type structures? I don't suppose other service adaptors take the call number and locations and do more things with them? Or do they? I suppose you could envisage having the relevant locations pinpointed on a map by another service adaptor, in which case it would need to know how to identify the locations. Or today's opening hours of the relevant locations being available in a side panel. I'd be grateful for any guidance or words of wisdom on this sort of thing, so we can avoid doing things the wrong way. Oh, and I am guessing that sort of amalgamating these items into bibs is best done before the structures get rendered by the _holding.html.erb file. I don't know much about the .erb syntax yet, but the examples I have looked at have basic logic and looping, but nothing complicated like seeing whether this edition is the same as the previous one and if not starting a new section for a new bib.... Thanks, Matthew -- Matthew Phillips Electronic Systems Librarian, Durham University Durham University Library, Stockton Road, Durham, DH1 3LY +44 (0)191 334 2941 From m.e.phillips at durham.ac.uk Thu Jan 3 17:08:30 2013 From: m.e.phillips at durham.ac.uk (PHILLIPS M.E.) Date: Thu, 3 Jan 2013 17:08:30 +0000 Subject: [Umlaut-general] Making changes to library holdings display In-Reply-To: <50E5AEFE.8050509@jhu.edu> References: <50E5AEFE.8050509@jhu.edu> Message-ID: Thanks: I will do some more thinking. As it happened shortly after receiving your e-mail we tested the export tool for e-mailing again and found that it gives the holdings details for a book in the e-mail message. So this would be one of perhaps several things that would need a rewrite if we were to go down the road of putting a more hierarchical structure on the data, even if we used the private hash area in the service response. I will take a look at the local helper method idea if I can find out how that is done. So far we have created a app/views/resolve/_holding.html.erb in our app to override the Umlaut one. I will try to work out how the local helper method fits in, as in most cases we probably will not retrieve multiple editions anyway. I will need to be careful, because our college libraries often have a separate bib record for the same work, which muddles things, so I cannot just rely on edition_str being distinct. I could examine the :url because that will contain the bib record number and be reliable for linking. Basically, as we link through to the OPAC by bib number we have to keep things with different bib numbers separate in the Umlaut display even if they appear to be identical editions. Forgetting the separate editions for the moment, and thinking about multiple copies of a single edition, all on the same bib record but at different libraries, one thing I am not clear about is how a local helper would amalgamate items at the same location into one line in the table for display. The main thing that is unclear to me is how the "more info" button would work. I would be very glad to have fewer of these, as we cannot do anything more specific than link through at the bib record level anyway. But at present, with each item generating a separate service response, they all end up as separate links in Umlaut, for example: http://palimpsest-vm1.dur.ac.uk:3000/link_router/index/6310 http://palimpsest-vm1.dur.ac.uk:3000/link_router/index/6311 http://palimpsest-vm1.dur.ac.uk:3000/link_router/index/6312 The button is generated in _holding.html.erb by this code: <%= link_to(image_tag("more_info.gif", "border" => 0, "alt" => 'more info'), {:controller=>"link_router", :id=>p.id}, "target" => "_blank") %> If we were amalgamating items into a summary display ("6 copies available") then we would have several holdings "p" and therefore several p.id. I guess it would not be a problem just taking the first or the last, as they all link through to the same thing. Thanks for your advice: we'll keep you informed of progress. Matthew -----Original Message----- From: Jonathan Rochkind [mailto:rochkind at jhu.edu] Sent: 03 January 2013 16:17 To: umlaut-general at rubyforge.org Cc: PHILLIPS M.E. Subject: Re: [Umlaut-general] Making changes to library holdings display Hmm, I need to read over and think about it more, but I think there's a way for you do this already with easy local customizations, without requiring any changes to Umlaut. There is a way for you to specify your own custom local view template for holdings, without needing to change Umlaut. I'll need to look up what it is. Rather than change the nature/schema of the responses, what I'd suggest is you still generate one response per 'item'/'line' you want to display. Then you can write a local helper method just in your local app, which takes the flat list of response 'lines' and organizes them into the multi-level structure you seem to need (collated by edition_str, it sounds like maybe?). Then you can write a custom local template which uses this local helper method to get the data structures, and display them however you want. Not use the built-in _holding partial, but write your own local one for your needs. You should be able to do this with little to no actual changes need to Umlaut core, all done in your local app. I forget exactly how you specify a custom local view template, which you'll want to do for the holdings section here, I'll have to look that up -- and it's possible that will have to be changed if what's there now is not sufficient for this case. Does this description of a basic approach make sense? Jonathan From rochkind at jhu.edu Thu Jan 3 17:13:49 2013 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 03 Jan 2013 12:13:49 -0500 Subject: [Umlaut-general] Making changes to library holdings display In-Reply-To: References: <50E5AEFE.8050509@jhu.edu> Message-ID: <50E5BC4D.6050602@jhu.edu> To create a local helper method, you just put it in a file in your local ./app/helpers, same as in any other Rails app. Then your local template can call that helper method. This is standard Rails stuff. Over-riding _holdings by creating a local file with the same name is one way to create the local template -- if that works for you, that's fine. There is also a way in Umlaut to tell it to use a template with a different name, but I'd have to remember/look up how to do that. You may be right that you'll have to over-ride other parts of Umlaut to do things the way you want, if you also want the email export to use the different rendering. I see how that's a pain, sorry. But I still think it makes more sense for you to do it locally than to change Umlaut. Not everyone will want the style of output you want -- I don't. Sure, Umlaut core could theoretically be changed to support both types of rendering, configurable or whatever -- but I have found that dealing with ILS holdings is just _too darn variable_, everyone needs to do it differently in a bunch of different areas, it's not feasible to make Umlaut support them all, Umlaut would get too complicated and hard to maintain -- the best thing to do is make it easy to customize locally exactly how you want. However, I am completley open to making changes to Umlaut to make it easier and more concise for you to make the local customizations you need to. On 1/3/2013 12:08 PM, PHILLIPS M.E. wrote: > Thanks: I will do some more thinking. As it happened shortly after > receiving your e-mail we tested the export tool for e-mailing again > and found that it gives the holdings details for a book in the e-mail > message. So this would be one of perhaps several things that would > need a rewrite if we were to go down the road of putting a more > hierarchical structure on the data, even if we used the private hash > area in the service response. > > I will take a look at the local helper method idea if I can find out > how that is done. So far we have created a > app/views/resolve/_holding.html.erb in our app to override the Umlaut > one. I will try to work out how the local helper method fits in, as > in most cases we probably will not retrieve multiple editions anyway. > I will need to be careful, because our college libraries often have a > separate bib record for the same work, which muddles things, so I > cannot just rely on edition_str being distinct. I could examine the > :url because that will contain the bib record number and be reliable > for linking. Basically, as we link through to the OPAC by bib number > we have to keep things with different bib numbers separate in the > Umlaut display even if they appear to be identical editions. > > Forgetting the separate editions for the moment, and thinking about > multiple copies of a single edition, all on the same bib record but > at different libraries, one thing I am not clear about is how a local > helper would amalgamate items at the same location into one line in > the table for display. The main thing that is unclear to me is how > the "more info" button would work. I would be very glad to have > fewer of these, as we cannot do anything more specific than link > through at the bib record level anyway. But at present, with each > item generating a separate service response, they all end up as > separate links in Umlaut, for example: > > http://palimpsest-vm1.dur.ac.uk:3000/link_router/index/6310 > http://palimpsest-vm1.dur.ac.uk:3000/link_router/index/6311 > http://palimpsest-vm1.dur.ac.uk:3000/link_router/index/6312 > > The button is generated in _holding.html.erb by this code: > > <%= link_to(image_tag("more_info.gif", "border" => 0, "alt" => 'more > info'), {:controller=>"link_router", :id=>p.id}, "target" => > "_blank") %> > > If we were amalgamating items into a summary display ("6 copies > available") then we would have several holdings "p" and therefore > several p.id. I guess it would not be a problem just taking the > first or the last, as they all link through to the same thing. > > Thanks for your advice: we'll keep you informed of progress. > > Matthew > > -----Original Message----- From: Jonathan Rochkind > [mailto:rochkind at jhu.edu] Sent: 03 January 2013 16:17 To: > umlaut-general at rubyforge.org Cc: PHILLIPS M.E. Subject: Re: > [Umlaut-general] Making changes to library holdings display > > Hmm, I need to read over and think about it more, but I think there's > a way for you do this already with easy local customizations, without > requiring any changes to Umlaut. > > There is a way for you to specify your own custom local view template > for holdings, without needing to change Umlaut. I'll need to look up > what it is. > > Rather than change the nature/schema of the responses, what I'd > suggest is you still generate one response per 'item'/'line' you want > to display. > > Then you can write a local helper method just in your local app, > which takes the flat list of response 'lines' and organizes them into > the multi-level structure you seem to need (collated by edition_str, > it sounds like maybe?). > > Then you can write a custom local template which uses this local > helper method to get the data structures, and display them however > you want. Not use the built-in _holding partial, but write your own > local one for your needs. > > You should be able to do this with little to no actual changes need > to Umlaut core, all done in your local app. I forget exactly how you > specify a custom local view template, which you'll want to do for the > holdings section here, I'll have to look that up -- and it's possible > that will have to be changed if what's there now is not sufficient > for this case. > > Does this description of a basic approach make sense? > > Jonathan > > _______________________________________________ Umlaut-general > mailing list Umlaut-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/umlaut-general > From rochkind at jhu.edu Thu Jan 3 16:17:02 2013 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 03 Jan 2013 11:17:02 -0500 Subject: [Umlaut-general] Making changes to library holdings display In-Reply-To: References: Message-ID: <50E5AEFE.8050509@jhu.edu> Hmm, I need to read over and think about it more, but I think there's a way for you do this already with easy local customizations, without requiring any changes to Umlaut. There is a way for you to specify your own custom local view template for holdings, without needing to change Umlaut. I'll need to look up what it is. Rather than change the nature/schema of the responses, what I'd suggest is you still generate one response per 'item'/'line' you want to display. Then you can write a local helper method just in your local app, which takes the flat list of response 'lines' and organizes them into the multi-level structure you seem to need (collated by edition_str, it sounds like maybe?). Then you can write a custom local template which uses this local helper method to get the data structures, and display them however you want. Not use the built-in _holding partial, but write your own local one for your needs. You should be able to do this with little to no actual changes need to Umlaut core, all done in your local app. I forget exactly how you specify a custom local view template, which you'll want to do for the holdings section here, I'll have to look that up -- and it's possible that will have to be changed if what's there now is not sufficient for this case. Does this description of a basic approach make sense? Jonathan On 1/3/2013 11:07 AM, PHILLIPS M.E. wrote: > Hello, > > We're still working away on Umlaut when we get the chance, and liking it more and more. I submitted a very minor pull request on GitHub just now: I hope I've gone about it the right way. > > I'd just like a quick pointer in the right direction. We have written a service adaptor for our Millennium ILS so that we can display holdings information about print copies in Umlaut. For example, see http://bit.ly/S6OLW4 for a book with lots of copies. At present the service adaptor basically creates a new service response for every item which it finds attached to the bib records retrieved by the OPAC search, just like the Horizon adaptor which Jonathan wrote. > > The app/views/resolve/_holding.html.erb file is still the same as the standard Umlaut one, written for Jonathan's requirements, except I have made some small tweaks just to prove I know how to edit it. > > What I would like to do is a rather more drastic change, so that we can present a rather more compact display to the user. I would like to be able to show a row in the table for each library which holds copies, and on that row give the classmark (assuming all copies in that library have the same classmark) and then instead of the text "Available" I would like to be able to say things like > > 6 copies available, 2 on loan > 1 copy available > 3 copies on loan (first due 23-01-2013) > > I am confident enough about programming in Ruby to generate these strings, and I can see it would be quite easy to implement this in my millennium.rb service adaptor, by replacing the text returned in the :status key, but there may be better ways to do this. > > Going beyond that initial aim, I am thinking that for vaguer matches, where the adaptor might retrieve several bib records, I would like the results grouped by bib record, rather than being a long list of items. For example, see http://bit.ly/VkXPmS where an OpenURL has matched multiple editions of a book. I would like to try displaying it in this sort of way: > > 3rd ed., 2000 > -- Bill Bryson Library 005.133PER WAL 1 copy available > -- St. Mary's College Library 005.133WAL 1 copy available > 2nd ed., 1996 > -- Bill Bryson Library 005.133PER WAL 4 copies available > -- St. Aidan's College Library 510.78 WAL 1 copy available > > To do this I think I would need to make the service response from millennium.rb return a single response per bib record, with keys such as the current > :edition_str > :match_reliability > :url > > A new element of the response would be an array of libraries or locations, each of which would have keys such as the current > :collection_str > :status > :call_number > > (we do not have any easy way of creating a request link, sadly, as our OPAC is not amenable to this). > > What I would like to ask is, should I just rewrite my millennium.rb file to generate a different structure in the service response, of type "holding", and put a new _holding.html.erb in place to render it, or should I invent a new service response type (such as holding_summary?) to avoid clashing with data structures invented by Jonathan for his Horizon-based holding response type. I am just wondering which would be more maintainable longer term. Would we meet any problems if we meddled with the "standard" holding response type structures? I don't suppose other service adaptors take the call number and locations and do more things with them? Or do they? I suppose you could envisage having the relevant locations pinpointed on a map by another service adaptor, in which case it would need to know how to identify the locations. Or today's opening hours of the relevant locations being available in a side panel. > > I'd be grateful for any guidance or words of wisdom on this sort of thing, so we can avoid doing things the wrong way. > > Oh, and I am guessing that sort of amalgamating these items into bibs is best done before the structures get rendered by the _holding.html.erb file. I don't know much about the .erb syntax yet, but the examples I have looked at have basic logic and looping, but nothing complicated like seeing whether this edition is the same as the previous one and if not starting a new section for a new bib.... > > Thanks, > > Matthew > From rochkind at jhu.edu Thu Jan 3 17:17:52 2013 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 03 Jan 2013 12:17:52 -0500 Subject: [Umlaut-general] Making changes to library holdings display In-Reply-To: References: <50E5AEFE.8050509@jhu.edu> Message-ID: <50E5BD40.1000502@jhu.edu> On 1/3/2013 12:08 PM, PHILLIPS M.E. wrote: > Forgetting the separate editions for the moment, and thinking about > multiple copies of a single edition, all on the same bib record but > at different libraries, one thing I am not clear about is how a local > helper would amalgamate items at the same location into one line in > the table for display. The main thing that is unclear to me is how > the "more info" button would work. I would be very glad to have > fewer of these, as we cannot do anything more specific than link > through at the bib record level anyway. But at present, with each > item generating a separate service response, they all end up as > separate links in Umlaut, for example: You can write your own local template to do it differently. If you don't want a link next to each 'line', then don't have your local template render one there. Have your local template only render a link at the 'heading', to whatever it should be. So, how would a local helper method amalgamate items at the same location? Well, how can you tell the lines are at the same location? Do they have a :library value that's identical? Is that not good enough, do you want to add a new value :library_code or something which has an internal code that will be identical for lines that should be amalgamated? If so, you can do that. Then you can write your own ruby code which looks through the array, and partitions the array into seperate sub-arrays which have identical :library_code's or whatever. The built-in method Array#group_by may be convenient here, but if it didn't exist you could still write less concise logic to do it yourself. Does this make some sense? From rochkind at jhu.edu Thu Jan 3 17:21:10 2013 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 03 Jan 2013 12:21:10 -0500 Subject: [Umlaut-general] Making changes to library holdings display In-Reply-To: <50E5BD40.1000502@jhu.edu> References: <50E5AEFE.8050509@jhu.edu> <50E5BD40.1000502@jhu.edu> Message-ID: <50E5BE06.2050203@jhu.edu> And I'd add, I forget, is the Millenium adapter something that already existed, or something you're writing? It's hard to get these ILS adapters general purpose and flexible enough for everyone. It is possible changes to THAT adapter are needed in Umlaut core. But if you wrote that adpater yourself, and you're having it generate response items that you don't actually want to display _at all_ -- then just rewrite it to not do that. Every response item, basically, is meant to represent an item of output. They don't need to completely and accurately represent the actual copy/item/holding records in your ILS -- they should instead be generated to represent an individual output element. Not sure if that's helpful or just more confusing to say! On 1/3/2013 12:17 PM, Jonathan Rochkind wrote: > > > On 1/3/2013 12:08 PM, PHILLIPS M.E. wrote: >> Forgetting the separate editions for the moment, and thinking about >> multiple copies of a single edition, all on the same bib record but >> at different libraries, one thing I am not clear about is how a local >> helper would amalgamate items at the same location into one line in >> the table for display. The main thing that is unclear to me is how >> the "more info" button would work. I would be very glad to have >> fewer of these, as we cannot do anything more specific than link >> through at the bib record level anyway. But at present, with each >> item generating a separate service response, they all end up as >> separate links in Umlaut, for example: > > You can write your own local template to do it differently. If you don't > want a link next to each 'line', then don't have your local template > render one there. Have your local template only render a link at the > 'heading', to whatever it should be. > > So, how would a local helper method amalgamate items at the same location? > > Well, how can you tell the lines are at the same location? Do they have > a :library value that's identical? Is that not good enough, do you want > to add a new value :library_code or something which has an internal code > that will be identical for lines that should be amalgamated? If so, you > can do that. > > Then you can write your own ruby code which looks through the array, and > partitions the array into seperate sub-arrays which have identical > :library_code's or whatever. The built-in method Array#group_by may be > convenient here, but if it didn't exist you could still write less > concise logic to do it yourself. > > Does this make some sense? > _______________________________________________ > Umlaut-general mailing list > Umlaut-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/umlaut-general From rochkind at jhu.edu Thu Jan 10 14:18:16 2013 From: rochkind at jhu.edu (Jonathan Rochkind) Date: Thu, 10 Jan 2013 14:18:16 +0000 Subject: [Umlaut-general] Rails must be updated Message-ID: <665DBC51D0250A47B4F9306CE71E5FB776C9A96F@JHEMTEBEX1.win.ad.jhu.edu> There is a significant Rails security vulnerability announced -- the vulnerability is as bad as it gets, possibly allowing attackers to execute arbitrary code on your server. You must update the version of Rails you are using. If you are on Umlaut3/Rails3, this is pretty easy. From a source checkout of your app, bundle update rails bundle show rails (make sure it's 3.2.11 or the latest 3.0.x or 3.1.x ; if not you might need to edit your Gemfile to allow the update) Commit your Gemfile.lock to your repo, and redeploy your app from your repo But I'm worried some of you guys are still on Rails2/Umlaut2? Umlaut 2 runs on Rails 2.1 or something, not the latest Rails 2.3 branch. There is no security patch release for Rails pre 2.3. There are still ways to change your configuration to close the exploit, but exactly what code may depend on exactly what version of Rails. I can try to help you figure it out if you need it. (PS: Get off Umlaut2, really, please). Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: