Run a job from an application's menu
A job menu item puts a Nomaflow job in an application's menu, for users who do not administer Nomaflow: the person who loads the month's sales file, the security officer who collects the security data before a review. The item opens the job's own page — the files it needs, its parameters, Run, the log followed live and the previous runs. Nothing else of Nomaflow is shown.
At a glance
The job's page
| Part | Content |
|---|---|
| Title and description | The menu item's label, then the job's description. |
| Parameters | The user parameters the job declares: a dropdown when the values are fixed, a text input otherwise, each pre-filled with its default. A required one carries *; an optional dropdown offers (all). |
| Files | One picker per file_load step that needs a file — File for the step “load”, with the sheet when the step names one. Accepted: .xlsx, .xlsm, .csv, .txt, .tsv. A step with its own path or a watched folder asks for nothing: it reads its file. |
| Run | Uploads the files and starts the run. Pick the file(s) first. or “Company” is required. when something is missing. One run at a time: while one is going, the button waits. |
| Log | The run's state and its log, refreshed every 2 seconds while the run is queued or running, the error in red. Files of the run offers the files it produced — the rejected rows of a load. |
| Previous runs | The last 20 runs: start, state, duration, who ran it (or the trigger, for a scheduled run), rows and the start of the error. A click on a run shows its log. |
The run is an ordinary Nomaflow run: the operators see it in the run history, its notifications and alerts apply.
Putting a job in a menu
In Settings → Menus, add an item of type Job (run it, follow its log) and pick the job in Target: the dropdown lists every job with the first line of its description. No connector is set. See Menu item types.
Who may run it
The item and its page need the permission job:<id> — in Settings → Access → Roles, Beyond the menus, rule type Job, then the job. A deny (!job:<id>) hides the item even when the menu would show it. Superusers see every job.
Every holder of the permission sees all the runs of the job — the previous runs list, their logs and their files —, not only their own.
User parameters
A job declares in jobs.toml what a user may set when running it from its page. Anything else is refused; the operator's other settings stay out of reach.
[[jobs.user_params]]
name = "models"
label = "Explorer model (blank = every model)"
l = { fr = "Modèle Explorateur (vide = tous les modèles)" }
step = "refresh"
choices_from = "explorer_models:nomajde"
| Key | Meaning |
|---|---|
name | The step argument the value is given to. |
label, l | The label shown, per language. Default: the name. |
step | The step that receives the value. |
default | The pre-filled value. |
required | true: the job does not start without a value. |
choices | A fixed list of values: the page shows a dropdown and refuses any other value. |
choices_from | explorer_models:<app> — the Data Explorer models of an application. |
A blank value means not set: the step's own default applies.
What the applications ship
| Application | Folder | Jobs |
|---|---|---|
| Nomasx-1 | Jobs | Collect security, Collect licences — see Nomasx-1 jobs. |
| Nomajde | Jobs | Re-merge security (change package), Re-merge security (all roles), Refresh data dictionary (Explorer models) — see Nomajde jobs. |
| Sales demo | Import | Items file, Companies file, Sales file (one month), Refresh periods, Load the sample files — see The sales demo. |