The jobs screen

TL;DR

The in-app job runner. Clicking a job name runs that job for real, which is why the permission behind this screen is an administrator credential rather than a browse-only one.

/system/jobs embeds public/jobs.php in an iframe. The runner lists the job groups, then the jobs in a group, and clicking a job runs it immediately. There is no additional confirmation step.

This runs real jobs

A run writes to the CCC database and calls upstream systems. It is the same execution the crontab performs, from a browser instead of from cron. Only role 1, System administrator, holds this permission in config/reference/userroles.json.

What it lists

The groups under app/jobs/, with install/ excluded, and the job files in each. The list is built by scanning the directory at request time, so a new job appears here as soon as the file exists and nothing has to be registered for it.

The runner reads no database of its own. It shows what is on disk, not what is switched on.

The force switch

A switch at the top right of every listing puts force=true in the URL and carries it along every link it prints. With force on, a job whose step is switched off at /system/crons runs anyway, printing that it was forced and continuing instead of ending with "Cron is paused".

It is off by default, and the crontab never passes it. That is what makes the switch at /system/crons hold the schedule while a deliberate run still works.

The same thing from a shell is the filename followed by force:

docker exec ocean1-ccc php /var/www/app/jobs/akeneo/getproducts.php force

What the output is

Whatever the job prints. Jobs open with print('<pre>') for exactly this reason, so the run reads as a log in the iframe. The runner does not redact anything. A job that printed a configuration value would hand it to anyone holding this permission, which is recorded posture in AGENTS.md: one job used to print every credential and was removed, and no job prints a configuration value today.

Before running a job by hand

  • Check whether the step is paused at /system/crons first. If it is, someone paused it, and forcing it is a decision rather than a fix.
  • A queue-driven job only processes what is queued. Running a worker with an empty queue does nothing; the queue is filled by resetdaily.php, resetcontinuous.php or the screen that queued the work.
  • Watch the batch go todo, in progress, finished at /system/batches. A run that ends without finishing its batch leaves it at in progress until retry.php reopens it.
  • Check that no worker of the same type is already running. Batch claiming is not atomic, and concurrent swap jobs can interfere with each other. Installer jobs are excluded from this runner.

Evidence

Listing, the directory scan, the force switch and its URL carrying from public/jobs.php. The iframe from templates/main/system/jobs.tpl. The permission's weight, the removed job and the no-redaction rule from AGENTS.md, Known posture. The pause behaviour and the shell force form from AGENTS.md, Jobs and the batches queue. The concurrent install warning from AGENTS.md, Development flow. Basis: code-checked against the current implementation.

About this document
  • Type
    page
  • Status
    active
  • Updated
    2026-09-14
  • Created
    2026-09-13
  • Covers
    system/jobs