All good thoughts, in particular the design approach in #3 to maintain freshness is a great new idea. --joe On Tue, Feb 17, 2009 at 10:03 AM, Owen Leonard <oleonard@myacpl.org> wrote:
Now that we're up and running on 3.0, we're discovering some aspects of the Holds Queue report that are not working for us:
1. Title. The list displays the title (245a) and only the title. No subtitle, no name of part/section of a work (245p), no number of part/section of a work (245n). This makes it impossible to pull some items based only on what's in the report (picture being in the stacks with a printed copy, wishing you could click through for more info). In our [custom-built] 2.x report we had barcodes, at least.
2. Damaged items. The holds queue report includes items which have been marked as damaged. I would think that if the holds queue process found a bib record with more than one available item that it should only list available items which are not marked as damaged--perhaps based on the "AllowHoldsOnDamagedItems" preference?
3. Freshness. I realize the process for building the Holds Queue report must be intensive or it wouldn't rely on a cron job. But what about a process for taking the processed and stored Holds Queue report and filtering it based on more current availability information? The display of the report could include a pass to check for current status so that even if the Holds Queue report hadn't regenerated for an hour, it would still hide items on the list which had been made waiting or lost.
I welcome any opinions or ideas anyone might have,
Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org <http://lists.koha.org/mailman/listinfo/koha-devel>
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel