Rediflow
English ▾

How to seed comprehensive testing data

This seed populates existing projects (e.g. after example or ODS fixture) with work packages, tasks, 120 synthetic persons, person assignments, and WBS rows so that capacity views and “by project” data are usable for testing.

When to run

  • After migrations and at least one project/organisation fixture (e.g. scripts/seed_example_projects.py or scripts/seed_from_ods.py).
  • Requires a child organisation: the home organisation must have parent_id set (e.g. a department under EXAMPLE, not the root organisation).

Prerequisites

  • Containerised (Podman) PostgreSQL 18+; DATABASE_URL set (e.g. from .env.dev).
  • Migrations applied.
  • At least one child organisation that will own or participate in projects (e.g. EXAMPLE-IT). You can list organisations under Settings → ORGS and pick a short name that is not a root (root organisations are rejected).

Command

uv run python scripts/seed_testing_data.py --home-org EXAMPLE-IT

Required:

  • --home-org / -o: Short name of the child organisation. All generated persons are attached to this organisation via PersonOrgPeriod. If you pass a root organisation (e.g. EXAMPLE), the script exits with an error; use a child such as EXAMPLE-IT or the leaf organisation that owns your projects.

Optional:

  • --person-count / -n: Number of persons to create (default 120).
  • --limit-projects / -l: Cap the number of projects to enrich (default: all where home organisation is Project Owner Organisation (POO) or partner).
  • --dry-run: Do not write to the database; report what would be done.
  • --seed / -s: Random seed for reproducible runs.

What gets created

  • Projects: All projects where the home organisation is Project Owner Organisation (POO) or a partner are included. Each project gets a reference awarded person-months total in 13–652 (random). Longer projects get more work packages (internal: 4+ by duration; EU: 5–11).
  • Work packages and tasks: The project’s total person-months is spread across Work packages (WPs) (random weights), then each WP’s share is spread across its tasks (1–5 tasks per WP; more tasks when the WP has more person-months). Each task has begin_month and end_month within the project duration. EstCapa rows are created so that each task’s person-months is distributed over its months (capacity/Estimated (EST) views are filled).
  • Tasks: Task names are derived from WP and project name; awarded_pms per task sum to the project total so the project list “Ref. person-months” and “Sum (tasks)” match.
  • Persons: 120 persons (or --person-count) with codes TEST-001 … TEST-120, generated first and last names (50% male / 50% female), and:
    • Full-time equivalent (FTE) distribution: 4% at 0.8 FTE, 1% at 0.6, 1% at 0.4, rest at 1.0.
    • Leave: Majority get 6 weeks paid (annual leave); 5% get additional 2 weeks unpaid. Leave types annual and unpaid are created if missing.
    • PersonOrgPeriod: One period per person to the home organisation (default 2 years back, 2 years forward).
    • PersonWorkerGroupPeriod: If any employee groups (worker groups) exist in Settings, each person is assigned to one for the same period. Persons are distributed round‑robin across all groups (TEST-001 → first group, TEST-002 → second, etc.). When you add a new employee group, re-run the seed to update existing test persons into the new distribution.
  • Person assignments: Persons are assigned to the included projects with allocation percentages. Assignment start/end dates are limited to the task date range (min task begin_month to max task end_month, as dates) when the project has tasks, so allocations fall within when work is planned. Allocation skew: about 80% of total allocation is assigned to the 4% of persons (the 0.8 FTE group).
  • Month overrides: PersonAssignmentMonthOverride rows with Full-time equivalent (FTE) spread 0–100% across the first 12 months. Some persons are over-allocated (>100% total) and some under-allocated (<100%) for allocation lock testing.
  • Work breakdown structure (WBS): For each project, one Wbs row for the home organisation with wp1_pms … wp8_pms filled from the sum of task awarded_pms per Work package (WP) so capacity/EURS views stay consistent.

Idempotency and safety

  • Idempotent: Safe to run multiple times. The script skips existing persons (by code TEST-*), existing WPs (by project + wp_number), existing tasks, existing person assignments, and existing WBS rows. Deterministic codes and naming avoid duplicates on re-run.
  • No deletion: The script only adds data; it does not remove existing persons, assignments, or project structure.

Picking the home organisation

  1. Open Settings → ORGS in the app (or query the DB for orgs.short_name and orgs.parent_id).
  2. Choose an organisation that is a child (has a parent): e.g. an institute under a school, or a department. Its short name is what you pass to --home-org.
  3. If the script reports “Home org must be a child organisation”, the short name you passed is a root organisation; pick a child of it instead.