Author: kiorky



.. contents::

collective.cron is a cron-like asynchronous tasks system based on top of and
The implementation does not have for now all the bells and wistles of a nice UI.
However the simple interface does all the stuff and the underlying job manager works reliably.

Finaly, you can register your tasks easily.

Note that at the moment, we have 100% test coverage. This do not prevent bugs altogether, but it keeps us from making big mistakes.

The design is modern and modular, imagine that you can even easily change from to another job system.

The buildout infrastructure
- base.cfg                -> base buildout informations
- buildout.cfg            -> base buildout for the current plone version
- test-4.0.x.cfg          -> test buildout for plone4.0
- test-4.1.x.cfg          -> test buildout for plone4.1
- test-4.2.x.cfg          -> test buildout for plone4.2

The most important things are in base.cfg.
If you plan to integrate collective.cron to your buildout, please refer to the documentation.

- For now we use the unreleased version of :

Note for tests
- Tests can unpredictibly crash because of monkey patchs to datetime.
  This is a false positive. Just relaunch them if you see something similar ::

      ConflictError: database conflict error (oid 0x2549d9dd3cf6b59b, serial this txn started with 0x0399e4b3adb993bb 2012-10-14 09:23:40.716776, serial currently committed 0x0399e4b3ae733c77 2012-10-14 09:23:40.886752)

collective.cron 1.0 => collective.cron 2.0
- in 1.0, each cron task was a content.
  This was then tedious to replicate and maintain accross multiple instances and plone versions.
  One of the goal of collective.cron 2.0 is to avoid at most to have persistance, specially specialized contents to minimize all the common migration problems we have with an objects database.
  Thus a choice has been made to heavily use as a configuration backend.

- Thus, there is no migration prepared from collective.cron 1.0 to 2.0
  It is up to you to do it.
  Specially, you will have to clean the database of all specific collective.cron 1.0 based & persistent content before upgrading.
  Indeed, as the design of tasks is really different, we can't do any automatic migration.

- First with collective.cron 1.x in your buildout

        - Search, record settings then delete all IBackend content
        - Delete all jobresults & persistent contents
        - Cleanup all the zc.async queue

- Next, deactivate collective.cron 1.x and activate collective.cron 2.x in your buildout

    - Adapt your adapters and content types to work with collective.cron 2.0 (inputs/mark items to work on)
    - add equivalent crons records to the crontab setting of the backends job


  * `Planet Makina Corpus <>`_
  * `Contact us <>`_

.. |makinacom| image::
.. _makinacom:


- kiorky  <>



- `github <>`_

- collective.cron lets you register crons which run periodically in your system.
- Each plone site has a crontab.
- This crontab is used by many components to execute the cron jobs.
- There is a central dashboard which will list all tasks registered on the site crontab.
- The tasks configuration is based on but is designed to be replaceable (component).
- The tasks execution is based on but is designed to be also replaceable (component).

- The cron manager will ensure to restore all cron jobs for all plone sites at zope restart.

A crontab is the collection of all cron registered to a plone site.
A crontab can be (de