I have completed the first draft of a document of proposed changes to the current Cronjob Package.

A serious limitation of the package is that you can only specify one time to run the cron. Anything more complex would require separate entries in the database. When I started working on correcting that problem I decided to rethink the entire package.

I would like to get any additional ideas and feedback now, before I start writing any code. I'm going to try an experiment of writing documentation before code and see how that works. This should allow further rounds of comment before changes become too time consuming.

The database itself isn't subsite aware, so I doubt that could be done. Anyone who can add a page to the system can already execute any database query they want.

My belief is that most queries/reports used in the cron package will probably be written by a developer, but the new format would allow non-developers to view the cron, and run it when they want (assuming they have the correct privilege).

Once a report works, a designer could make it look nicer by adjusting the template which would not require admin approval.

The new package could also be mounted once and only an admin added, this would duplicate the current package behavior.

Thank you very much for your paper on the Cron package. I was not familiar with it.  One question, can you use the Notification package rather then creating cron_notifications.

Here is how I would see it working. Each cron job is an object that a user can request notification on. For example there is a daily status report run at 2am each day.  The user could request an instant notification on this and get his report at 2am. Or he could choose a weekly notification and get one email each week with all the daily reports aggregated. One would have to be careful on the UI because if you choose a daily notification on a daily report you might end up with your report being sent a long time after it was generated.

We have a feature we need to add in the next week that might use the Cron Package, probably in its current form since we need it now.

On our Project Portfolio Management Site, the user can currently generate a report on all closed tasks for a project within a date range. The report is about a screen full per task and includes pictures, a survey response and some other task specific data.  There is an option that lets the user "email this page" to any address.

The next step is to nightly send one email with this same report for each task marked complete in the last 24 hours.  We can't insert a notification at the time of status change because the report must include the most up to date photos and survey response and potentially someone could make a typo and find it later, add more information later in the day, etc.

Does this sound like a good application for the current Cron Package?

The next step is to nightly send one email with this same report for each task marked complete in the last 24 hours.

If you can write a tcl script to do the job, the current Cronjob Package can schedule the task. In this case you would probably not use the 'sql' field, you would just use the regular db_* api to select data and then insert data into the Notifications Package for delivery.

I like the idea, can you give an example of what you would like to see as being possible?

I guess parameters could be validated against the user_id or the package_id for the instance.

Consider a (not too distant future) dotProject package, where  an admin has control over 30 or so subsites, each focused on a manufacturing or construction project.  Each subsite uses a series of cron reports to track project progress. Some might create indexed ratios from data for financial officers, other indexes might be for project managers, functional management (operations), and stakeholders. Other reports might notify resource controls (inventory, HR etc.).

The point  is that most of the reports would be identical across all the subsites, only changing by project name/id (relevant dbs [if named differently] and perhaps report cycles.  If a query was considered new every time a project started to use the report for the first time, the load would become very tedious. The load from mistakes in editing and delayed report generation (as each query is painstakenly put in a que for authorization) could be higher than the security risk involved in adding an optional parameter feature.

Based on your most recent comments of this being a UI issue, are you stating that queries already have this level of flexibility --without editing?

Andrew, one change is the addition of logging. I only have a simple table for now, but possibly a return status could be added. Then you would need to query that table somehow to check what happened. Maybe another alternative it to provide a post script callback. Actually the cron_notification_types table will probably work as a callback mechanism. In addition, the archive_type and archive_data fields of the cron_scripts table might be useful to consider. Maybe one archive type would be kick off another script? Bottom line: I will probably have two or three of these types of things built in, so adding another might not be that hard.

Also, note that the script type is going to be expandable. Essentially anything you can run on your box, you can schedule (umm, or will be able).

If you come across any additional ideas on how other systems work, which you like, please pass them along.

Philip, are you speaking of unix cron? This thread was about the cronjob package, not related to unix cron. However, to suspend a job, which runs under your user account, do:

crontab -e 

You will probably be in vi to edit, so 'arrow' down to the line you want to suspend and then type 'i', then '#', to comment out the line. then type ':wq' to save and exit. 

In the cronjob package you can also disable a cronjob.