kawa
906f3ca101
- SUMMARY.md: icon lookup + copy into .intunewin staging - STATE.md: advanced to 06-01 complete, 100% progress, PKG-04 decision recorded - ROADMAP.md: phase 06 marked Complete (1/1 plans) - REQUIREMENTS.md: PKG-04 marked complete
142 lines
8.3 KiB
Markdown
142 lines
8.3 KiB
Markdown
# Roadmap: ImpTune
|
|
|
|
## Overview
|
|
|
|
ImpTune ships in five phases ordered by risk and dependency. The foundation phase validates the highest-risk unknown (.intunewin format) before anything else is built. Driver management comes next because the printer form's driver dropdown depends on parsed INF data. Printer configuration and persistence follow. Script generation builds the PowerShell output that both export formats wrap. Finally, package export assembles all prior work into downloadable deployment artifacts.
|
|
|
|
## Phases
|
|
|
|
**Phase Numbering:**
|
|
- Integer phases (1, 2, 3): Planned milestone work
|
|
- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)
|
|
|
|
Decimal phases appear between their surrounding integers in numeric order.
|
|
|
|
- [x] **Phase 1: Foundation** - Docker container scaffold, SQLite schema, and .intunewin format spike (completed 2026-04-10)
|
|
- [ ] **Phase 2: Driver Management** - Driver ZIP upload, INF parsing, DriverDesc dropdown, volume persistence
|
|
- [x] **Phase 3: Printer Configuration** - Full printer config form, client/tenant labels, SQLite persistence (completed 2026-04-10)
|
|
- [x] **Phase 4: Script Generation** - PowerShell install/uninstall/detection scripts with all correctness guards (completed 2026-04-10)
|
|
- [x] **Phase 5: Package Export** - .intunewin and NinjaRMM ZIP export, icon upload, command preview (completed 2026-04-10)
|
|
- [x] **Phase 6: Wire Icon into .intunewin Export** - Embed uploaded icon in .intunewin package, closing PKG-04 gap (completed 2026-04-10)
|
|
- [ ] **Phase 7: Dashboard & Navigation Polish** - Fix /packages 404 nav link, wire dashboard recent queries
|
|
|
|
## Phase Details
|
|
|
|
### Phase 1: Foundation
|
|
**Goal**: A running Docker container with the app scaffold, data schema, and a validated .intunewin generation capability
|
|
**Depends on**: Nothing (first phase)
|
|
**Requirements**: INFRA-01, INFRA-02
|
|
**Success Criteria** (what must be TRUE):
|
|
1. Running `docker compose up` starts the app and serves a response on localhost
|
|
2. The container has no Node.js dependency and starts from a single image
|
|
3. A Python-generated .intunewin file uploads successfully to a real Intune tenant without format errors
|
|
4. SQLite database initializes automatically on first run with the correct schema
|
|
**Plans**: 3 plans
|
|
|
|
Plans:
|
|
- [x] 01-01: Docker container scaffold (Dockerfile, python:3.12-slim-bookworm, volume, healthcheck)
|
|
- [ ] 01-02: SQLite schema and data models (peewee ORM, driver + printer + client tables)
|
|
- [ ] 01-03: .intunewin format spike (AES-256-CBC encrypted ZIP-in-ZIP with detection.xml, validated against real Intune)
|
|
|
|
### Phase 2: Driver Management
|
|
**Goal**: Technicians can upload driver packages and select driver names from parsed INF data — no free-text entry
|
|
**Depends on**: Phase 1
|
|
**Requirements**: DRV-01, DRV-02, DRV-03, DRV-04, DRV-05
|
|
**Success Criteria** (what must be TRUE):
|
|
1. User can upload a ZIP file containing INF + supporting files via the browser
|
|
2. After upload, user sees a dropdown of driver names extracted from the INF (DriverDesc values), not a text field
|
|
3. Uploaded driver packages survive container restarts (persisted to Docker volume)
|
|
4. System flags files in the driver package that are not referenced by the INF, with a count or list
|
|
**Plans**: 2 plans
|
|
|
|
Plans:
|
|
- [ ] 02-01-PLAN.md — INF parser with TDD (encoding detection, token resolution, multi-model, unused files)
|
|
- [ ] 02-02-PLAN.md — Driver upload endpoint, persistence, drivers page UI with HTMX
|
|
|
|
### Phase 3: Printer Configuration
|
|
**Goal**: Technicians can configure all printer parameters, assign printers to clients, and retrieve saved configs without re-uploading drivers
|
|
**Depends on**: Phase 2
|
|
**Requirements**: PRNT-01, PRNT-02, PRNT-03, PRNT-04, PRNT-05, PRNT-06, PRNT-07, PRNT-08, PRNT-09, PRNT-10
|
|
**Success Criteria** (what must be TRUE):
|
|
1. User can fill in a printer form (name, IP, port, duplex, color/BW, paper size, collate) and save it
|
|
2. Saved printer appears under its client/tenant label after page refresh
|
|
3. System auto-populates the port name field from the entered IP address (user can edit it)
|
|
4. User can open a saved printer config and regenerate its package without uploading the driver again
|
|
**Plans**: 2 plans
|
|
|
|
Plans:
|
|
- [ ] 03-01-PLAN.md — Printer + client CRUD, form with all fields, Alpine.js port derivation, grouped list, integration tests
|
|
- [ ] 03-02-PLAN.md — Printer detail page, saved config retrieval, driver association display, regeneration placeholder
|
|
|
|
### Phase 4: Script Generation
|
|
**Goal**: The system produces correct, production-ready PowerShell scripts that handle all Intune and RMM execution contexts
|
|
**Depends on**: Phase 3
|
|
**Requirements**: SCRPT-01, SCRPT-02, SCRPT-03, SCRPT-04, SCRPT-05
|
|
**Success Criteria** (what must be TRUE):
|
|
1. Generated install script runs successfully on a clean Windows endpoint via Intune (pnputil staging + port + driver + printer + settings)
|
|
2. Generated install script self-elevates via UAC when run interactively by a standard user
|
|
3. Generated install script relaunches in 64-bit PowerShell when Intune's 32-bit process triggers it (WOW64 guard)
|
|
4. Generated uninstall script removes printer, driver, and port cleanly
|
|
5. Generated detection script returns exit 0 when the printer is installed and exit 1 when it is not
|
|
**Plans**: 2 plans
|
|
|
|
Plans:
|
|
- [ ] 04-01-PLAN.md — Install script generator with TDD (Jinja2 template, WOW64 guard, UAC elevation, pnputil two-step, duplex mapping, idempotency)
|
|
- [ ] 04-02-PLAN.md — Uninstall + detection templates, script download API endpoints, router registration
|
|
|
|
### Phase 5: Package Export
|
|
**Goal**: Technicians can download a complete, ready-to-deploy package for either Intune or NinjaRMM in one click
|
|
**Depends on**: Phase 4
|
|
**Requirements**: PKG-01, PKG-02, PKG-03, PKG-04, PKG-05
|
|
**Success Criteria** (what must be TRUE):
|
|
1. User can download a .intunewin file that Intune accepts as a Win32 app without errors
|
|
2. User can download a NinjaRMM ZIP containing the install script and driver folder
|
|
3. User can upload a custom PNG icon (256x256, max 750KB) and it is embedded in the .intunewin package
|
|
4. User can preview and copy the Intune install command string and uninstall command string before exporting
|
|
**Plans**: 2 plans
|
|
|
|
Plans:
|
|
- [ ] 05-01-PLAN.md — NinjaRMM ZIP + .intunewin export endpoints (packages.py router, integration tests)
|
|
- [ ] 05-02-PLAN.md — Icon upload with Pillow validation, command preview UI, export buttons on printer detail page
|
|
|
|
### Phase 6: Wire Icon into .intunewin Export
|
|
**Goal**: The uploaded PNG icon is included in the .intunewin package so Intune displays it as the app icon
|
|
**Depends on**: Phase 5
|
|
**Requirements**: PKG-04
|
|
**Gap Closure**: Closes PKG-04 (unsatisfied), icons.py→packages.py integration gap, icon→.intunewin flow gap
|
|
**Success Criteria** (what must be TRUE):
|
|
1. `packages.py` queries Icon model for the printer's icon before building .intunewin
|
|
2. Icon file is copied into the tmpdir staging area and included in the .intunewin output
|
|
3. An integration test verifies icon presence in the exported .intunewin package
|
|
|
|
Plans:
|
|
- [ ] 06-01-PLAN.md — Wire icon lookup into packages.py, copy to tmpdir, integration test
|
|
|
|
### Phase 7: Dashboard & Navigation Polish
|
|
**Goal**: Navigation links work correctly and the dashboard shows real data instead of empty placeholders
|
|
**Depends on**: Phase 3
|
|
**Requirements**: None (UX/integration fixes)
|
|
**Gap Closure**: Closes base.html→/packages 404 integration gap, pages.py dashboard hardcoded [] integration gap
|
|
**Success Criteria** (what must be TRUE):
|
|
1. Clicking the /packages nav link does not produce a 404
|
|
2. Dashboard shows recently created printers from the database
|
|
3. Dashboard shows recently exported packages from the database
|
|
|
|
Plans:
|
|
- [ ] 07-01-PLAN.md — Add /packages route, wire dashboard queries, verify nav links
|
|
|
|
## Progress
|
|
|
|
**Execution Order:**
|
|
Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5
|
|
|
|
| Phase | Plans Complete | Status | Completed |
|
|
|-------|----------------|--------|-----------|
|
|
| 1. Foundation | 3/3 | Complete | 2026-04-10 |
|
|
| 2. Driver Management | 1/2 | In Progress| |
|
|
| 3. Printer Configuration | 2/2 | Complete | 2026-04-10 |
|
|
| 4. Script Generation | 2/2 | Complete | 2026-04-10 |
|
|
| 5. Package Export | 2/2 | Complete | 2026-04-10 |
|
|
| 6. Wire Icon into .intunewin Export | 1/1 | Complete | 2026-04-10 |
|
|
| 7. Dashboard & Navigation Polish | 0/1 | Pending | |
|