vault backup: 2026-02-27 10:43:35
This commit is contained in:
@@ -9,6 +9,21 @@ tags:
|
||||
|
||||
EventKit is a **decentralised, [[04 - Federation Architecture|federated]]** [[01 - Inventory Management|inventory management]], [[02 - Planning Module|planning]], and [[03 - CRM Module|CRM]] platform purpose-built for the **event industry**. Each company hosts its own instance with full data sovereignty, while optional federation enables cross-company workflows like sub-hire tracking, equipment sharing, and inter-company asset visibility.
|
||||
|
||||
### Business Model
|
||||
|
||||
**Open core** — free self-hosted with community support, paid SaaS with premium features.
|
||||
|
||||
### MVP Scope
|
||||
|
||||
**Build order**: Inventory + Scanning → Planning → CRM → Federation
|
||||
|
||||
**Target sectors for MVP**:
|
||||
|
||||
- 🔊 Audio (PA systems, microphones, mixing desks)
|
||||
- 💡 Lighting (moving heads, LED fixtures, dimmers)
|
||||
- 🔩 Rigging (truss, motors, chains, shackles)
|
||||
- ⚡ Power distribution (distros, cables, generators)
|
||||
|
||||
---
|
||||
|
||||
## Core Modules
|
||||
@@ -57,6 +72,7 @@ graph TB
|
||||
API["API Server"]
|
||||
Fed["Federation Service"]
|
||||
Worker["Background Workers"]
|
||||
MQ[("NATS / Redis")]
|
||||
DB[(Database)]
|
||||
Files[(File Storage)]
|
||||
|
||||
@@ -65,7 +81,8 @@ graph TB
|
||||
API --> DB
|
||||
API --> Files
|
||||
API --> Fed
|
||||
API --> Worker
|
||||
API --> MQ
|
||||
MQ --> Worker
|
||||
Worker --> DB
|
||||
end
|
||||
|
||||
|
||||
@@ -89,15 +89,17 @@ stateDiagram-v2
|
||||
### Asset Register
|
||||
|
||||
| Feature | Description |
|
||||
| --------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| --------------------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| Individual asset tracking | Each asset has a UUID, serial number, and QR code |
|
||||
| Asset numbering scheme | Human-readable IDs: product prefix + sequential number (e.g. `SM58-001`, `SM58-002`). UUID for internal use |
|
||||
| Legacy barcode support | Import and map existing barcode/label schemes — dual scanning supported alongside new QR codes |
|
||||
| Purchase & financial data | Purchase date, supplier, cost, insurance value, depreciation |
|
||||
| Documentation | Photos, manuals, spec sheets, certificates attached per asset |
|
||||
| Firmware / version tracking | Track software/firmware versions on digital equipment |
|
||||
| Custom attributes | User-defined fields per product category (e.g. "wattage" for amps, "throw distance" for projectors) |
|
||||
| Condition tracking | User-definable states — defaults: **Good** / **Damaged** / **Written Off** |
|
||||
| Condition notes | Free-text notes updated at each check-in inspection |
|
||||
| Full audit trail | Every status change, location change, and edit is logged with timestamp and user |
|
||||
| Full audit trail | Every status change, location change, and edit is logged with timestamp and user (field-level diffs) |
|
||||
|
||||
### Cases & Packing
|
||||
|
||||
@@ -125,12 +127,13 @@ stateDiagram-v2
|
||||
### Availability Engine
|
||||
|
||||
| Feature | Description |
|
||||
| ---------------------- | ---------------------------------------------------------------- |
|
||||
| ---------------------- | ------------------------------------------------------------------------------- |
|
||||
| Real-time availability | See what's available for any date range, per product or category |
|
||||
| Conflict detection | Alert when the same asset is double-booked across events |
|
||||
| Availability search | "Show me 10× available SM58s for March 15-18" |
|
||||
| Calendar view | Heatmap-style availability calendar showing utilisation density |
|
||||
| Shortage alerts | Warn planners when demand exceeds available stock |
|
||||
| Reservation rules | Configurable per event priority level (hard lock vs. overridable with approval) |
|
||||
|
||||
### Sub-hire Management
|
||||
|
||||
@@ -146,11 +149,11 @@ stateDiagram-v2
|
||||
### Consumables
|
||||
|
||||
| Feature | Description |
|
||||
| ------------------------- | --------------------------------------------------------------------------------- |
|
||||
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
|
||||
| Stock level tracking | Current quantity per consumable product |
|
||||
| Reorder thresholds | Automated alerts when stock falls below a defined level |
|
||||
| Par levels | Target stock levels to maintain |
|
||||
| Consumption per event | Track how much of each consumable was used per event |
|
||||
| Consumption per event | Estimated at planning stage, actual recorded after event — deducted from stock when physically dispatched (scan-based) |
|
||||
| Purchase order generation | Generate POs to restock consumables — requires manual confirmation before sending |
|
||||
|
||||
### Maintenance & Testing
|
||||
@@ -180,6 +183,44 @@ stateDiagram-v2
|
||||
| Insurance valuation | Current value of all assets for insurance purposes |
|
||||
| Depreciation report | Book value vs. purchase price over time |
|
||||
|
||||
### Stocktake
|
||||
|
||||
All approaches are supported — user selectable:
|
||||
|
||||
| Mode | Description |
|
||||
| ---------------- | --------------------------------------------------- |
|
||||
| **Full** | Scan everything, compare against expected inventory |
|
||||
| **Partial/zone** | Scan specific areas, shelves, or categories |
|
||||
| **Rolling** | Continuous — scan a section each day |
|
||||
|
||||
### Prep Checklists
|
||||
|
||||
Optional per-product checklists for event preparation (e.g. "test power", "check firmware", "include accessories"). Checklists are user-definable per product category.
|
||||
|
||||
### Damage Reporting
|
||||
|
||||
Configurable workflow per damage severity:
|
||||
|
||||
| Step | Description |
|
||||
| ----------------------- | ---------------------------------------------------- |
|
||||
| Flag asset | Mark as damaged, auto-create maintenance task |
|
||||
| Photo evidence | Required or optional depending on configuration |
|
||||
| Cost estimate | Optional — estimate for client charge-back |
|
||||
| Severity-based workflow | Different actions triggered by damage severity level |
|
||||
|
||||
### Return Inspection
|
||||
|
||||
Detailed return inspection workflow:
|
||||
|
||||
| Step | Action |
|
||||
| ---- | ---------------------------------------------- |
|
||||
| 1 | Scan asset |
|
||||
| 2 | Per-item checklist (product-category-specific) |
|
||||
| 3 | Photos of current condition |
|
||||
| 4 | Condition update (good / damaged / write-off) |
|
||||
| 5 | Route to cleaning queue if needed |
|
||||
| 6 | Shelve / re-stock |
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
@@ -75,6 +75,8 @@ stateDiagram-v2
|
||||
| **Closed** | Final invoicing, profit/loss analysis, post-event review notes |
|
||||
| **Cancelled** | Event cancelled — reserved stock released, cancellation fees applied |
|
||||
|
||||
> **Event phases are customisable per event type.** The phases above are provided as defaults. Admins can define custom phase workflows for different event categories.
|
||||
|
||||
---
|
||||
|
||||
## Feature Breakdown
|
||||
@@ -82,23 +84,24 @@ stateDiagram-v2
|
||||
### Event / Job Management
|
||||
|
||||
| Feature | Description |
|
||||
| --------------------- | --------------------------------------------------------------- |
|
||||
| --------------------- | ----------------------------------------------------------------------------------------------------------------- |
|
||||
| Event creation | Dates (setup, show, strike), venue link, client link (→ CRM) |
|
||||
| Multi-day events | Events spanning multiple days with per-day schedules |
|
||||
| Multi-venue events | Festivals or events with multiple stages/spaces |
|
||||
| Project grouping | Group related events under a project (tours, recurring shows) |
|
||||
| Event status workflow | Progress through lifecycle phases with validation rules |
|
||||
| Project grouping | Group related events under a project (tours, recurring shows). Simple grouping for MVP, full project entity later |
|
||||
| Event status workflow | Progress through customisable lifecycle phases with validation rules |
|
||||
| Event templates | Save and reuse event configurations for recurring job types |
|
||||
| Event duplication | Clone an event as a starting point for a similar job |
|
||||
| Recurring events | Template-based auto-generation + clone previous event |
|
||||
| Internal notes | Free-text notes, checklists, and file attachments per event |
|
||||
| Event tags | Categorise events (corporate, festival, wedding, concert, etc.) |
|
||||
|
||||
### Pull Lists / Equipment Planning
|
||||
|
||||
| Feature | Description |
|
||||
| ---------------------- | ------------------------------------------------------------------- |
|
||||
| ---------------------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| Build from catalogue | Add products/kits from the inventory catalogue to the pull list |
|
||||
| Kit/set expansion | Adding a kit auto-adds all component products |
|
||||
| Kit/set expansion | Adding a kit auto-adds all component products. User chooses: all-or-nothing (default) or individually tracked |
|
||||
| Availability check | Real-time check against inventory — green/amber/red indicators |
|
||||
| Conflict detection | Alert if requested equipment is already booked elsewhere |
|
||||
| Shortage handling | When stock is short, suggest sub-hire or alternative products |
|
||||
@@ -145,6 +148,14 @@ Crew members can log in (web or mobile app) to:
|
||||
| Dispatch tracking | Track when vehicles leave warehouse and arrive at venue |
|
||||
| Return tracking | Track when vehicles return from venue |
|
||||
|
||||
#### Transport Roadmap
|
||||
|
||||
| Phase | Features |
|
||||
| ---------------- | --------------------------------------------------------------- |
|
||||
| **MVP** | Assign vehicles to events, simple load lists |
|
||||
| **Intermediate** | Weight/volume calculations, truck pack lists, capacity warnings |
|
||||
| **Advanced** | Route optimisation, multi-stop planning, fuel tracking |
|
||||
|
||||
### Venue Management
|
||||
|
||||
| Feature | Description |
|
||||
@@ -157,6 +168,17 @@ Crew members can log in (web or mobile app) to:
|
||||
| Blackout dates | Track dates when a venue is unavailable |
|
||||
| Venue history | See all past events at a venue with notes |
|
||||
|
||||
> **Venue federation** is planned but will start as local-only. In a future phase, instances will be able to share venue specs across the network via [[04 - Federation Architecture|federation]].
|
||||
|
||||
### Calendar Integration
|
||||
|
||||
| Feature | Phase | Description |
|
||||
| ------------------------- | ------ | -------------------------------------------------- |
|
||||
| **CalDAV sync** | MVP | Generic calendar sync for crew and event schedules |
|
||||
| **iCal export** | MVP | Export events and crew schedules as `.ics` files |
|
||||
| **Google Calendar sync** | Future | Bidirectional sync with Google Calendar |
|
||||
| **Outlook/Exchange sync** | Future | Bidirectional sync with Microsoft 365 |
|
||||
|
||||
### Timeline & Scheduling
|
||||
|
||||
| Feature | Description |
|
||||
|
||||
@@ -88,21 +88,24 @@ Stages are **fully customisable** per instance. Multiple pipelines can exist (e.
|
||||
### Quoting
|
||||
|
||||
| Feature | Description |
|
||||
| ------------------- | ---------------------------------------------------------------- |
|
||||
| ------------------- | ------------------------------------------------------------------------------------------------------------ |
|
||||
| Quote builder | Build quotes from the equipment catalogue with real-time pricing |
|
||||
| Line items | Equipment hire, crew costs, transport, consumables, sub-hire |
|
||||
| Discount management | Per-line or overall discounts with approval workflows |
|
||||
| Quote versioning | Track revisions sent to the client |
|
||||
| Quote versioning | Each revision saved as separate version (v1, v2, v3…) |
|
||||
| Quote templates | Reusable templates for common job types |
|
||||
| PDF generation | Professional, branded quote PDFs |
|
||||
| Quote → Invoice | Copy confirmed quote to invoice draft for manual adjustment |
|
||||
| Quote → Event | Accepted quote auto-creates an event in the Planning module |
|
||||
| Availability check | Verify equipment availability while building the quote |
|
||||
| Client approval | E-signature approval with comments/conditions via client portal (simple approval for MVP, e-signature later) |
|
||||
|
||||
### Communication
|
||||
|
||||
| Feature | Description |
|
||||
| ------------------ | ---------------------------------------------------------- |
|
||||
| Email integration | Send/receive emails from within the CRM (IMAP/SMTP or API) |
|
||||
| -------------------- | --------------------------------------------------------------------------------------- |
|
||||
| Email integration | Full IMAP/SMTP — send and receive emails from within the CRM |
|
||||
| Email sub-addressing | Route emails to projects/clients via `+` addressing (e.g. `crm+project123@company.com`) |
|
||||
| Email templates | Reusable templates for common communications |
|
||||
| Call logging | Log phone calls with notes and outcomes |
|
||||
| Meeting scheduling | Schedule and track meetings |
|
||||
@@ -113,13 +116,16 @@ Stages are **fully customisable** per instance. Multiple pipelines can exist (e.
|
||||
EventKit includes **built-in accounting features** as the primary financial workflow. External integrations (Xero, QuickBooks) are available but secondary.
|
||||
|
||||
| Feature | Description |
|
||||
| ----------------------- | ------------------------------------------------------- |
|
||||
| Invoice generation | Generate invoices from confirmed quotes or events |
|
||||
| ----------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| Invoice generation | Generate invoices from confirmed quotes (copy to draft) |
|
||||
| Line item detail | Equipment, crew, transport, consumables, sub-hire costs |
|
||||
| Invoice status tracking | Draft → Sent → Paid → Overdue |
|
||||
| Payment tracking | Record payments received, partial payments, deposits |
|
||||
| Deposit invoicing | Separate deposit invoice + final invoice (e.g. 50% upfront) |
|
||||
| Purchase orders | Generate and track POs for consumables and sub-hire |
|
||||
| Credit notes | Issue credit for cancellations or adjustments |
|
||||
| Tax calculation | Per-product + per-customer tax logic (EU reverse charge for B2B) — configurable rates |
|
||||
| Bank API integration | Open Banking APIs (PSD2) + generic bank statement import (CSV/MT940) for automatic payment matching |
|
||||
| Financial reporting | Revenue, expenses, profit/loss per event and period |
|
||||
| Xero integration | Optional sync — invoices, payments, contacts |
|
||||
| QuickBooks integration | Optional sync — invoices, payments, contacts |
|
||||
@@ -176,6 +182,21 @@ Clients can log in to a self-service portal:
|
||||
|
||||
---
|
||||
|
||||
## Data Import / Migration
|
||||
|
||||
Import from other systems is an optional future feature. Supported sources:
|
||||
|
||||
| Source | Format |
|
||||
| ------------------------- | --------------------------- |
|
||||
| Spreadsheets | Excel / Google Sheets (CSV) |
|
||||
| Rentman | CSV / API export |
|
||||
| Flex Rental Solutions | CSV export |
|
||||
| Current RMS | CSV / API export |
|
||||
| EasyJob | CSV export |
|
||||
| Custom / in-house systems | Generic CSV import |
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [[00 - System Overview]] — High-level system overview
|
||||
|
||||
@@ -226,6 +226,45 @@ Assets can be **permanently transferred** between instances (e.g. selling equipm
|
||||
| 4 | Seller's instance marks asset as "Transferred" (end of local history) |
|
||||
| 5 | Buyer's instance creates asset with full imported history |
|
||||
|
||||
### Federation Versioning
|
||||
|
||||
The federation protocol relies on **Protobuf's built-in backward compatibility**:
|
||||
|
||||
- New fields are **additive** — old instances ignore unknown fields
|
||||
- Deprecated fields are **never removed**, only marked obsolete
|
||||
- Breaking changes are **documented** and communicated to partners
|
||||
- No formal version negotiation during handshake — keep it simple
|
||||
|
||||
### Dispute Resolution
|
||||
|
||||
Equipment condition disputes are handled **out-of-band** (phone, email). EventKit provides supporting evidence:
|
||||
|
||||
| Feature | Description |
|
||||
| -------------------------- | ------------------------------------------------------ |
|
||||
| Timestamped condition logs | Before/after condition recorded at dispatch and return |
|
||||
| Photo evidence | Optional photos attached to condition logs |
|
||||
| Audit trail | Full history of who scanned what and when |
|
||||
| Dispute handling | Out-of-band — no formal in-app dispute workflow |
|
||||
|
||||
### Federation Downtime Handling
|
||||
|
||||
| Behaviour | Description |
|
||||
| ---------------------- | ------------------------------------------------------- |
|
||||
| **Outbox queue** | Pending requests queued when partner is offline |
|
||||
| **Auto-retry** | Automatic retry when partner comes back online |
|
||||
| **Admin notification** | Notify admin after configurable hours of failed retries |
|
||||
| **Manual retry** | Option to manually retry or cancel queued requests |
|
||||
|
||||
### Federation Data Visibility
|
||||
|
||||
How much partner inventory data is visible is **configurable per trust level**:
|
||||
|
||||
| Trust Level | Visibility |
|
||||
| ------------ | ------------------------------------------------------- |
|
||||
| **Minimal** | Real-time availability queries only |
|
||||
| **Standard** | Cached summary (category counts, general availability) |
|
||||
| **Full** | Product catalogue shared (not individual asset details) |
|
||||
|
||||
---
|
||||
|
||||
## Global Asset Identity
|
||||
|
||||
@@ -97,6 +97,8 @@ Labels should include:
|
||||
| **Rugged handheld** | Heavy warehouse / outdoor use | e.g. Zebra TC-series — built-in scanner, drop-resistant |
|
||||
| **Fixed scanner** | Check-in/check-out desk | Mounted scanner at warehouse dispatch point |
|
||||
|
||||
**Default**: Phone camera (web or native). **Power-user option**: Bluetooth barcode scanner paired to phone/tablet for bulk warehouse operations.
|
||||
|
||||
### Recommended Setup
|
||||
|
||||
| Role | Device |
|
||||
@@ -106,6 +108,15 @@ Labels should include:
|
||||
| **Office / planning** | Web UI (no scanning needed) |
|
||||
| **Dispatch desk** | Fixed USB scanner + desktop |
|
||||
|
||||
### Label Printing
|
||||
|
||||
| Method | Description |
|
||||
| ------------------- | ------------------------------------------------------------------------ |
|
||||
| **PDF generation** | Default — generate PDF sheets for any label printer (Avery sheets, etc.) |
|
||||
| **Direct printing** | Optional — integration with label printers (Brother QL, DYMO, Zebra) |
|
||||
|
||||
Users can also print QR codes however they prefer — EventKit provides the QR data and a printable format.
|
||||
|
||||
---
|
||||
|
||||
## Scanning Workflows
|
||||
|
||||
@@ -22,7 +22,10 @@ Non-functional requirements, deployment model, API design, and infrastructure co
|
||||
| **API definition** | **Protocol Buffers (Protobuf)** | Schema-first API design, backward-compatible evolution, generates Go server stubs + TypeScript/JS clients |
|
||||
| **Database** | **PostgreSQL 15+** | Robust, proven, excellent JSON support, full-text search, strong ecosystem |
|
||||
| **Frontend** | **React** (TanStack Router + TanStack Query) | Team expertise, strong ecosystem, ConnectRPC generates typed TS clients |
|
||||
| **File storage** | Local filesystem or S3-compatible | Configurable per deployment |
|
||||
| **UI components** | **shadcn/ui** | Accessible, composable, Tailwind-based component library |
|
||||
| **File storage** | Local filesystem or S3-compatible | Configurable per deployment — local for self-hosted, S3/MinIO for SaaS |
|
||||
| **Search** | PostgreSQL full-text search | Start with built-in FTS; add dedicated engine (Meilisearch) later if needed |
|
||||
| **Background jobs** | NATS or Redis | External message broker — suits Kubernetes deployment model |
|
||||
|
||||
### Why ConnectRPC
|
||||
|
||||
@@ -48,8 +51,10 @@ This means:
|
||||
| **Framework** | React | SPA — SEO is not a requirement |
|
||||
| **Routing** | @tanstack/router | Type-safe, file-based routing |
|
||||
| **Data fetching** | @tanstack/query | Caching, background refetching, optimistic updates |
|
||||
| **UI components** | shadcn/ui | Accessible, composable component library |
|
||||
| **API client** | ConnectRPC generated TS code | Type-safe from `.proto` definitions |
|
||||
| **Build tool** | Vite | Fast dev server and optimised builds |
|
||||
| **Theme** | Dark mode (default) | Light mode + high contrast mode as toggles |
|
||||
|
||||
### Mobile App
|
||||
|
||||
@@ -120,12 +125,16 @@ Each company runs their own instance. The deployment should be **simple and repr
|
||||
For the hosted SaaS offering, use a **shared database with tenant isolation**:
|
||||
|
||||
| Aspect | Approach |
|
||||
| -------------------- | ----------------------------------------------------------------------- |
|
||||
| -------------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| **Database** | Shared PostgreSQL instance, tenant ID on every table |
|
||||
| **Isolation** | Row-level security (RLS) policies enforce tenant boundaries |
|
||||
| **Isolation** | Row-level security (RLS) policies enforce tenant boundaries — complete isolation, no cross-tenant data ever |
|
||||
| **Cross-tenant** | No shared data between tenants — use Federation for inter-company workflows |
|
||||
| **Connection** | Connection pooling shared across tenants |
|
||||
| **Migration** | Single schema, all tenants upgrade together |
|
||||
| **Data sovereignty** | Tenants wanting full isolation should use self-hosted or dedicated tier |
|
||||
| **Onboarding** | Self-service with admin approval, or manual admin creation |
|
||||
| **Data export** | Full JSON/CSV export at any time (GDPR Article 20) + right to be forgotten |
|
||||
| **Quotas** | Soft limits with warnings — pricing tiers TBD |
|
||||
|
||||
| Approach | Description |
|
||||
| ---------------------- | -------------------------------------------------------------------- |
|
||||
@@ -262,18 +271,24 @@ service InventoryService {
|
||||
|
||||
## Authentication & Authorisation
|
||||
|
||||
### Authentication Methods
|
||||
### Identity Provider — Keycloak
|
||||
|
||||
| Method | Use Case |
|
||||
| --------------------------- | -------------------------------------- |
|
||||
| **Email + password** | Default for local users |
|
||||
| **OAuth 2.0 / OIDC** | SSO via Google, Microsoft, etc. |
|
||||
| **LDAP / Active Directory** | Enterprise directory integration |
|
||||
| **API keys** | For programmatic access / integrations |
|
||||
| **mTLS** | Federation — instance-to-instance |
|
||||
Authentication is delegated to **Keycloak** as the central identity provider:
|
||||
|
||||
| Component | Approach |
|
||||
| ---------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| **Identity provider** | Keycloak (self-hosted alongside EventKit) |
|
||||
| **Protocol** | Generic OIDC — works with Keycloak, Auth0, or any OIDC provider |
|
||||
| **Session management** | Handled by Keycloak (tokens, refresh, SSO) |
|
||||
| **User onboarding** | Admin creates user → email invitation → user sets password |
|
||||
| **Role management** | Roles defined in Keycloak, permissions mapped in EventKit |
|
||||
| **Federation auth** | mTLS certificates for instance-to-instance communication |
|
||||
| **API keys** | Granular scopes (e.g. `inventory:read`, `planning:write`) — start with full access, add scopes later |
|
||||
|
||||
### Role-Based Access Control (RBAC)
|
||||
|
||||
Roles are managed in Keycloak. EventKit reads roles and maps them to permissions:
|
||||
|
||||
| Role | Permissions |
|
||||
| ------------- | -------------------------------------------------------------------- |
|
||||
| **Admin** | Full system access, user management, federation management, settings |
|
||||
@@ -284,7 +299,70 @@ service InventoryService {
|
||||
| **Crew** | View assigned events, update availability, timesheets |
|
||||
| **Read-only** | View dashboards and reports, no edit capabilities |
|
||||
|
||||
Custom roles with granular permission sets should also be possible.
|
||||
Custom roles with granular permission sets are fully supported — admins create roles in Keycloak, then map permissions in EventKit.
|
||||
|
||||
---
|
||||
|
||||
## Data Management
|
||||
|
||||
### Soft Delete
|
||||
|
||||
| Behaviour | Description |
|
||||
| --------------- | ------------------------------------------------------- |
|
||||
| **Default** | Soft delete — records marked as deleted, hidden from UI |
|
||||
| **Recovery** | Admins can restore soft-deleted records |
|
||||
| **Hard delete** | Admin action after configurable retention period |
|
||||
| **Cascade** | Related records follow the parent's delete behaviour |
|
||||
|
||||
### Audit Trail
|
||||
|
||||
| Feature | Description |
|
||||
| ------------------------ | --------------------------------------------- |
|
||||
| **Field-level tracking** | Old value → new value for every field change |
|
||||
| **User attribution** | Who made the change and when |
|
||||
| **Entity history** | Full change history per record (like Git log) |
|
||||
| **Immutable log** | Audit records cannot be edited or deleted |
|
||||
| **Future** | Full diff view (Git-style) for every record |
|
||||
|
||||
### Caching
|
||||
|
||||
| Component | Strategy |
|
||||
| ---------- | ----------------------------------------------------- |
|
||||
| **Layer** | Redis (shared with background job broker) |
|
||||
| **Scope** | Session cache, query cache, federation response cache |
|
||||
| **Policy** | TTL-based with manual invalidation on writes |
|
||||
|
||||
### Database Migrations
|
||||
|
||||
| Environment | Strategy |
|
||||
| --------------- | ---------------------------------------------------- |
|
||||
| **Development** | Automatic on startup |
|
||||
| **Production** | Explicit migration step before deploying new version |
|
||||
|
||||
---
|
||||
|
||||
## UI & Navigation
|
||||
|
||||
| Feature | Description |
|
||||
| ------------------- | -------------------------------------------------------------------------------- |
|
||||
| **Navigation** | Sidebar with module sections + command palette (Cmd+K) |
|
||||
| **Dashboard** | Configurable per user — multiple layouts with simple view switching |
|
||||
| **Bulk operations** | Bulk status change, assign to event, print labels, import/export |
|
||||
| **List views** | Table default, card view for specific entities (e.g. assets with photos) |
|
||||
| **Keyboard** | Full keyboard navigation (like Linear) — Cmd+K, shortcuts for all common actions |
|
||||
|
||||
### Dashboard Widgets
|
||||
|
||||
| Widget | Description |
|
||||
| ------------------------------- | ---------------------------------- |
|
||||
| Upcoming events | Next 7/14/30 days |
|
||||
| Equipment utilisation overview | Usage rates across categories |
|
||||
| Open quotes / pending approvals | Awaiting client or internal action |
|
||||
| Overdue returns / missing items | Equipment past return deadline |
|
||||
| Revenue summary | Period revenue with trend |
|
||||
| Low-stock consumable alerts | Below reorder threshold |
|
||||
| Crew availability overview | Available vs booked crew |
|
||||
| Recent activity feed | Latest system-wide actions |
|
||||
|
||||
---
|
||||
|
||||
@@ -357,6 +435,20 @@ erDiagram
|
||||
| **Webhooks** | ✅ Yes | Outbound webhooks for third-party integration |
|
||||
| **SMS** | ❌ No | Not planned |
|
||||
|
||||
### Webhook Events
|
||||
|
||||
All major entity changes trigger outbound webhooks:
|
||||
|
||||
| Event Category | Examples |
|
||||
| -------------- | ------------------------------------------------ |
|
||||
| **Assets** | Status changed (checked out, returned, damaged) |
|
||||
| **Events** | Status changed (confirmed, completed, cancelled) |
|
||||
| **Quotes** | Approved / rejected by client |
|
||||
| **Invoices** | Paid, overdue |
|
||||
| **Stock** | Low stock alert |
|
||||
| **Federation** | Sub-hire request, asset transfer |
|
||||
| **CRUD** | Create / update / delete on any major entity |
|
||||
|
||||
---
|
||||
|
||||
## Monitoring & Observability
|
||||
@@ -371,15 +463,78 @@ erDiagram
|
||||
|
||||
---
|
||||
|
||||
## Reporting
|
||||
|
||||
| Feature | Description |
|
||||
| ------------------------- | -------------------------------------------------- |
|
||||
| **Output formats** | In-app, PDF, CSV/Excel, scheduled email delivery |
|
||||
| **Predefined reports** | Standard reports with filters and grouping |
|
||||
| **Custom report builder** | Drag-and-drop fields, custom calculations (future) |
|
||||
| **Roadmap** | Predefined + filters for MVP, full builder later |
|
||||
|
||||
---
|
||||
|
||||
## Document Generation
|
||||
|
||||
| Feature | Description |
|
||||
| ---------------------- | --------------------------------------------------------- |
|
||||
| **Branding** | Company logo + name + colours for MVP |
|
||||
| **Full templates** | Header, footer, fonts, layout customisation (future) |
|
||||
| **Template engine** | HTML/CSS templates — users can provide their own (future) |
|
||||
| **Document numbering** | Configurable prefix + sequence per document type |
|
||||
|
||||
---
|
||||
|
||||
## Data Retention & Files
|
||||
|
||||
| Feature | Description |
|
||||
| -------------------- | ------------------------------------------------------------------- |
|
||||
| **Retention policy** | Configurable per entity type (e.g. events: 5 years, audit: 7 years) |
|
||||
| **Legal compliance** | Follow Austrian/EU legal requirements (varies by document type) |
|
||||
| **File versioning** | Keep version history (v1, v2, v3) when files are updated |
|
||||
|
||||
---
|
||||
|
||||
## Notifications
|
||||
|
||||
| Feature | Description |
|
||||
| -------------------- | ---------------------------------------------------------------- |
|
||||
| **User preferences** | Granular per-event-type toggle (future feature) |
|
||||
| **Email templates** | Tenant-branded for MVP (logo, colours), full customisation later |
|
||||
|
||||
---
|
||||
|
||||
## API & Extensibility
|
||||
|
||||
| Feature | Description |
|
||||
| --------------------- | ------------------------------------------------------------- |
|
||||
| **API documentation** | Auto-generated from Protobuf definitions (buf.build registry) |
|
||||
| **MVP docs** | Minimal — just the `.proto` files |
|
||||
| **Plugin system** | Design for extensibility now, implement plugin API later |
|
||||
| **Webhooks** | Primary extensibility mechanism for MVP |
|
||||
|
||||
---
|
||||
|
||||
## Testing & Environments
|
||||
|
||||
| Feature | Description |
|
||||
| ------------------------ | ----------------------------------------------------------------------- |
|
||||
| **Testing strategy** | Whatever ships fastest with confidence |
|
||||
| **Staging environments** | Ephemeral preview environments per PR (Kubernetes-native, not priority) |
|
||||
| **Local development** | Docker Compose for local dev stack |
|
||||
|
||||
---
|
||||
|
||||
## Internationalisation
|
||||
|
||||
| Feature | Description |
|
||||
| ----------------------- | -------------------------------------------------------- |
|
||||
| **Multi-language UI** | Support for multiple interface languages |
|
||||
| **Multi-currency** | Prices and costs in different currencies with conversion |
|
||||
| ----------------------- | ---------------------------------------------------------------------------- |
|
||||
| **i18n framework** | Built-in from the start — translations added incrementally |
|
||||
| **MVP languages** | English + German |
|
||||
| **Multi-currency** | Configurable from the start — currency, tax rates, tax ID formats per tenant |
|
||||
| **Timezone support** | Per-user timezone, event times stored in UTC |
|
||||
| **Date/number formats** | Locale-aware formatting |
|
||||
| **Right-to-left** | RTL layout support for applicable languages |
|
||||
| **Date/number formats** | Locale-aware formatting (e.g. `dd.MM.yyyy` for DE, `MM/dd/yyyy` for EN) |
|
||||
| **Right-to-left** | RTL layout support for applicable languages (future) |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -14,11 +14,11 @@ Remaining decisions and questions that need answers before or during implementat
|
||||
## Business & Scope
|
||||
|
||||
| # | Question | Options / Notes |
|
||||
| --- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
|
||||
| 1 | **Primary equipment types** — which sectors will be supported first? | Audio, lighting, video, staging, rigging, power, furniture, décor — prioritise for MVP |
|
||||
| --- | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
|
||||
| 1 | ~~**Primary equipment types** — which sectors first?~~ | ✅ **Answered**: Audio, Lighting, Rigging, Power distribution for MVP |
|
||||
| 2 | ~~**Target company size** — small (1-5 people) or larger (20+)?~~ | ✅ **Answered**: Small to medium companies wanting to share resources. Both scales should be possible |
|
||||
| 3 | **Pricing model** — how will EventKit itself be offered? | Open source, freemium, paid self-hosted licence, or SaaS alongside self-hosted? |
|
||||
| 4 | **MVP scope** — which module to build first? | Inventory + Scanning → Planning → CRM → Federation is a natural order |
|
||||
| 3 | ~~**Pricing model** — how will EventKit itself be offered?~~ | ✅ **Answered**: Open core — free self-hosted, paid SaaS with premium features |
|
||||
| 4 | ~~**MVP scope** — which module to build first?~~ | ✅ **Answered**: Inventory + Scanning → Planning → CRM → Federation |
|
||||
| 5 | ~~**Data migration** — what systems are companies migrating from?~~ | ✅ **Answered**: Nice-to-have future feature. Import tooling not a priority for MVP |
|
||||
|
||||
---
|
||||
@@ -26,14 +26,14 @@ Remaining decisions and questions that need answers before or during implementat
|
||||
## Technical
|
||||
|
||||
| # | Question | Options / Notes |
|
||||
| --- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
|
||||
| --- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| 6 | ~~**Tech stack** — backend language and framework?~~ | ✅ **Decided: Go** with ConnectRPC |
|
||||
| 7 | ~~**Frontend framework**~~ | ✅ **Decided: React** with @tanstack/router + @tanstack/query. Mobile: React Native / Expo (planned, not priority) |
|
||||
| 7 | ~~**Frontend framework**~~ | ✅ **Decided: React** with @tanstack/router + @tanstack/query + shadcn/ui. Mobile: React Native / Expo (planned, not priority) |
|
||||
| 8 | ~~**Database**~~ | ✅ **Decided: PostgreSQL 15+** |
|
||||
| 9 | **Search engine** | Built-in DB search, or dedicated (Meilisearch, Typesense) for large catalogues? |
|
||||
| 10 | **File storage** | Local filesystem, S3-compatible, or both? |
|
||||
| 11 | **Real-time updates** | gRPC server-streaming (via ConnectRPC) is the natural choice. SSE fallback for browsers? |
|
||||
| 12 | **Background jobs** | Go goroutines + internal queue, or external (Redis, NATS)? |
|
||||
| 9 | ~~**Search engine**~~ | ✅ **Answered**: PostgreSQL full-text search first, dedicated engine (Meilisearch) later if needed |
|
||||
| 10 | ~~**File storage**~~ | ✅ **Answered**: Both — local filesystem + S3-compatible, configurable per deployment |
|
||||
| 11 | ~~**Real-time updates**~~ | ✅ **Answered**: Not from the start. Future nice-to-have via gRPC server-streaming |
|
||||
| 12 | ~~**Background jobs**~~ | ✅ **Answered**: External broker (NATS or Redis) — suited for Kubernetes deployment |
|
||||
|
||||
---
|
||||
|
||||
@@ -45,17 +45,17 @@ Remaining decisions and questions that need answers before or during implementat
|
||||
| 14 | ~~**Protocol format**~~ | ✅ **Decided: gRPC via ConnectRPC** with Protobuf service definitions |
|
||||
| 15 | ~~**Pricing in federation** — should sub-hire rates be shared automatically?~~ | ✅ **Answered: Prices negotiated per-transaction** — out-of-band negotiation, system tracks equipment movement |
|
||||
| 16 | ~~**Asset ownership transfer** — can an asset be permanently sold to another instance?~~ | ✅ **Answered: Yes** — permanent ownership transfer is supported |
|
||||
| 17 | **Federation versioning** — how to handle protocol upgrades? | Protobuf's built-in backward compatibility helps here |
|
||||
| 18 | **Dispute resolution** — what happens if companies disagree about asset condition? | Photo evidence at dispatch/return, timestamped condition logs |
|
||||
| 17 | ~~**Federation versioning** — how to handle protocol upgrades?~~ | ✅ **Answered**: Protobuf backward compat, document breaking changes, no formal version negotiation |
|
||||
| 18 | ~~**Dispute resolution** — what happens if companies disagree about asset condition?~~ | ✅ **Answered**: Timestamped condition logs + out-of-band dispute handling |
|
||||
|
||||
---
|
||||
|
||||
## Scanning & Hardware
|
||||
|
||||
| # | Question | Options / Notes |
|
||||
| --- | ------------------------------------------------------------------- | ----------------------------------------------------------------------- |
|
||||
| 19 | **Primary scanning device** — phone cameras or dedicated scanners? | Phones (lower cost) vs. Bluetooth scanners (faster) vs. both |
|
||||
| 20 | **Label printer** — should EventKit support direct printing? | Or generate PDFs and let users print on any printer? |
|
||||
| --- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
|
||||
| 19 | ~~**Primary scanning device** — phone cameras or dedicated scanners?~~ | ✅ **Answered**: Both — phone camera default, Bluetooth scanner as power-user option |
|
||||
| 20 | ~~**Label printer** — should EventKit support direct printing?~~ | ✅ **Answered**: PDF default, direct printing optional |
|
||||
| 21 | ~~**Existing barcodes** — do companies already have asset labels?~~ | ✅ **Answered: Yes, support legacy barcode import/mapping** if possible |
|
||||
| 22 | ~~**Offline requirements** — how often will users be offline?~~ | ✅ **Answered: Nice-to-have**, not a hard requirement |
|
||||
|
||||
@@ -67,8 +67,8 @@ Remaining decisions and questions that need answers before or during implementat
|
||||
| --- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 23 | ~~**Invoicing depth** — full invoicing or integration with existing accounting?~~ | ✅ **Answered: Integrated accounting features are the priority.** Xero/QuickBooks integration is optional/secondary. Invoices, payments, and purchases all in-app |
|
||||
| 24 | ~~**Accounting integrations** — which platforms?~~ | ✅ **Answered: Xero and QuickBooks** — optional, not priority. Integrated features come first |
|
||||
| 25 | **Email integration** — built-in email or link to external? | IMAP/SMTP integration vs. Gmail/Outlook API vs. just logging |
|
||||
| 26 | **Marketing features** — email campaigns needed? | Or leave marketing to dedicated tools (Mailchimp, etc.)? |
|
||||
| 25 | ~~**Email integration** — built-in email or link to external?~~ | ✅ **Answered**: Full IMAP/SMTP with sub-addressing for routing emails to projects/clients |
|
||||
| 26 | ~~**Marketing features** — email campaigns needed?~~ | ✅ **Answered**: Not for now — leave to dedicated tools |
|
||||
|
||||
---
|
||||
|
||||
@@ -77,22 +77,15 @@ Remaining decisions and questions that need answers before or during implementat
|
||||
| # | Question | Options / Notes |
|
||||
| --- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| 27 | ~~**Crew management depth** — basic assignment or full scheduling?~~ | ✅ **Answered**: Crew members login and confirm availability. Basic scheduling with crew portal |
|
||||
| 28 | **Transport planning** — basic or advanced? | Basic: assign vehicles. Advanced: route optimisation, weight distribution |
|
||||
| 29 | **Venue database** — shared across instances? | Could be a federated feature — shared venue specs across the network |
|
||||
| 30 | **Calendar integration** — which platforms? | Google Calendar, Outlook/Exchange, CalDAV — for crew and event sync |
|
||||
| 28 | ~~**Transport planning** — basic or advanced?~~ | ✅ **Answered**: Start basic → intermediate (weight/volume) → advanced (route optimisation) |
|
||||
| 29 | ~~**Venue database** — shared across instances?~~ | ✅ **Answered**: Start local, federate later |
|
||||
| 30 | ~~**Calendar integration** — which platforms?~~ | ✅ **Answered**: CalDAV + iCal export for MVP. Google Calendar + Outlook/Exchange later |
|
||||
|
||||
---
|
||||
|
||||
## Priority Matrix
|
||||
|
||||
Suggested priority for answering these questions:
|
||||
|
||||
| Priority | Questions | Reason |
|
||||
| -------------------------------------- | --------------------------- | ------------------------------------------------- |
|
||||
| ✅ **Answered** | 2, 5-8, 13-16, 21-24, 27 | See strikethrough items above |
|
||||
| 🔴 **Must answer before starting** | 1, 4 | Scope (which equipment sectors first, MVP order) |
|
||||
| 🟡 **Answer during early development** | 3, 9-11, 19 | Affects architecture but can be deferred slightly |
|
||||
| 🟢 **Answer before beta** | 12, 17-18, 20, 25-26, 28-30 | Important but not blocking initial development |
|
||||
All 30 questions have been answered. ✅
|
||||
|
||||
---
|
||||
|
||||
@@ -106,4 +99,5 @@ Suggested priority for answering these questions:
|
||||
- [[05 - Barcode and QR Scanning]] — Scanning and hardware
|
||||
- [[06 - Module Integration]] — Cross-module workflows
|
||||
- [[07 - Technical Requirements]] — Technical decisions made and remaining
|
||||
- [[09 - Discovery Questions]] — Original discovery questionnaire with answers
|
||||
- [[00-DiscoveryQuestions]] — Round 1 answers
|
||||
- [[01-DiscoveryQuestions]] — Round 2 answers
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
tags:
|
||||
- eventkit
|
||||
- discovery-questions
|
||||
---
|
||||
|
||||
# Discovery Questions
|
||||
243
Test/EventKit/DiscoveryQuestions/01-DiscoveryQuestions.md
Normal file
243
Test/EventKit/DiscoveryQuestions/01-DiscoveryQuestions.md
Normal file
@@ -0,0 +1,243 @@
|
||||
---
|
||||
tags:
|
||||
- eventkit
|
||||
- discovery-questions
|
||||
---
|
||||
|
||||
# Discovery Questions — Round 2
|
||||
|
||||
Deeper questions building on your earlier answers. These target the remaining open items from [[08 - Open Questions]] and drill into implementation details.
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Scope & MVP
|
||||
|
||||
### 1. Primary Equipment Sectors
|
||||
|
||||
Which sectors should the MVP support first? Pick the top 2-3 that you'd want to demo:
|
||||
|
||||
- [x] Audio (PA systems, microphones, mixing desks)
|
||||
- [x] Lighting (moving heads, LED fixtures, dimmers)
|
||||
- [ ] Video (projectors, LED walls, cameras)
|
||||
- [ ] Staging (decks, legs, railings)
|
||||
- [x] Rigging (truss, motors, chains, shackles)
|
||||
- [x] Power distribution (distros, cables, generators)
|
||||
- [ ] Furniture (tables, chairs, bars, décor)
|
||||
- [ ] Other: \_\_\_
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 2. MVP Build Order
|
||||
|
||||
The natural order seems to be: Inventory + Scanning → Planning → CRM → Federation. Do you agree, or would you re-order?
|
||||
|
||||
> **Answer:** I agree with the order.
|
||||
|
||||
### 3. EventKit's Own Pricing Model
|
||||
|
||||
How will EventKit itself be offered to customers?
|
||||
|
||||
- [ ] Fully open source (self-hosted only, community support)
|
||||
- [x] Open core (free self-hosted, paid SaaS with premium features)
|
||||
- [ ] Paid licence (self-hosted with per-seat or per-instance licence)
|
||||
- [ ] SaaS only
|
||||
- [ ] Other: \_\_\_
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ Technical Architecture
|
||||
|
||||
### 4. Search
|
||||
|
||||
For asset/product search across potentially large inventories — start with PostgreSQL full-text search and add a dedicated engine later, or use something like Meilisearch from the start?
|
||||
|
||||
> **Answer:** Seems good to start with PostgreSQL full-text search and add a dedicated engine later.
|
||||
|
||||
### 5. File Storage
|
||||
|
||||
Where should uploaded files (photos, manuals, certificates) live?
|
||||
|
||||
- [ ] Local filesystem (simplest for self-hosted)
|
||||
- [ ] S3-compatible object storage (MinIO for self-hosted, AWS S3 for SaaS)
|
||||
- [x] Support both, configurable per deployment
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 6. Real-time Updates
|
||||
|
||||
Should the UI update in real-time (e.g. when another user scans an asset, dashboards update live)? If yes, gRPC server-streaming via ConnectRPC is the natural fit. Do you want this from the start?
|
||||
|
||||
> **Answer:** Not from the start, but it would be nice to have in the future.
|
||||
|
||||
### 7. Background Jobs
|
||||
|
||||
For tasks like sending emails, generating reports, processing federation messages — use Go's built-in concurrency (goroutines + internal queue), or an external broker like NATS or Redis?
|
||||
|
||||
> **Answer:** I want to deploy this on a Kubernetes cluster, so I would prefer to use an external broker like NATS or Redis.
|
||||
|
||||
---
|
||||
|
||||
## 📧 Communication & Integration
|
||||
|
||||
### 8. Email Integration
|
||||
|
||||
How should the CRM handle email?
|
||||
|
||||
- [ ] Just log emails manually (no integration)
|
||||
- [ ] SMTP sending only (send from within EventKit, no inbox)
|
||||
- [x] Full IMAP/SMTP integration (send and receive within EventKit)
|
||||
- [ ] Gmail/Outlook API integration
|
||||
- [ ] Start simple, expand later
|
||||
|
||||
> **Answer:** SMTP and IMAP integration would be nice to have utilizing features like sub-addressing to route emails to specific projects or clients.
|
||||
|
||||
### 9. Marketing Features
|
||||
|
||||
Should EventKit include any marketing tools (e.g. email campaigns, newsletters), or leave this to dedicated tools like Mailchimp?
|
||||
|
||||
> **Answer:** Not for now.
|
||||
|
||||
### 10. Calendar Sync
|
||||
|
||||
Should crew schedules and events sync with external calendars?
|
||||
|
||||
- [x] Google Calendar
|
||||
- [x] Outlook / Exchange
|
||||
- [x] CalDAV (generic)
|
||||
- [x] iCal export only (manual, no live sync)
|
||||
- [ ] Not needed for now
|
||||
|
||||
> **Answer:** CalDAV and iCal export only would be nice to have. And Google Calendar and Outlook / Exchange integration would be nice to have in the future.
|
||||
|
||||
---
|
||||
|
||||
## 📱 Scanning & Hardware
|
||||
|
||||
### 11. Primary Scanning Device
|
||||
|
||||
What should the primary scanning experience be?
|
||||
|
||||
- [ ] Phone camera only (lower cost of entry)
|
||||
- [ ] Bluetooth barcode scanner paired to phone/tablet (faster for bulk ops)
|
||||
- [x] Support both — phone camera as default, Bluetooth scanner as optional power-user feature
|
||||
- [ ] Dedicated rugged scanner devices
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 12. Label Printing
|
||||
|
||||
How should QR labels be produced?
|
||||
|
||||
- [ ] Generate PDF sheets — users print on any label printer (Avery sheets, etc.)
|
||||
- [ ] Direct integration with label printers (Brother QL, DYMO, Zebra)
|
||||
- [x] Both — PDF as default, direct printing as optional
|
||||
- [x] Not needed — users can print QR codes however they want
|
||||
|
||||
> **Answer:** Both — PDF as default, direct printing as optional. But not needed — users can print QR codes however they want.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Federation Details
|
||||
|
||||
### 13. Federation Versioning
|
||||
|
||||
When the federation protocol evolves (new fields, new RPCs) — should there be a formal version negotiation during handshake, or rely on Protobuf's built-in backward compat and just document breaking changes?
|
||||
|
||||
> **Answer:** Rely on Protobuf's built-in backward compat and just document breaking changes.
|
||||
|
||||
### 14. Dispute Resolution
|
||||
|
||||
When Company A returns equipment to Company B and they disagree about condition — what should EventKit provide?
|
||||
|
||||
- [ ] Photo evidence required at dispatch and return (comparison view)
|
||||
- [x] Timestamped condition logs with before/after
|
||||
- [ ] A formal dispute workflow (raise dispute, evidence, resolution)
|
||||
- [x] Just logging — disputes handled out-of-band
|
||||
- [ ] Some combination of above: \_\_\_
|
||||
|
||||
> **Answer:** Timestamped condition logs with before/after and just logging — disputes handled out-of-band.
|
||||
|
||||
---
|
||||
|
||||
## 🚛 Planning Details
|
||||
|
||||
### 15. Transport Planning
|
||||
|
||||
How advanced should transport logistics be?
|
||||
|
||||
- [ ] Basic: assign vehicles to events, simple load lists
|
||||
- [x] Intermediate: weight/volume calculations, truck pack lists
|
||||
- [x] Advanced: route optimisation, multi-stop planning, fuel tracking
|
||||
- [x] Start basic, extend later
|
||||
|
||||
> **Answer:** Intermediate: weight/volume calculations, truck pack lists and advanced: route optimisation, multi-stop planning, fuel tracking. But start basic, extend later.
|
||||
|
||||
### 16. Venue Database
|
||||
|
||||
Should venue data be:
|
||||
|
||||
- [ ] Local only — each instance manages its own venue records
|
||||
- [x] Federated — instances can share venue specs across the network
|
||||
- [x] Start local, federate later
|
||||
|
||||
> **Answer:** Federated — instances can share venue specs across the network. But start local, federate later.
|
||||
|
||||
---
|
||||
|
||||
## 🌍 Localisation & Compliance
|
||||
|
||||
### 17. Language Support
|
||||
|
||||
Should the UI be localised from the start? If so, which languages for MVP?
|
||||
|
||||
- [ ] English only for MVP
|
||||
- [x] English + German
|
||||
- [x] Full i18n framework from the start, translations added incrementally
|
||||
- [ ] Other: \_\_\_
|
||||
|
||||
> **Answer:** Full i18n framework from the start, translations added incrementally. But other: English + German to start of.
|
||||
|
||||
### 18. Currency & Tax
|
||||
|
||||
Which currency and tax regime should be supported first?
|
||||
|
||||
- [ ] EUR only (Austrian VAT rules)
|
||||
- [ ] EUR + GBP (UK VAT / Austrian VAT)
|
||||
- [x] Configurable from the start (currency, tax rates, tax ID formats)
|
||||
|
||||
> **Answer:** Configurable from the start (currency, tax rates, tax ID formats).
|
||||
|
||||
---
|
||||
|
||||
## 💡 UX & Design
|
||||
|
||||
### 19. Design Language
|
||||
|
||||
Do you have any preferences for the overall look and feel?
|
||||
|
||||
- [x] Clean and minimal (e.g. Linear, Notion)
|
||||
- [ ] Dashboard-heavy with data density (e.g. Grafana, Datadog)
|
||||
- [x] Modern and colourful (e.g. Figma, Notion)
|
||||
- [ ] Reference app/website for inspiration: \_\_\_
|
||||
|
||||
> **Answer:** Designed using shadcn ui components.
|
||||
|
||||
### 20. Dark Mode
|
||||
|
||||
Should dark mode be supported?
|
||||
|
||||
- [x] Yes, as default
|
||||
- [ ] Yes, as toggle (light default)
|
||||
- [ ] Not needed for MVP
|
||||
|
||||
> **Answer:** Yes, as default. Eventually, I would like to have a toggle to switch between other color schemes as well (e.g. high contrast mode).
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [[08 - Open Questions]] — Tracks which questions are still open
|
||||
- [[00-DiscoveryQuestions]] — Round 1 answers
|
||||
- [[07 - Technical Requirements]] — Decisions already made
|
||||
252
Test/EventKit/DiscoveryQuestions/02-DiscoveryQuestions.md
Normal file
252
Test/EventKit/DiscoveryQuestions/02-DiscoveryQuestions.md
Normal file
@@ -0,0 +1,252 @@
|
||||
---
|
||||
tags:
|
||||
- eventkit
|
||||
- discovery-questions
|
||||
---
|
||||
|
||||
# Discovery Questions — Round 3
|
||||
|
||||
Now that all high-level decisions are made, this round focuses on **implementation details**, **edge cases**, and **workflow specifics** that will shape the actual code.
|
||||
|
||||
---
|
||||
|
||||
## 📦 Inventory — Asset Model
|
||||
|
||||
### 1. Asset Numbering Scheme
|
||||
|
||||
How should human-readable asset IDs work? Examples:
|
||||
|
||||
- `SM58-001`, `SM58-002` — product prefix + sequential number
|
||||
- `A-2024-00001` — company prefix + year + sequence
|
||||
- User-defined per product category
|
||||
- No scheme — just UUID, users label however they want
|
||||
|
||||
> **Answer:** Product prefix + sequential number for human readable id, UUID for internal id
|
||||
|
||||
### 2. Asset Condition Tracking
|
||||
|
||||
How granular should condition states be?
|
||||
|
||||
- [x] Simple: Good / Damaged / Written Off
|
||||
- [ ] Detailed: New / Excellent / Good / Fair / Needs Repair / Damaged / Written Off
|
||||
- [x] User-definable condition states
|
||||
|
||||
> **Answer:** Simple: Good / Damaged / Written Off, but user-definable
|
||||
|
||||
### 3. Kit / Set Behaviour
|
||||
|
||||
When a Kit is added to a pull list, should:
|
||||
|
||||
- [ ] All items in the Kit be individually reserved (items tracked separately)
|
||||
- [x] The Kit be treated as a single unit (all-or-nothing)
|
||||
- [x] Both options — user chooses per Kit
|
||||
|
||||
> **Answer:** Both options — user chooses per Kit. Default option is all-or-nothing.
|
||||
|
||||
---
|
||||
|
||||
## 🗂️ Data & Schema
|
||||
|
||||
### 4. Soft Delete vs Hard Delete
|
||||
|
||||
Should deleted records be:
|
||||
|
||||
- [ ] Soft deleted (marked as deleted, hidden from UI, recoverable)
|
||||
- [ ] Hard deleted (permanently removed)
|
||||
- [x] Soft delete by default, hard delete with admin action after a retention period
|
||||
|
||||
> **Answer:** Soft delete by default, hard delete with admin action after a retention period.
|
||||
|
||||
### 5. Audit Trail Depth
|
||||
|
||||
How much should be logged?
|
||||
|
||||
- [ ] Just entity-level changes (who changed what, when)
|
||||
- [x] Field-level change history (old value → new value for every field)
|
||||
- [x] Full audit trail with field-level diff (like a Git history for every record)
|
||||
|
||||
> **Answer:** Field-level change history (old value → new value for every field). Full autit train in the future
|
||||
|
||||
### 6. Multi-Warehouse
|
||||
|
||||
Can a company have multiple warehouse locations?
|
||||
|
||||
- [x] Yes — from the start
|
||||
- [ ] No — single warehouse per instance for MVP
|
||||
- [ ] Yes, but only a "primary" + "secondary" distinction
|
||||
|
||||
> **Answer:** Yes — from the start
|
||||
|
||||
---
|
||||
|
||||
## 💰 Accounting & Finances
|
||||
|
||||
### 7. Tax Calculation
|
||||
|
||||
How should VAT/tax work?
|
||||
|
||||
- [ ] Single tax rate per instance (e.g. 20% Austrian USt for everything)
|
||||
- [ ] Per-product tax rates (some items exempt, some reduced rate)
|
||||
- [x] Per-product + per-customer tax logic (reverse charge for EU B2B)
|
||||
- [x] Configurable — I want flexibility
|
||||
|
||||
> **Answer:** Per-product + per-customer tax logic (reverse charge for EU B2B). Configurable — I want flexibility
|
||||
|
||||
### 8. Payment Methods
|
||||
|
||||
Which payment methods should be tracked?
|
||||
|
||||
- [x] Just record that a payment was made (manual)
|
||||
- [ ] Bank transfer details (IBAN, reference)
|
||||
- [ ] Online payments (Stripe, PayPal integration)
|
||||
- [ ] Start manual, add online payments later
|
||||
|
||||
> **Answer:** Just record that a payment was made (manual). Online Payment's arn't planned, but integration with Bank APIs for automatic payment tracking is planned.
|
||||
|
||||
### 9. Deposit / Advance Payments
|
||||
|
||||
Should the system support deposits (e.g. 50% upfront, 50% after event)?
|
||||
|
||||
- [ ] Yes — multiple partial payments against an invoice
|
||||
- [x] Yes — separate deposit invoice + final invoice
|
||||
- [ ] Not needed for MVP
|
||||
|
||||
> **Answer:** Yes — separate deposit invoice + final invoice
|
||||
|
||||
---
|
||||
|
||||
## 👥 Users & Permissions
|
||||
|
||||
### 10. Custom Roles
|
||||
|
||||
Beyond the predefined roles (Admin, Manager, Planner, Warehouse, Sales, Crew, Read-only), should admins be able to create fully custom roles with granular permissions?
|
||||
|
||||
- [x] Yes — from the start
|
||||
- [ ] No — predefined roles are enough for MVP
|
||||
- [ ] Predefined roles, but with optional per-role permission overrides
|
||||
|
||||
> **Answer:** Yes, User and Role Management is planned with Keycloak as an authentication provider. Roles should be managed in Keycloak, not in the application. The application should only read the roles from Keycloak. And granting Permissions to roles should also be handled in our application.
|
||||
|
||||
### 11. User Invitation Flow
|
||||
|
||||
How should new users be onboarded?
|
||||
|
||||
- [ ] Admin creates account, sends login credentials
|
||||
- [ ] Email invitation with sign-up link
|
||||
- [x] Both — admin creates, user sets own password via email link
|
||||
|
||||
> **Answer:** All users shoud be confirmed by an admin in some way. So the admin creates the user and sends an email invitation to the user. The user can then set his own password via email link.
|
||||
|
||||
### 12. SSO Providers
|
||||
|
||||
Which SSO providers should be supported for MVP?
|
||||
|
||||
- [ ] None — email/password only for MVP
|
||||
- [ ] Google OAuth
|
||||
- [ ] Microsoft / Azure AD
|
||||
- [x] Generic OIDC (works with Keycloak, Auth0, etc.)
|
||||
- [ ] All of the above
|
||||
|
||||
> **Answer:** Generic OIDC (works with Keycloak, Auth0, etc.)
|
||||
|
||||
---
|
||||
|
||||
## 📋 Quoting & Sales
|
||||
|
||||
### 13. Quote Versioning
|
||||
|
||||
When a quote is revised, should:
|
||||
|
||||
- [ ] The original be overwritten
|
||||
- [x] Each revision be saved as a separate version (v1, v2, v3...)
|
||||
- [ ] Revision history tracked but only latest version visible to client
|
||||
|
||||
> **Answer:** Each revision be saved as a separate version (v1, v2, v3...)
|
||||
|
||||
### 14. Quote → Invoice Flow
|
||||
|
||||
How should a confirmed quote become an invoice?
|
||||
|
||||
- [ ] Auto-generate invoice from quote (one click)
|
||||
- [x] Copy quote to invoice draft for manual adjustment
|
||||
- [ ] Both options
|
||||
|
||||
> **Answer:** Copy quote to invoice draft for manual adjustment
|
||||
|
||||
### 15. Client Approval Workflow
|
||||
|
||||
For the client portal, when a client approves a quote:
|
||||
|
||||
- [ ] Instant approval — quote status changes immediately
|
||||
- [x] Approval with e-signature (legally binding)
|
||||
- [x] Approval with comment / conditions
|
||||
- [x] Simple approval for MVP, e-signature later
|
||||
|
||||
> **Answer:** Approval with e-signature (legally binding) and comments / conditions.
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Event Workflow
|
||||
|
||||
### 16. Event Phases
|
||||
|
||||
Should events have customisable phases, or a fixed lifecycle?
|
||||
|
||||
- [ ] Fixed: Draft → Confirmed → In Progress → Completed → Closed
|
||||
- [x] Customisable phases per event type
|
||||
- [ ] Fixed lifecycle with optional sub-statuses
|
||||
|
||||
> **Answer:** Customisable phases per event type, but default phases should be provided. Draft - Confirmed - In Progress - Completed - Closed
|
||||
|
||||
### 17. Recurring Events
|
||||
|
||||
Should recurring events be supported (e.g. weekly residency at same venue)?
|
||||
|
||||
- [x] Yes — template-based with auto-generation
|
||||
- [x] Yes — clone previous event
|
||||
- [ ] Not needed for MVP
|
||||
|
||||
> **Answer:** Yes — template-based with auto-generation and clone previous event
|
||||
|
||||
### 18. Projects / Multi-Day Events
|
||||
|
||||
Should a "Project" (grouping multiple related events) be a first-class entity?
|
||||
|
||||
- [x] Yes — project contains multiple events, shared budget/client
|
||||
- [x] No — events are standalone, just tag them for grouping
|
||||
- [x] Simple grouping for MVP, full project entity later
|
||||
|
||||
> **Answer:** Events are standalone, but can be grouped in projects. Projects can have multiple events, shared budget/client. Simple grouping for MVP, full project entity later.
|
||||
|
||||
---
|
||||
|
||||
## 🔐 Security & Auth
|
||||
|
||||
### 19. Session Management
|
||||
|
||||
How should user sessions work?
|
||||
|
||||
- [ ] JWT with short expiry + refresh token
|
||||
- [ ] Session-based (server-side session store)
|
||||
- [ ] JWT for API, session for web UI
|
||||
|
||||
> **Answer:** Handled by Keycloak
|
||||
|
||||
### 20. API Key Scoping
|
||||
|
||||
Should API keys be scoped to specific permissions/modules?
|
||||
|
||||
- [x] Yes — granular scopes (e.g. `inventory:read`, `planning:write`)
|
||||
- [ ] No — API keys get full access of the user who created them
|
||||
- [x] Start simple (full access), add scopes later
|
||||
|
||||
> **Answer:** Yes — granular scopes (e.g. `inventory:read`, `planning:write`). Start simple (full access), add scopes later.
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [[08 - Open Questions]] — All 30 original questions now answered
|
||||
- [[00-DiscoveryQuestions]] — Round 1 answers
|
||||
- [[01-DiscoveryQuestions]] — Round 2 answers
|
||||
- [[07 - Technical Requirements]] — Technical decisions made
|
||||
254
Test/EventKit/DiscoveryQuestions/03-DiscoveryQuestions.md
Normal file
254
Test/EventKit/DiscoveryQuestions/03-DiscoveryQuestions.md
Normal file
@@ -0,0 +1,254 @@
|
||||
---
|
||||
tags:
|
||||
- eventkit
|
||||
- discovery-questions
|
||||
---
|
||||
|
||||
# Discovery Questions — Round 4
|
||||
|
||||
We're now deep into implementation territory. This round focuses on **UI/UX workflows**, **edge cases**, **integrations**, and **operational details**.
|
||||
|
||||
---
|
||||
|
||||
## 🖥️ UI & Workflows
|
||||
|
||||
### 1. Dashboard — What's Most Important?
|
||||
|
||||
What should the main dashboard show when a user logs in? Pick your top priorities:
|
||||
|
||||
- [x] Upcoming events (next 7/14/30 days)
|
||||
- [x] Equipment utilisation overview
|
||||
- [x] Open quotes / pending approvals
|
||||
- [x] Overdue returns / missing equipment
|
||||
- [x] Revenue summary
|
||||
- [x] Low-stock consumable alerts
|
||||
- [x] Crew availability overview
|
||||
- [x] Recent activity feed
|
||||
- [ ] Other: \_\_\_
|
||||
|
||||
> **Answer:** Configurable dashboard per user. Multiple with simple view switching
|
||||
|
||||
### 2. Navigation Structure
|
||||
|
||||
How should the main app be structured?
|
||||
|
||||
- [ ] Sidebar navigation with module sections (Inventory, Planning, CRM, etc.)
|
||||
- [ ] Top navigation bar with dropdowns
|
||||
- [x] Sidebar + command palette (Cmd+K) for quick navigation
|
||||
- [ ] Other preference: \_\_\_
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 3. Bulk Operations
|
||||
|
||||
Which bulk operations are critical for daily work?
|
||||
|
||||
- [ ] Bulk status change (e.g. mark 50 assets as "In Service")
|
||||
- [ ] Bulk assign to event (select multiple assets → assign to pull list)
|
||||
- [ ] Bulk print labels (select assets → generate label sheet)
|
||||
- [ ] Bulk import (CSV upload for assets, contacts, products)
|
||||
- [ ] Bulk export (export filtered views to CSV/Excel)
|
||||
- [x] All of the above
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## 📊 Reporting & Analytics
|
||||
|
||||
### 4. Report Output Formats
|
||||
|
||||
How should reports be delivered?
|
||||
|
||||
- [ ] In-app only (charts and tables on screen)
|
||||
- [ ] PDF export
|
||||
- [ ] CSV/Excel export
|
||||
- [ ] Scheduled email delivery (e.g. weekly utilisation report)
|
||||
- [x] All of the above
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 5. Custom Reports
|
||||
|
||||
Should users be able to build custom reports, or are predefined reports enough for MVP?
|
||||
|
||||
- [ ] Predefined reports only
|
||||
- [x] Predefined + simple filters/grouping
|
||||
- [x] Full custom report builder (drag-and-drop fields, custom calculations)
|
||||
- [x] Predefined for MVP, custom builder later
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Integrations & Webhooks
|
||||
|
||||
### 6. Webhook Events
|
||||
|
||||
Which events should trigger outbound webhooks? Pick the critical ones:
|
||||
|
||||
- [x] Asset status changed (checked out, returned, damaged)
|
||||
- [x] Event status changed (confirmed, completed, cancelled)
|
||||
- [x] Quote approved / rejected by client
|
||||
- [x] Invoice paid
|
||||
- [x] Low stock alert
|
||||
- [x] Federation events (sub-hire request, asset transfer)
|
||||
- [x] All entity changes (CRUD on any major entity)
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 7. Bank API Integration
|
||||
|
||||
You mentioned automatic payment tracking via bank APIs. Any preferences?
|
||||
|
||||
- [x] Open Banking APIs (PSD2 — European standard)
|
||||
- [ ] Specific bank: \_\_\_
|
||||
- [x] Generic bank statement import (CSV/MT940)
|
||||
- [x] Not sure yet — decide later
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## 📦 Warehouse Operations
|
||||
|
||||
### 8. Stocktake Process
|
||||
|
||||
How should stocktakes work?
|
||||
|
||||
- [x] Full stocktake — scan everything, compare against expected inventory
|
||||
- [x] Partial/zone stocktake — scan specific areas/shelves
|
||||
- [x] Continuous rolling stocktake — scan a section each day
|
||||
- [x] All approaches
|
||||
|
||||
> **Answer:** User selectable
|
||||
|
||||
### 9. Prep Workflow
|
||||
|
||||
When preparing equipment for an event, should there be a formal "prep checklist"?
|
||||
|
||||
- [x] Yes — per-product checklist (e.g. "test power", "check firmware", "include accessories")
|
||||
- [x] No — just scan to check out, the pull list is the checklist
|
||||
- [x] Optional checklists — define per product category if wanted
|
||||
|
||||
> **Answer:** User selectable.
|
||||
|
||||
### 10. Damage Reporting
|
||||
|
||||
When equipment returns damaged, what should happen?
|
||||
|
||||
- [x] Flag asset as damaged, create maintenance task automatically
|
||||
- [x] Flag + photo evidence required
|
||||
- [x] Flag + photo + cost estimate for client charge-back
|
||||
- [x] Configurable workflow per damage severity
|
||||
|
||||
> **Answer:** User selectable.
|
||||
|
||||
---
|
||||
|
||||
## 🌐 Federation — Edge Cases
|
||||
|
||||
### 11. Federation Downtime
|
||||
|
||||
When a federated partner's instance is offline, what should happen to pending requests?
|
||||
|
||||
- [x] Queue in outbox, retry automatically when partner comes back
|
||||
- [x] Queue + notify admin after X hours of failed retries
|
||||
- [x] Fail immediately with manual retry option
|
||||
|
||||
> **Answer:** User selectable.
|
||||
|
||||
### 12. Federation Data Sync
|
||||
|
||||
How much data should be visible about a partner's inventory?
|
||||
|
||||
- [ ] Nothing — they respond to availability queries in real-time
|
||||
- [ ] Cached summary (category counts, general availability)
|
||||
- [ ] Product catalogue shared (but not individual asset details)
|
||||
- [x] Configurable per trust level
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## ⚡ Performance & Infrastructure
|
||||
|
||||
### 13. Caching Strategy
|
||||
|
||||
For a Kubernetes deployment, what caching layer do you prefer?
|
||||
|
||||
- [x] Redis (already considering for background jobs — reuse for caching)
|
||||
- [ ] In-memory only (Go's built-in caching, no external dependency)
|
||||
- [ ] No caching for MVP — optimise later
|
||||
|
||||
> **Answer:** Redis
|
||||
|
||||
### 14. Database Migrations
|
||||
|
||||
How should schema migrations be handled?
|
||||
|
||||
- [ ] Automatic on startup (app runs migrations before serving)
|
||||
- [ ] Separate migration step (run migrations explicitly before deploying new version)
|
||||
- [x] Both — auto for dev, explicit for production
|
||||
|
||||
> **Answer:** Both — auto for dev, explicit for production
|
||||
|
||||
---
|
||||
|
||||
## 📄 Documents & Branding
|
||||
|
||||
### 15. Document Branding
|
||||
|
||||
For generated PDFs (quotes, invoices, pull lists), how customisable should branding be?
|
||||
|
||||
- [x] Basic — company logo + name + colours
|
||||
- [x] Full template customisation (header, footer, fonts, layout)
|
||||
- [x] HTML/CSS template engine (users provide their own templates)
|
||||
- [x] Basic for MVP, full templates later
|
||||
|
||||
> **Answer:** User selectable.
|
||||
|
||||
### 16. Document Numbering
|
||||
|
||||
How should quotes and invoices be numbered?
|
||||
|
||||
- [ ] Sequential: `INV-0001`, `INV-0002`
|
||||
- [ ] Year-based: `INV-2026-0001`
|
||||
- [x] Configurable prefix + sequence per document type
|
||||
- [ ] Other: \_\_\_
|
||||
|
||||
> **Answer:** Configurable prefix + sequence per document type.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Testing & Quality
|
||||
|
||||
### 17. Testing Strategy
|
||||
|
||||
For development, which testing approach do you prefer?
|
||||
|
||||
- [ ] Unit tests + integration tests (standard)
|
||||
- [ ] Unit + integration + E2E browser tests (Playwright/Cypress)
|
||||
- [ ] Heavy emphasis on integration tests with testcontainers
|
||||
- [x] Whatever gets us shipping fastest with confidence
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 18. Staging Environment
|
||||
|
||||
Should there be a formal staging/preview environment?
|
||||
|
||||
- [ ] Yes — dedicated staging with sample data
|
||||
- [x] Yes — ephemeral preview environments per PR (Kubernetes-native)
|
||||
- [x] No — local dev + production is enough for now
|
||||
|
||||
> **Answer:** Yes — ephemeral preview environments per PR (Kubernetes-native) not with priority
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [[00-DiscoveryQuestions]] — Round 1 answers
|
||||
- [[01-DiscoveryQuestions]] — Round 2 answers
|
||||
- [[02-DiscoveryQuestions]] — Round 3 answers
|
||||
- [[07 - Technical Requirements]] — Technical decisions made
|
||||
216
Test/EventKit/DiscoveryQuestions/04-DiscoveryQuestions.md
Normal file
216
Test/EventKit/DiscoveryQuestions/04-DiscoveryQuestions.md
Normal file
@@ -0,0 +1,216 @@
|
||||
---
|
||||
tags:
|
||||
- eventkit
|
||||
- discovery-questions
|
||||
---
|
||||
|
||||
# Discovery Questions — Round 5
|
||||
|
||||
We're narrowing in on the final implementation details. This round focuses on **data architecture**, **notification specifics**, **multi-tenancy edge cases**, and **operational workflows**.
|
||||
|
||||
---
|
||||
|
||||
## 🗄️ Data Architecture
|
||||
|
||||
### 1. Tenant Isolation (SaaS Mode)
|
||||
|
||||
For the shared-DB multi-tenancy with RLS — should tenants be able to:
|
||||
|
||||
- [ ] Share nothing (complete isolation, even separate schemas)
|
||||
- [ ] Share reference data (e.g. common product catalogues, venue databases)
|
||||
- [ ] Share everything except user data (federated approach within SaaS)
|
||||
- [x] Complete isolation via RLS — no cross-tenant data ever
|
||||
|
||||
> **Answer:** Federate using Federation Architecture
|
||||
|
||||
### 2. Data Retention Policy
|
||||
|
||||
How long should data be kept?
|
||||
|
||||
- [ ] Indefinitely (never auto-purge)
|
||||
- [x] Configurable retention per entity type (e.g. events: 5 years, audit logs: 7 years)
|
||||
- [ ] Configurable globally (e.g. "keep everything for 10 years")
|
||||
- [x] Follow Austrian/EU legal requirements (varies by document type)
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 3. File Versioning
|
||||
|
||||
When a file attached to an asset is updated (e.g. new manual version):
|
||||
|
||||
- [ ] Overwrite the old file
|
||||
- [x] Keep version history (v1, v2, v3)
|
||||
- [ ] Keep version history with diff/comparison view
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## 🔔 Notifications
|
||||
|
||||
### 4. Notification Preferences
|
||||
|
||||
Should users control which notifications they receive?
|
||||
|
||||
- [x] Yes — granular per-event-type toggle (e.g. "notify me about overdue returns but not new quotes")
|
||||
- [ ] Yes — but only broad categories (e.g. "inventory alerts", "CRM updates")
|
||||
- [ ] No — admins configure notification rules globally
|
||||
|
||||
> **Answer:** Future feature
|
||||
|
||||
### 5. Email Templates
|
||||
|
||||
Should notification emails be customisable?
|
||||
|
||||
- [ ] Fixed templates (EventKit branding)
|
||||
- [ ] Tenant-branded templates (company logo, colours)
|
||||
- [ ] Fully customisable HTML templates per notification type
|
||||
- [x] Tenant-branded for MVP, full customisation later
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## 🏢 Multi-Tenancy & Operations
|
||||
|
||||
### 6. Tenant Onboarding
|
||||
|
||||
For SaaS, how should new tenants be set up?
|
||||
|
||||
- [ ] Self-service sign-up (create account → start using immediately)
|
||||
- [x] Self-service with admin approval before activation
|
||||
- [x] Manual onboarding (admin creates tenant)
|
||||
- [ ] Self-service for MVP, approval flow later
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 7. Tenant Data Export
|
||||
|
||||
Should tenants be able to export all their data (GDPR Article 20)?
|
||||
|
||||
- [x] Yes — full data export in JSON/CSV at any time
|
||||
- [x] Yes — full export + ability to delete all data (right to be forgotten)
|
||||
- [ ] Admin-triggered export only
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 8. Tenant Limits / Quotas
|
||||
|
||||
Should the SaaS tier enforce limits?
|
||||
|
||||
- [ ] No limits (fair use policy)
|
||||
- [x] Soft limits with warnings (e.g. "you have 10,000 assets, consider upgrading")
|
||||
- [ ] Hard limits per plan (e.g. free: 100 assets, pro: 10,000, enterprise: unlimited)
|
||||
- [x] Decide pricing tiers later
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## 📋 Operational Workflows
|
||||
|
||||
### 9. Return Inspection Detail
|
||||
|
||||
When equipment returns from an event, how detailed should the inspection be?
|
||||
|
||||
- [ ] Simple: scan asset → mark as returned → done
|
||||
- [ ] Standard: scan → condition check (good/damaged) → shelve
|
||||
- [x] Detailed: scan → per-item checklist → photos → condition update → cleaning queue → shelve
|
||||
- [ ] Configurable per product category
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 10. Consumable Allocation
|
||||
|
||||
How should consumables be tracked per event?
|
||||
|
||||
- [x] Estimated at planning stage, actual recorded after event
|
||||
- [ ] Deducted from stock when event is confirmed
|
||||
- [x] Deducted when physically dispatched (scan-based)
|
||||
- [ ] Flexible — user chooses per consumable type
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 11. Asset Reservation Rules
|
||||
|
||||
When equipment is reserved for an event, should:
|
||||
|
||||
- [ ] Hard reservation — cannot be booked for anything else in that window
|
||||
- [ ] Soft reservation — can be overridden with manager approval
|
||||
- [x] Configurable per event priority level
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## 🔌 API & Developer Experience
|
||||
|
||||
### 12. API Documentation
|
||||
|
||||
How should the API be documented?
|
||||
|
||||
- [x] Auto-generated from Protobuf definitions (buf.build registry)
|
||||
- [ ] OpenAPI/Swagger (via ConnectRPC's REST mapping)
|
||||
- [ ] Both Protobuf docs + OpenAPI
|
||||
- [x] Minimal docs for now — just the .proto files
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 13. Plugin / Extension System
|
||||
|
||||
Should EventKit support third-party plugins or extensions?
|
||||
|
||||
- [ ] Yes — from the start (plugin API, hooks, event system)
|
||||
- [x] Yes — but later (design for it now, implement later)
|
||||
- [ ] No — keep it simple, extensibility via webhooks and API
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 14. Import from Other Systems
|
||||
|
||||
What systems might users migrate from?
|
||||
|
||||
- [x] Spreadsheets (Excel/Google Sheets)
|
||||
- [x] Rentman
|
||||
- [x] Flex Rental Solutions
|
||||
- [x] Current RMS
|
||||
- [x] EasyJob
|
||||
- [x] Custom / in-house systems
|
||||
- [x] Don't know yet — generic CSV import is enough for now
|
||||
|
||||
> **Answer:** All of the above, but optoinal feature for sumetimes in the future.
|
||||
|
||||
---
|
||||
|
||||
## 🎨 UI Detail
|
||||
|
||||
### 15. Table vs Card Views
|
||||
|
||||
For list pages (assets, events, contacts), should there be:
|
||||
|
||||
- [ ] Table view only (data-dense, sortable columns)
|
||||
- [ ] Card view only (visual, thumbnail-based)
|
||||
- [ ] Both — user toggles between table and card view
|
||||
- [x] Table default, card view for specific entities (e.g. assets with photos)
|
||||
|
||||
> **Answer:**
|
||||
|
||||
### 16. Keyboard Shortcuts
|
||||
|
||||
Beyond Cmd+K, should there be keyboard shortcuts for common actions?
|
||||
|
||||
- [x] Yes — full keyboard navigation (like Linear)
|
||||
- [ ] Basic shortcuts only (Cmd+N new, Cmd+S save, etc.)
|
||||
- [ ] Not needed for MVP
|
||||
|
||||
> **Answer:**
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [[00-DiscoveryQuestions]] — Round 1 answers
|
||||
- [[01-DiscoveryQuestions]] — Round 2 answers
|
||||
- [[02-DiscoveryQuestions]] — Round 3 answers
|
||||
- [[03-DiscoveryQuestions]] — Round 4 answers
|
||||
- [[07 - Technical Requirements]] — Technical decisions made
|
||||
Reference in New Issue
Block a user