Re: [OPEN-ILS-GENERAL] Seeking opinions on client "Transfer All Title Holds" option
Kathy, We do use this option frequently. I can't say how often our libraries wish to only transfer a single hold, but we are currently doing a lot of deduplication which ultimately ends in one or more bibs being deleted. In this case we obviously need to transfer all of the holds. As you've said, there are other ways to accomplish this, though not as efficiently. That said, perhaps we should take a "record merge" approach rather than "pick the best, lose the rest". I don't want to hold this up, but having only recently started this dedupe project this wasn't on our radar when you initially brought it up. I think I'd like to do some experimenting, but perhaps a library setting to disable the option is a good middle ground? Justin On Mon Dec 15 14:32:44 2014, Kathy Lussier wrote: Hi all, I'm picking up this thread four months later. Seeing no objections to removing the option and some hearty assent, I have contributed some code to remove this option from both the old client and the new web client. I'm sending out this e-mail for one last call to see if there are any people who use it with some frequency who believe it should continue to remain available in the client. As I mentioned when I first sent out this message, even with the option removed, the ability to transfer all holds will continue to be available from the bib record's View Holds interface. Thanks! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 8/5/2014 11:51 AM, Tina Ji (Project Sitka) wrote: It is a dangerous action in our setting. We actually disabled it by graying out the option in the staff client. Quoting Kathy Lussier : Hi all, I wanted to seek some feedback on Launchpad bug 1350377 https://bugs.launchpad.net/evergreen/+bug/1350377. The bug seeks an additional permission to be used with the "Transfer All Title Holds" option in the client. However, I was wondering if there would be any support from removing that option from the client altogether. Here's the issue: When you are in a bib record in the staff client, you have the option to transfer *all* title holds to another bib record. You first need to mark the other bib record as a holds transfer destination. However, you also have the option to transfer one or any number of selected holds to the marked bib record from the holds view of the bib record. You could transfer just one hold here or you could select them all if you really needed to transfer all holds. The benefit of using this option is that the user must actively select the holds that will be transferred. I personally think providing a blanket "Transfer All Title Holds" option in the client is dangerous, even if there were a separate permission for it, and unnecessary since there are other methods available in the staff client to accomplish the same task. Making it even more dangerous is the fact that the "Actions for this Record" menu that contains this option to transfer all holds is still available in the holds view of the bib record, which is where you go to transfer selected holds (see the screencast at http://www.screencast.com/t/ifHhJHNqq). It is very easy to mistakenly select this option when you are trying just to transfer just one hold. In fact, I accidentally selected it when I was just testing out the transfer holds scenario a few minutes ago. During a brief discussion in IRC on this issue, it was mentioned that possible use cases for the "transfer all title holds" option are: 1. When staff are manually merging bib records. The client bib merge option automatically merges holds, but there may be reasons staff merge the records without using that option. 2. In cases where there are orphaned holds on a record that no longer has copies to fill the hold. Since I think both of these use cases could be accommodated by using the option where you transfer selected holds, I wanted to see if others would support removing the "Transfer All Title Holds" option. Is there anyone who uses this option with some frequency who thinks it should continue to be available? Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier Tina Ji 1-888-848-9250 Support Specialist BC Libraries Cooperative/Sitka
Re: [OPEN-ILS-GENERAL] Seeking opinions on client "Transfer All Title Holds" option
Hi all, I'm picking up this thread four months later. Seeing no objections to removing the option and some hearty assent, I have contributed some code to remove this option from both the old client and the new web client. I'm sending out this e-mail for one last call to see if there are any people who use it with some frequency who believe it should continue to remain available in the client. As I mentioned when I first sent out this message, even with the option removed, the ability to transfer all holds will continue to be available from the bib record's View Holds interface. Thanks! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 8/5/2014 11:51 AM, Tina Ji (Project Sitka) wrote: It is a dangerous action in our setting. We actually disabled it by graying out the option in the staff client. Quoting Kathy Lussier : Hi all, I wanted to seek some feedback on Launchpad bug 1350377 https://bugs.launchpad.net/evergreen/+bug/1350377. The bug seeks an additional permission to be used with the "Transfer All Title Holds" option in the client. However, I was wondering if there would be any support from removing that option from the client altogether. Here's the issue: When you are in a bib record in the staff client, you have the option to transfer *all* title holds to another bib record. You first need to mark the other bib record as a holds transfer destination. However, you also have the option to transfer one or any number of selected holds to the marked bib record from the holds view of the bib record. You could transfer just one hold here or you could select them all if you really needed to transfer all holds. The benefit of using this option is that the user must actively select the holds that will be transferred. I personally think providing a blanket "Transfer All Title Holds" option in the client is dangerous, even if there were a separate permission for it, and unnecessary since there are other methods available in the staff client to accomplish the same task. Making it even more dangerous is the fact that the "Actions for this Record" menu that contains this option to transfer all holds is still available in the holds view of the bib record, which is where you go to transfer selected holds (see the screencast at http://www.screencast.com/t/ifHhJHNqq). It is very easy to mistakenly select this option when you are trying just to transfer just one hold. In fact, I accidentally selected it when I was just testing out the transfer holds scenario a few minutes ago. During a brief discussion in IRC on this issue, it was mentioned that possible use cases for the "transfer all title holds" option are: 1. When staff are manually merging bib records. The client bib merge option automatically merges holds, but there may be reasons staff merge the records without using that option. 2. In cases where there are orphaned holds on a record that no longer has copies to fill the hold. Since I think both of these use cases could be accommodated by using the option where you transfer selected holds, I wanted to see if others would support removing the "Transfer All Title Holds" option. Is there anyone who uses this option with some frequency who thinks it should continue to be available? Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier Tina Ji 1-888-848-9250 Support Specialist BC Libraries Cooperative/Sitka
Re: [OPEN-ILS-GENERAL] 2.8 release scheduling
Hi Bill, Dates look reasonable to me. Having gone through the alpha cutting stage myself now, I may agree with you that very few people tend to test them and provide feedback with the majority often waiting for the beta when more features have been added of note or substance. Or you know... just running directly off master and testing all along the way. ;) I am +1 to your proposed dates; it'll certainly help that we'll be coordinating the main release cutting alongside the current maintenance release dates. Looks like that'll help with the bug wrangling and getting happier releases out the door in general. Looking forward to seeing what's in the pipeline for 2.8! -- Ben On Fri, Dec 12, 2014 at 4:07 PM, Bill Erickson wrote: > Hi All, > > I'm attempting to sketch out the release schedule for Evergreen 2.8, so I'd > like to run some dates/thoughts by everyone. > > For starters, unless someone requests it, I'm not planning to cut an Alpha > release. I've never seen anyone install one :). I'm happy to cut one if > desired, though. > > Proposed schedule: > > * Jan 14 2015: Feature Target Deadline > > This is the date where all features we expect to get into 2.8 are documented > in LP and targeted to 2.8. They do not have to be coded or tagged as pull > requests by this date. They just need to be documented. As before, this is > a strong recommendation, but not a hard deadline. > > Feb 18 2015: Feature Freeze > > From this date forward, only bug fixes may be committed to master. Any > un-merged features will be booted to 2.9. > > Feb 25 2015: 2.8.beta1 Release > > March 9 2015: 2.8.rc1 Release > > March 18 2015: 2.8.0 Release > > Comments/suggestions welcome. > > Note that in the future I'll avoid cross-posting to both -general and -dev > lists and just send 2.8 updates to -general to cut down on noise. > > Thanks, everyone. > > -b -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
