Forum OpenACS Development: New Specification for Cron Package

Otherwise the admin would have to approve every single query of project leaders for data security issues if the query e.g. queries employee data from various projects.

All I'm trying to say is, can we have a consistent technical way to limit access to the data.

"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.."

I see how requiring the developer/admins to edit/create crons is adequate for many applications. However, I also see how Malte's suggestion would be really useful for dotProject implementations.

Would it be possible for queries to be created that have editable data ranges or parameters, so that the query remains unedited for purposes of cron, but editable within the scope of choosing a range or changing parameters?

For example, could a query be created (by an admin) that allows users to choose which projects they can apply the query to?

It would be helpful to make available a set of queries so that read/write users could choose which db's or projects (and perhaps subcategories etc) to run the cron on, as well as when crons are run --without downgrading the approved query to unapproved and requiring admin re-approval.

Torben,

Any user given write permission on the package instance can create a cron.

I hadn't considered the potential of using parameters in queries, but I can see how that would be useful. Possibly the 'order' attribute could be removed from cron_scripts and a mapping table could be used instead. This would allow re-use of scripts, or at least it might allow someone to copy public/viewable scripts. I am worried that admins would run into problems ensuring that parameterized queries would not remain a security risk. What would be an example of such a query?

Caroline,

cron_notifications only serves to identify what kind of notification to send, if any. It might be the report generated from running the cron, or maybe a link to the report in something like file-storage. I assume that the standard Notifications Package would be used to hold and send emails.

Crons can be run at any time by the user with write access, but the main purpose of the package is to run reports at specific times, since data changes.

I don't want to oversell the report capabilities of this package. The current package is very limited, providing one inflexible format. The proposed changes will allow you to specify a series of scripts and templates to run, and what to do with the result. But anything that can be written into a script/template combination can be supported.

What if, for example, parameterized queries were built using subsequent forms, the first chose the query, the second presented parameter options based on that query --where all parameters were then validated?

What if, for example, parameterized queries were built using subsequent forms, the first chose the query, the second presented parameter options based on that query --where all parameters were then validated?

This sounds more like a UI issue, if the query is fully determined, I guess that the forms page would do validation, and the approved_p flag could be set. In this case, it would just be an application that uses the Cron Package. An admin which loads the package is essentially happy with the amount of validation that is taking place.

Torben, You could create a UI that added crons that would do the required checks for you. This would create a query per subsite with the parameters filled in as you want. I would have to consider if having a parameterized query shared among different owners/users would be useful, or just confusing. What if someone expected certain features of a report and another subsite wanted or lobbied for a change, the change was made and now one other subsite gets upset at the change. So what I was thinking is that each cron would have separate entries for the script, instead of a shared script and a separate parameters table. Btw, nothing prevents a real add-on package that creates and maintains parameters and as a first step runs a script which creates a new query. Any application should be able to load/unload/modify queries as it wishes. My approval process only applies to the Cron Package UI.

One other thing to consider is what happens when 30 essentially identical queries hit the database to run reports at the same time? One idea is to use the proposed pool field of the scripts table. That pool could have enough handles to take care of the load, without affecting too much the website.

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.

http://www.linuxquestions.org/questions/showthread.php?s=&threadid=164050

Hallo,

Is there a way to postpone cron jobs?

When I open up my laptop every morning (I usually leave it suspended), cron launches the jobs that should have run overnight (like updatedb). Sometimes the extra load is not a problem, other times I'd like to issue a command to postpone the jobs for an hour or two. Does this exist?

At the moment, I have to kill the job off and the job gets run next day.

Thanks for any advice!

Z.

Philip