Rewriting the Dev_Week Reserves Updates
Hey all, I'm rewriting my dev_week reserves patch for koha3 and I need some input on whether certain features I had are truly useful. So here they are: Expiration Date: An optional date after which the reserve would be automatically canceled. This one would be pretty easy. Set to Lowest priority: When the reserve was set to this it would always stay at the bottom of the reserves list, even if a new reserve was added. This one is a bit harder, but still very do-able. Thanks, Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
Kyle, First one YES! That way at the end of a school year say 2 months it would automatically cancel all the holds over the summer. I assume that would be a syspref where you could set the length of hold to cancel - say 60 days. Second one - don't care here about that. David Schuster now if I could only get the holds to fill only from the location of the patron. Kyle Hall wrote:
Hey all, I'm rewriting my dev_week reserves patch for koha3 and I need some input on whether certain features I had are truly useful. So here they are:
Expiration Date: An optional date after which the reserve would be automatically canceled. This one would be pretty easy. Set to Lowest priority: When the reserve was set to this it would always stay at the bottom of the reserves list, even if a new reserve was added. This one is a bit harder, but still very do-able.
Thanks, Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- View this message in context: http://www.nabble.com/Rewriting-the-Dev_Week-Reserves-Updates-tp25508314p255... Sent from the Koha - Dev mailing list archive at Nabble.com.
What I have right now is an expiration date field with a calendar popup. It sounds like you would like a syspref where you can set a default date to have filled in already ( i.e. the last day of school ). Or would it be better to have a syspref that sets a default expiration date X days from today ( i.e. 60 days from the time the hold is being placed ). I could add both, but only one way could be used at a time. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Sep 18, 2009 at 9:11 AM, David Schuster <dschust1@tx.rr.com> wrote:
Kyle,
First one YES! That way at the end of a school year say 2 months it would automatically cancel all the holds over the summer. I assume that would be a syspref where you could set the length of hold to cancel - say 60 days.
Second one - don't care here about that.
David Schuster
now if I could only get the holds to fill only from the location of the patron.
Kyle Hall wrote:
Hey all, I'm rewriting my dev_week reserves patch for koha3 and I need some input on whether certain features I had are truly useful. So here they are:
Expiration Date: An optional date after which the reserve would be automatically canceled. This one would be pretty easy. Set to Lowest priority: When the reserve was set to this it would always stay at the bottom of the reserves list, even if a new reserve was added. This one is a bit harder, but still very do-able.
Thanks, Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- View this message in context: http://www.nabble.com/Rewriting-the-Dev_Week-Reserves-Updates-tp25508314p255... Sent from the Koha - Dev mailing list archive at Nabble.com.
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
I'm rewriting my dev_week reserves patch for koha3
Hooray! I've been coveting your dev_week holds enhancements for ages.
Expiration Date: An optional date after which the reserve would be automatically canceled.
I second this one. Besides David's suggestion (which might require a *global* holds expiration date? By patron category? Sorry, I should stop), I can see public library patrons wanting holds cancelled if they haven't come in by the time they leave for vacation, or book club members wanting a hold cancelled if it isn't fulfilled by the date of their meeting.
Set to Lowest priority: When the reserve was set to this it would always stay at the bottom of the reserves list, even if a new reserve was added. This one is a bit harder, but still very do-able.
The situation that springs to mind on this one is the library staff member who wants to read a bestseller but who doesn't want to displace a patron on the list. The hold wouldn't be filled until you were the last one on the list? Good stuff, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Fri, Sep 18, 2009 at 9:22 AM, Owen Leonard <oleonard@myacpl.org> wrote:
Set to Lowest priority: When the reserve was set to this it would always stay at the bottom of the reserves list, even if a new reserve was added. This one is a bit harder, but still very do-able.
The situation that springs to mind on this one is the library staff member who wants to read a bestseller but who doesn't want to displace a patron on the list. The hold wouldn't be filled until you were the last one on the list?
Right. Our librarians wanted it for borrowers who are home-bound and get to check out books for months at a time, so they get last priority on reserves. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
Good stuff,
Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
" Expiration Date: An optional date after which the reserve would be automatically canceled. This one would be pretty easy." There is the holdCancelLength syspref -- is that what you're working with? Does the code not obey it now? (Haven't checked...). We also have some related development in the works (see bug 3474, http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3474 ) that adds an expiration date to the reserves once the hold is triggered, then moves it from reserves to old_reserves if that date passes without the patron picking up the item. Jane Wagner Library Systems Analyst PTFS Inc. Content Management and Library Solutions 6400 Goldsboro Road, Suite 200 Bethesda, MD 20817 (301) 654-8088 x 151 jwagner@ptfs.com -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Kyle Hall Sent: Friday, September 18, 2009 9:06 AM To: koha-devel Subject: [Koha-devel] Rewriting the Dev_Week Reserves Updates Hey all, I'm rewriting my dev_week reserves patch for koha3 and I need some input on whether certain features I had are truly useful. So here they are: Expiration Date: An optional date after which the reserve would be automatically canceled. This one would be pretty easy. Set to Lowest priority: When the reserve was set to this it would always stay at the bottom of the reserves list, even if a new reserve was added. This one is a bit harder, but still very do-able. Thanks, Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
That sounds like the one option I just mentioned in my last message. I could just hold off on that feature since it sounds just like what you are working on. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Sep 18, 2009 at 9:39 AM, Wagner, Jane <jwagner@ptfs.com> wrote:
" Expiration Date: An optional date after which the reserve would be automatically canceled. This one would be pretty easy."
There is the holdCancelLength syspref -- is that what you're working with? Does the code not obey it now? (Haven't checked...).
We also have some related development in the works (see bug 3474, http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3474 ) that adds an expiration date to the reserves once the hold is triggered, then moves it from reserves to old_reserves if that date passes without the patron picking up the item.
Jane Wagner Library Systems Analyst PTFS Inc. Content Management and Library Solutions 6400 Goldsboro Road, Suite 200 Bethesda, MD 20817 (301) 654-8088 x 151 jwagner@ptfs.com
-----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Kyle Hall Sent: Friday, September 18, 2009 9:06 AM To: koha-devel Subject: [Koha-devel] Rewriting the Dev_Week Reserves Updates
Hey all, I'm rewriting my dev_week reserves patch for koha3 and I need some input on whether certain features I had are truly useful. So here they are:
Expiration Date: An optional date after which the reserve would be automatically canceled. This one would be pretty easy. Set to Lowest priority: When the reserve was set to this it would always stay at the bottom of the reserves list, even if a new reserve was added. This one is a bit harder, but still very do-able.
Thanks, Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
participants (4)
-
David Schuster -
Kyle Hall -
Owen Leonard -
Wagner, Jane