# PRD — quantivia-clean (Quantivia demo tree)

Evidence date: 2026-10-05. Source: `git@bitbucket.org:overdrive/quantivia-clean.git`, `master` at `808df0f` (2019-06-12, "Demo site backup").

There was no prior PRD in Silicon Ark for this directory. Related sets exist for `quantiviaLive` and `quantivia-svn`. Requirements below come from this repository's code and embedded user guides. Provenance is marked on each item.

`origin/development` is three commits ahead of `master` with QA-oriented subjects. This PRD does not treat that branch as the product baseline unless a requirement says so. Which branch customers or demos see is **Unknown / Requires Confirmation**.

## Product purpose

Quantivia is a **Deliverable Progress and Performance Reporting** tool that runs as an eGroupWare-friendly application (inside the eGroupWare folder tree, authenticated by eGroupWare sessions, but not registered as a standard eGroupWare app).

It supports programme/project teams tracking deliverables, budgets, earned-value style performance (SPI/CPI/EAC), control points, progress updates, and reporting — with per-client UI branding.

Provenance: **Documented** (`class.quantivia_bo.inc.php` header; `quantivia/templates_*/user_guide.php`) and **Implemented**.

This repository specifically captures a **demo site backup** configured for `demo.quantivia.com` on Windows IIS. Provenance: **Implemented** (`header.inc.php`, commit message).

## Users and roles

| Role | What they do | Evidence | Provenance |
|---|---|---|---|
| Anonymous visitor | Can reach login / about; cannot use Quantivia without session | `quantivia/index.php` redirects if no `sessionid` cookie | Implemented |
| eGroupWare authenticated user | Holds session cookies used by Quantivia | `login.php`, `auto_login.php`, cookies `sessionid` / `last_loginid` | Implemented |
| Site Admin (System Administrator) | Member of eGroupWare group `Admins`; site-wide Quantivia admin menus (project list, users, programmes) | `is_user_admin()`, `Menu.php`, `common_pageSetup.php` | Implemented; user-guide term **Documented** |
| Project Admin (Project Administrator) | Member of `P_{p_id}_admin` or listed as project administrator; configures project, tracking, publishes when status allows | `is_user_project_admin()`, `Menu.php` | Implemented |
| Progress Admin | Member of `P_{p_id}_p_admin` (or project admin); progress-administration menus | `is_user_project_progress_admin()` | Implemented |
| Project User (view) | Member of `P_{p_id}`; dashboard, calendar, view-oriented menus | `is_user_project_user()`, `Menu.php` | Implemented |
| Demo user (`webdemo*` pattern) | Auto-login path for idle demo accounts | `auto_login.php` `?demo` | Implemented |
| Worker process (uid `-1`) | Special account bypass for background work | `get_uid()` behaviour noted in SO layer | Implemented |

People authenticate through eGroupWare (SQL auth in this demo config; LDAP/CAS/HTTP/NTLM are configurable in stock setup). Provenance: **Implemented** for SQL demo config; other auth types **Documented** in setup templates, runtime enablement **Unknown / Requires Confirmation**.

## Main workflows

### W1 — Sign in (standard)

Trigger: user opens `login.php` (or eGroupWare entry that leads there).

Expected behaviour:

- Credentials validated by eGroupWare auth.
- Session cookies established.
- User may then open Quantivia via `quantivia/main.php` (or `quantivia/index.php`, which requires cookies and redirects to `main.php`).

Provenance: **Implemented**.

### W2 — Sign in (demo auto-login)

Trigger: user opens `auto_login.php` with demo parameters (including `?demo` behaviour described in code).

Expected behaviour (as coded):

- Locate idle `webdemo*` style accounts, reset demo password, create session, preload dashboard settings for sample projects.
- Present Quantivia-branded demo login UI.

Provenance: **Implemented**. Treat as demo convenience, not a production requirement, unless product owners confirm otherwise.

### W3 — Select project / portfolio

Trigger: authenticated Quantivia user selects a project (or portfolio view).

Expected behaviour:

- Current project id stored in Quantivia session (`p_id`).
- Portfolio / consolidated view uses `p_id == '-1'` and multi-project session keys (`mp_id`).
- Menu items and rights recalculate from Site Admin / Project Admin / Progress Admin / View roles for the selected project(s).

Provenance: **Implemented** (`Menu.php`, session helpers).

### W4 — Configure a project

Trigger: Site Admin creates/manages projects; Project Admin configures categories, budget structure, tracking, theme.

Expected behaviour (menu-gated):

- Site Admin: Project List, Users Admin, Programme Admin.
- Project Admin / View: Project Categories, Budget Structure; Actual Hours Structure only when timekeeping method is Structured.
- Project Admin: Tracking Admin, Theme Admin (as menu allows).

Provenance: **Implemented** (`Menu.php`). Detailed field-level create rules also appear in the user guide (**Documented**).

### W5 — Load deliverables / schedule / progress via wizards

Trigger: Project Admin uses upload wizards.

Expected behaviour (from menus + user guide):

- Deliverable upload, chain assignment, schedule upload, progress upload wizards.
- Control-point chains assigned before schedule upload in documented procedure.
- Large uploads may be scheduled/offloaded.

Provenance: **Documented** (user guide) and **Implemented** (wizard menu entries / worker presence). Exact offload scheduling on this demo host: **Unknown / Requires Confirmation**.

### W6 — Online progress update

Trigger: Progress package issued to a user; user submits; admin reviews.

Lifecycle statuses implemented in BO:

`Invalid`, `Issued`, `Submitted`, `Reviewed`, `Archived`, `Rejected`, `Void`, `Proposed To Delete`, `Expired`.

Email notifications use Quantivia template packs. Packages can expire (documented in user guide / templates).

Provenance: **Implemented** (`$view_statuses`); email/expiry details **Documented** + partially **Inferred** from templates.

### W7 — Publish report and view performance graphs

Trigger: Project Admin publishes when project status is `control`.

Expected behaviour:

- Graphs/reports disabled until a published report exists (menu checks).
- Publish available only when project status is `control`.
- Graphs include S-curves, bulls-eye, trend, pareto, latency, FTE (service JSON endpoints).

Provenance: **Implemented** (`Menu.php`, `services/*.json.php`).

### W8 — Change register / budget control

Trigger: Project Admin manages changes after budget lock (user-guide narrative).

Documented behaviour: locked budget changes go through Change Register.

Whether every code path enforces the lock is **Requires Confirmation**. Menu/feature presence: **Implemented**.

## Functional requirements

### FR-001 — eGroupWare session gate for Quantivia

Requirement: Quantivia pages require an eGroupWare `sessionid` cookie; otherwise redirect to eGroupWare entry.

Evidence: `quantivia/index.php`.

Implementation: Implemented. Confidence: High.

### FR-002 — Role-based Quantivia authorisation

Requirement: Page/API access is denied with HTTP 401 and a translated message when the caller lacks Site Admin, Project Admin, Progress Admin, or Project User rights as required by the page.

Evidence: `checkCurrentUserAutherization()` in `quantivia/inc/common_pageSetup.php`.

Implementation: Implemented. Confidence: High.

### FR-003 — Demo licence gate

Requirement: Certain functions refuse when `$_SESSION['licensed']` is false, returning a Demo-mode message and HTTP 401.

Evidence: `requireFullLicence()`.

Implementation: Implemented. How the flag is set for this demo: **Unknown / Requires Confirmation**. Confidence: Medium.

### FR-004 — Dual-database configuration

Requirement: Quantivia reads identity from the eGroupWare DB and project data from a separate Quantivia DB.

Evidence: `quantivia/setup/quantivia_setings.php` (`demodppr` + `egw_db_*` → `demo`).

Implementation: Implemented (this backup). Confidence: High.

### FR-005 — Earned-value reporting methods

Requirement: System supports RAMP and STEP reporting methods; EAC methods Budget Rate, CPI, CPI+SPI Compounded, CPI+SPI 80:20; forecasting Original Duration / Current Trend / Remaining Duration; timekeeping Structured / Detailed / None.

Evidence: static arrays in `class.quantivia_bo.inc.php`.

Implementation: Implemented. Confidence: High.

### FR-006 — Progress update ticket statuses

Requirement: Progress update views use the status set in `$view_statuses` (Issued → Submitted → Reviewed / Rejected / Void / Expired / Archived, etc.).

Evidence: `class.quantivia_bo.inc.php`.

Implementation: Implemented. Confidence: High.

### FR-007 — Dynamic per-project deliverable tables

Requirement: Deliverable data for a project is stored in dynamically named tables such as `p_{project_id}_deliverables`.

Evidence: `class.quantivia_so.inc.php` / `DEL_TABLE` usage; base schema in `quantivia/setup/sql_construct.php`.

Implementation: Implemented. Confidence: High.

### FR-008 — Client branding via template packs

Requirement: UI/email branding can vary by template pack under `quantivia/templates_*`.

Evidence: 18 `templates_*` directories in this tree; Theme Admin menu.

Implementation: Implemented. Mapping of packs to live clients: **Unknown / Requires Confirmation**.

### FR-009 — Menu visibility by role and project state

Requirement: Navigation generated by `services/Menu.php` shows Dashboard/Calendar/Reports/Wizards/Configuration according to roles, timekeeping method, project status (`control` vs other), licence, and consolidated view.

Evidence: `Menu.php`.

Implementation: Implemented. Confidence: High.

### FR-010 — Tokenised Quantivia API

Requirement: `quantivia/services/qvaapi.php` validates a token before serving API responses.

Evidence: `validate_token()` usage in qvaapi.

Implementation: Implemented. Token issuance/ops process: **Unknown / Requires Confirmation**.

### FR-011 — GroupDAV / WebDAV access

Requirement: eGroupWare GroupDAV and filemanager WebDAV entry points exist for CalDAV/CardDAV/file clients.

Evidence: `groupdav.php`, `webdav.php`.

Implementation: Implemented (platform capability). Whether enabled on the demo host: **Unknown / Requires Confirmation**.

### FR-012 — Risk module integration

Requirement: The risk tracker can instantiate Quantivia business objects / settings.

Evidence: `risk/inc/class.risk_bo.inc.php`.

Implementation: Implemented. End-to-end product rules spanning both apps: **Requires Confirmation** beyond the include wiring.

## Integrations

| System | Purpose | Direction | Evidence | Notes |
|---|---|---|---|---|
| eGroupWare accounts/groups | Identity, ACL, project groups `P_{id}*` | Quantivia → EGW DB | settings + SO | Implemented |
| IMAP / FelamiMail | Mail UI; Quantivia notification templates | Bidirectional (mail) | `felamimail/`, templates | Runtime mail server config Unknown |
| GroupDAV | Calendar/contacts sync | Inbound clients | `groupdav.php` | Enablement Unknown |
| WebDAV | Files | Inbound clients | `webdav.php` | Enablement Unknown |
| LDAP / AD | Auth + organogram helpers | Optional | setup templates, `organogram/` | Demo uses SQL DB auth |
| CAS / NTLM / HTTP auth | Optional EGW auth | Optional | `login.php` / setup | Not confirmed for demo |
| Quantivia JSON API | External access | Inbound | `qvaapi.php` | Token ops Unknown |
| Risk app | Shares Quantivia BO | Internal | `risk_bo` | Implemented wiring |

## Constraints

- PHP era is eGroupWare 1.8 / PHP 5.2+ — not a modern PHP application. Provenance: **Documented** + **Inferred**.
- Quantivia commercial license URL is referenced; GPL applies to eGroupWare core (`doc/LICENSE`). Provenance: **Documented**.
- This tree contains committed demo configuration and credentials — unsuitable as a production secret store. Provenance: **Implemented**. Do not treat those values as current secrets without confirmation.
- No automated Quantivia test suite found. Provenance: **Observed**.

## Assumptions vs confirmed

| Statement | Status |
|---|---|
| Quantivia is the primary business product in this tree | Confirmed (Implemented + Documented) |
| This Git repo is a 2019 demo-site backup | Confirmed (commit message + demo paths) |
| Demo host was `demo.quantivia.com` on IIS | Confirmed for this backup config |
| `development` is the current deployed line | Unknown / Requires Confirmation |
| All shipped EGW apps were enabled on the demo | Unknown (DB-driven) |
| Change Register fully enforces budget lock in all paths | Requires Confirmation |
| Untangle files under `custom/` are part of the product | Unlikely; Requires Confirmation if they must be retained |

## Edge cases

| Case | Observed behaviour | Provenance |
|---|---|---|
| No EGW session cookie | Redirect to `../index.php` from Quantivia index | Implemented |
| Unauthorised role | HTTP 401 + Access Denied message | Implemented |
| Unlicensed / demo session | `requireFullLicence()` blocks function | Implemented |
| Portfolio view (`p_id == -1`) | Aggregated admin/view flags across selected projects | Implemented |
| Project not in `control` | Publish report menu gated | Implemented |
| No published report | Graph menus disabled | Implemented |
| Structured timekeeping off | Actual Hours Structure menu disabled with tooltip | Implemented |
| Worker uid `-1` | Special bypass path | Implemented |

## Requirements needing human confirmation

1. Intended product baseline: `master` vs `development` vs a different Quantivia repo (`quantiviaLive`, `quantivia-svn`).
2. Whether the demo auto-login path must remain documented as a supported feature.
3. Licence enforcement mechanism and whether this demo was intentionally unlicensed for some features.
4. Production/demo URLs still in use.
5. Which client template packs are still commercially relevant.
6. Whether ATE trackers (risk, NCR, WOMT, SMT, permit) are in scope for Quantivia product docs or only platform baggage in this backup.