Documentation — Planning

The planning module runs on Zenoba’s React engine: gantt-core (14 computation modules — CPM, constraints, calendar, leveling, WBS, history, simulation) and gantt-react (grid, timeline, bars). It provides:

Five mechanisms complement each other, from the finest gesture to the broadest:

1. Undo / History (Ctrl+Z, Ctrl+H) — every write — create, update, delete, link — is recorded with its before and after state. Undo replays the before state, redo the after state; an undone deletion brings back the whole task and its subtasks. A new action after an undo closes the redo. The journal survives reloads and is shared between users; unprotected entries are archived after seven days.
2. Saved version — “Save a version” button (Gantt toolbar, versions bar or Versions page). It freezes the plan under a name and seals every earlier action: they stay readable in the history (audit trail) but can no longer be undone.
3. Automatic versions — taken when a Work session starts and before any restore. An automatic version can be compared with the current plan, pinned (never purged) or restored. They expire after thirty days; saved versions never do.
4. Baselines — the approved, dated plan; comparing the current plan with the baseline measures date and duration variances; it can be restored.
5. Scenarios — a copy of the plan on which an alternative is explored, compared, then applied in one go; an applied scenario cannot be applied again.

Every rollback — version, baseline or scenario — first takes a safety version “Auto: before restore”, then seals the history: to undo it, go back to that safety version.

Tip : work freely in Work mode, undo at will, then save a version once the plan is approved — and create the baseline that variances will be measured against.

Zenoba supports the four PMI / PMBOK link types:

Lag: delay between the two tasks. Positive = wait, negative = overlap.

POST /api/v1/projects/{id}/gantt/link
{ "source": 101, "target": 102, "type": "0", "lag": 2 }

Constraints limit when a task can be scheduled; auto-scheduling respects them.

PUT /api/v1/projects/{id}/gantt/task/104
{ "constraint_type": "snet", "constraint_date": "2026-12-01" }

PUT /api/v1/projects/{id}/gantt/task/106
{ "deadline": "2027-03-01" }

The critical path is the longest sequence of tasks: it sets the minimum project duration. Every zero-slack task belongs to it.

Consequence : any delay on a critical task delays the whole project.

Enable it from the toolbar (“Critical path” button): critical tasks turn red.

GET /api/v1/projects/{id}/gantt/compute
{
  "wbs": { "1": "1", "101": "1.1", ... },
  "critical_path": [101, 102, 103, 107, ...],
  "slack": { "101": 0, "104": 11, "105": 30, ... }
}

Auto-scheduling automatically recalculates dependent task dates when a task is moved. It respects:

• All 4 link types (FS, SS, FF, SF) with positive/negative lag
• All 8 constraint types (ASAP, ALAP, SNET, SNLT, FNET, FNLT, MSO, MFO)
• Non-working days (weekends + calendar holidays)

Enable auto-scheduling from the Gantt toolbar. After each task move, the server recalculates and the Gantt updates automatically.

POST /api/v1/projects/{id}/gantt/auto-schedule
{ "modified_count": 3, "modified_ids": ["104", "109", "113"] }

Free slack is the number of days a task can be delayed without impacting the project end date.

• Slack = 0 : critical task, no delay possible without impacting the project
• Slack = 5 : 5 days of flexibility before impacting the project
• Slack > 10 : the task has plenty of flexibility, no immediate risk

Practical example: if a task has Slack=0 and slips by 1 day, the project end date slips by 1 day. If Slack=5, you have 5 days of buffer before impact.

Enable the Slack feature in the Gantt settings (gear icon): each task’s total and free float appear in its tooltip.

A baseline freezes the approved plan at a given date. Comparing the current plan with the baseline measures variances.

• Click “Baseline” in the toolbar (Ctrl+B)
• Create a baseline and name it (e.g. “Approved plan — 28 Aug committee”)
• Enable the baseline to see the ghost bars on the Gantt

Create a baseline at each key milestone to track variances over time.

Saturdays and Sundays appear in light grey on the timeline, at Day and Week zoom.

Holidays come from the workspace work calendar (Administration → Calendars); auto-scheduling and the critical path respect them.

Every action goes through the JWT-authenticated REST API. Each write is journaled and stays undoable for seven days.

POST   /api/v1/projects/{id}/gantt/task              { "text": "...", "start_date": "2026-09-01", "duration": 5 }
PUT    /api/v1/projects/{id}/gantt/task/{task_id}    { "text": "...", "progress": 0.5, "constraint_type": "snet" }
DELETE /api/v1/projects/{id}/gantt/task/{task_id}
POST   /api/v1/projects/{id}/gantt/link              { "source": 101, "target": 102, "type": "0", "lag": 0 }
DELETE /api/v1/projects/{id}/gantt/link/{link_id}

POST   /api/v1/projects/{id}/checkpoint              // checkpoint: named version + sealed journal
GET    /api/v1/projects/{id}/snapshots               + /compare?a=&b=current, /{snapshot_id}/restore
GET    /api/v1/projects/{id}/journal                 + /undoable, /redoable, /{entry_id}/undo, /{entry_id}/redo
GET    /api/v1/projects/{id}/baselines               + /compare?a=&b=, /{baseline_id}/restore
GET    /api/v1/projects/{id}/scenarios               + /{scenario_id}/compare, /{scenario_id}/apply