On Fri, Jul 10, 2009 at 10:53 AM, Cab Vinton <span dir="ltr"><<a href="mailto:bibliwho@gmail.com">bibliwho@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A cronjob for daily emails w/ a list of the Holds to pull would be a<br>
great idea & a time & labor-saver for librarians.</blockquote><div><br>Not really. Checking and printing your email isn't any easier or more time saving than checking and printing the web interface you're already using. <br>
<br>I'm sure librarians use their email all day too, but the point is to run the report as late as possible before the actual retrieval. That's what makes the web version more accurate. Retrieving books for holds that have already been filled or canceled and searching for books that have in fact already been checked out will certainly waste more time than loading a webpage.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Finally, every now & again, I wonder how often various cronjobs are<br>
set to run. Since we're hosted by a third party & don't have access to<br>
that info, it would be great if this was added as a separate tab on<br>
the About Koha page (i.e., a list of cronjobs, description of what<br>
they do, & how often they're set up to run.)</blockquote><div><br>Without getting into too much technical detail, I'll just say that this actually cannot be implemented securely. The apache user does not and should not have access to system users' crontabs. In our case, for example, it wouldn't matter anyway: the cron jobs are run on a totally separate zebra server. Koha would have no way of knowing where to check for information. <br>
</div></div><br>One fix would be the longstanding proposal to move to an internal Koha dispatcher daemon that effectively manages the various "cron-like" jobs internally and would also allow scheduled reports of any kind, but that is a serious undertaking with its own security and reliability considerations. <br>
<br>-- <br>Joe Atzberger<br>LibLime - Open Source Library Solutions<br>