vault backup: 2026-02-26 22:57:07
This commit is contained in:
20
Test/.obsidian/workspace.json
vendored
20
Test/.obsidian/workspace.json
vendored
@@ -13,12 +13,12 @@
|
|||||||
"state": {
|
"state": {
|
||||||
"type": "markdown",
|
"type": "markdown",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "EventKit/00 - System Overview.md",
|
"file": "EventKit/09 - Discovery Questions.md",
|
||||||
"mode": "source",
|
"mode": "source",
|
||||||
"source": false
|
"source": false
|
||||||
},
|
},
|
||||||
"icon": "lucide-file",
|
"icon": "lucide-file",
|
||||||
"title": "00 - System Overview"
|
"title": "09 - Discovery Questions"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
]
|
]
|
||||||
@@ -74,8 +74,7 @@
|
|||||||
"title": "Bookmarks"
|
"title": "Bookmarks"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
],
|
]
|
||||||
"currentTab": 1
|
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"direction": "horizontal",
|
"direction": "horizontal",
|
||||||
@@ -95,7 +94,7 @@
|
|||||||
"state": {
|
"state": {
|
||||||
"type": "backlink",
|
"type": "backlink",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "EventKit/00 - System Overview.md",
|
"file": "EventKit/09 - Discovery Questions.md",
|
||||||
"collapseAll": false,
|
"collapseAll": false,
|
||||||
"extraContext": false,
|
"extraContext": false,
|
||||||
"sortOrder": "alphabetical",
|
"sortOrder": "alphabetical",
|
||||||
@@ -105,7 +104,7 @@
|
|||||||
"unlinkedCollapsed": true
|
"unlinkedCollapsed": true
|
||||||
},
|
},
|
||||||
"icon": "links-coming-in",
|
"icon": "links-coming-in",
|
||||||
"title": "Backlinks for 00 - System Overview"
|
"title": "Backlinks for 09 - Discovery Questions"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
@@ -157,13 +156,13 @@
|
|||||||
"state": {
|
"state": {
|
||||||
"type": "outline",
|
"type": "outline",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "EventKit/00 - System Overview.md",
|
"file": "EventKit/09 - Discovery Questions.md",
|
||||||
"followCursor": false,
|
"followCursor": false,
|
||||||
"showSearch": false,
|
"showSearch": false,
|
||||||
"searchQuery": ""
|
"searchQuery": ""
|
||||||
},
|
},
|
||||||
"icon": "lucide-list",
|
"icon": "lucide-list",
|
||||||
"title": "Outline of 00 - System Overview"
|
"title": "Outline of 09 - Discovery Questions"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
@@ -195,14 +194,15 @@
|
|||||||
"obsidian-git:Open Git source control": false
|
"obsidian-git:Open Git source control": false
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"active": "f57ec71f88c52fc2",
|
"active": "33bf02b914739c8c",
|
||||||
"lastOpenFiles": [
|
"lastOpenFiles": [
|
||||||
|
"EventKit/00 - System Overview.md",
|
||||||
|
"EventKit/09 - Discovery Questions.md",
|
||||||
"EventKit/08 - Open Questions.md",
|
"EventKit/08 - Open Questions.md",
|
||||||
"EventKit/04 - Federation Architecture.md",
|
"EventKit/04 - Federation Architecture.md",
|
||||||
"EventKit/03 - CRM Module.md",
|
"EventKit/03 - CRM Module.md",
|
||||||
"EventKit/02 - Planning Module.md",
|
"EventKit/02 - Planning Module.md",
|
||||||
"EventKit/01 - Inventory Management.md",
|
"EventKit/01 - Inventory Management.md",
|
||||||
"EventKit/00 - System Overview.md",
|
|
||||||
"create a link.md",
|
"create a link.md",
|
||||||
"Welcome.md",
|
"Welcome.md",
|
||||||
"Untitled 1.base",
|
"Untitled 1.base",
|
||||||
|
|||||||
@@ -91,6 +91,7 @@ stateDiagram-v2
|
|||||||
| Feature | Description |
|
| Feature | Description |
|
||||||
| --------------------------- | --------------------------------------------------------------------------------------------------- |
|
| --------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||||
| Individual asset tracking | Each asset has a UUID, serial number, and QR code |
|
| Individual asset tracking | Each asset has a UUID, serial number, and QR code |
|
||||||
|
| 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 |
|
| Purchase & financial data | Purchase date, supplier, cost, insurance value, depreciation |
|
||||||
| Documentation | Photos, manuals, spec sheets, certificates attached per asset |
|
| Documentation | Photos, manuals, spec sheets, certificates attached per asset |
|
||||||
| Firmware / version tracking | Track software/firmware versions on digital equipment |
|
| Firmware / version tracking | Track software/firmware versions on digital equipment |
|
||||||
@@ -144,24 +145,27 @@ stateDiagram-v2
|
|||||||
|
|
||||||
### Consumables
|
### Consumables
|
||||||
|
|
||||||
| Feature | Description |
|
| Feature | Description |
|
||||||
| -------------------------- | ------------------------------------------------------- |
|
| ------------------------- | --------------------------------------------------------------------------------- |
|
||||||
| Stock level tracking | Current quantity per consumable product |
|
| Stock level tracking | Current quantity per consumable product |
|
||||||
| Reorder thresholds | Automated alerts when stock falls below a defined level |
|
| Reorder thresholds | Automated alerts when stock falls below a defined level |
|
||||||
| Par levels | Target stock levels to maintain |
|
| Par levels | Target stock levels to maintain |
|
||||||
| Consumption per event | Track how much of each consumable was used per event |
|
| Consumption per event | Track how much of each consumable was used per event |
|
||||||
| Purchase order integration | Generate POs to restock consumables |
|
| Purchase order generation | Generate POs to restock consumables — requires manual confirmation before sending |
|
||||||
|
|
||||||
### Maintenance & Testing
|
### Maintenance & Testing
|
||||||
|
|
||||||
| Feature | Description |
|
| Feature | Description |
|
||||||
| -------------------------- | ------------------------------------------------------------------------ |
|
| -------------------------- | --------------------------------------------------------------------------------------------- |
|
||||||
| PAT testing records | Track Portable Appliance Testing dates and results per asset |
|
| PAT testing records | Track Portable Appliance Testing dates and results per asset |
|
||||||
| Service schedules | Define recurring maintenance intervals (e.g. every 12 months) |
|
| ÖVE/ÖNORM compliance | Austrian electrical safety standards (ÖVE/ÖNORM E 8701) tracking |
|
||||||
| Next-service-due reminders | Automated alerts for upcoming maintenance |
|
| CE marking verification | Track CE conformity declarations for EU compliance |
|
||||||
| Repair history | Full repair log per asset — what was done, cost, duration |
|
| Service schedules | Define recurring maintenance intervals (e.g. every 12 months) |
|
||||||
| Maintenance cost tracking | Aggregate repair costs per asset for ROI analysis |
|
| Next-service-due reminders | Automated alerts for upcoming maintenance |
|
||||||
| Certification tracking | Track certifications with expiry dates (rigging gear, fire safety, etc.) |
|
| Repair history | Full repair log per asset — what was done, cost, duration |
|
||||||
|
| Maintenance cost tracking | Aggregate repair costs per asset for ROI analysis |
|
||||||
|
| Certification tracking | Track certifications with expiry dates (rigging gear, fire safety, etc.) |
|
||||||
|
| Dispatch gating | Prevent check-out of assets with expired tests, overdue maintenance, or lapsed certifications |
|
||||||
|
|
||||||
### Reporting & Analytics
|
### Reporting & Analytics
|
||||||
|
|
||||||
|
|||||||
@@ -118,10 +118,21 @@ stateDiagram-v2
|
|||||||
| Skill matching | Filter available crew by required skills/certifications |
|
| Skill matching | Filter available crew by required skills/certifications |
|
||||||
| Crew costs per event | Track day rates, overtime, expenses per crew member per event |
|
| Crew costs per event | Track day rates, overtime, expenses per crew member per event |
|
||||||
| Shift scheduling | Define shift start/end times per crew member per event day |
|
| Shift scheduling | Define shift start/end times per crew member per event day |
|
||||||
| Crew notifications | Notify assigned crew via email/SMS with event details |
|
| Crew notifications | Notify assigned crew via email / push with event details |
|
||||||
| Freelancer vs. in-house | Distinguish between employed staff and freelance contractors |
|
| Freelancer vs. in-house | Distinguish between employed staff and freelance contractors |
|
||||||
| Timesheet capture | Record actual hours worked for payroll/invoicing |
|
| Timesheet capture | Record actual hours worked for payroll/invoicing |
|
||||||
|
|
||||||
|
#### Crew Portal
|
||||||
|
|
||||||
|
Crew members can log in (web or mobile app) to:
|
||||||
|
|
||||||
|
| Feature | Description |
|
||||||
|
| ----------------------- | ------------------------------------------- |
|
||||||
|
| View assigned events | See all upcoming events they're assigned to |
|
||||||
|
| Confirm availability | Accept or decline event assignments |
|
||||||
|
| View event details | Access schedule, venue info, and call times |
|
||||||
|
| Update personal profile | Skills, certifications, contact details |
|
||||||
|
|
||||||
### Transport & Logistics
|
### Transport & Logistics
|
||||||
|
|
||||||
| Feature | Description |
|
| Feature | Description |
|
||||||
|
|||||||
@@ -108,16 +108,21 @@ Stages are **fully customisable** per instance. Multiple pipelines can exist (e.
|
|||||||
| Meeting scheduling | Schedule and track meetings |
|
| Meeting scheduling | Schedule and track meetings |
|
||||||
| Activity timeline | Unified feed of all interactions per contact/company/deal |
|
| Activity timeline | Unified feed of all interactions per contact/company/deal |
|
||||||
|
|
||||||
### Invoicing (Basic)
|
### Invoicing & Accounting (Integrated)
|
||||||
|
|
||||||
|
EventKit includes **built-in accounting features** as the primary financial workflow. External integrations (Xero, QuickBooks) are available but secondary.
|
||||||
|
|
||||||
| Feature | Description |
|
| Feature | Description |
|
||||||
| ----------------------- | ------------------------------------------------------- |
|
| ----------------------- | ------------------------------------------------------- |
|
||||||
| Invoice generation | Generate invoices from confirmed quotes or events |
|
| Invoice generation | Generate invoices from confirmed quotes or events |
|
||||||
| Line item detail | Equipment, crew, transport, consumables, sub-hire costs |
|
| Line item detail | Equipment, crew, transport, consumables, sub-hire costs |
|
||||||
| Invoice status tracking | Draft → Sent → Paid → Overdue |
|
| Invoice status tracking | Draft → Sent → Paid → Overdue |
|
||||||
| Payment tracking | Record payments received |
|
| Payment tracking | Record payments received, partial payments, deposits |
|
||||||
| Accounting integration | Export to or sync with Xero, QuickBooks, etc. |
|
| Purchase orders | Generate and track POs for consumables and sub-hire |
|
||||||
| Credit notes | Issue credit for cancellations or adjustments |
|
| Credit notes | Issue credit for cancellations or adjustments |
|
||||||
|
| Financial reporting | Revenue, expenses, profit/loss per event and period |
|
||||||
|
| Xero integration | Optional sync — invoices, payments, contacts |
|
||||||
|
| QuickBooks integration | Optional sync — invoices, payments, contacts |
|
||||||
|
|
||||||
### Reporting
|
### Reporting
|
||||||
|
|
||||||
@@ -145,6 +150,30 @@ Unlike generic CRMs, the EventKit CRM understands:
|
|||||||
| **Equipment preferences** | Record client brand/model preferences for future quotes |
|
| **Equipment preferences** | Record client brand/model preferences for future quotes |
|
||||||
| **Event types** | Categorise deals by event type (corporate, concert, wedding, festival) |
|
| **Event types** | Categorise deals by event type (corporate, concert, wedding, festival) |
|
||||||
|
|
||||||
|
### Client Portal
|
||||||
|
|
||||||
|
Clients can log in to a self-service portal:
|
||||||
|
|
||||||
|
| Feature | Description |
|
||||||
|
| ----------------- | ---------------------------------------------- |
|
||||||
|
| View quotes | See all quotes sent to them |
|
||||||
|
| Approve / deny | Accept or reject quotes with comments |
|
||||||
|
| Event status | Track active events and their current phase |
|
||||||
|
| Download invoices | Access and download invoices and receipts |
|
||||||
|
| Communication | Respond to messages without leaving the portal |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Equipment Pricing
|
||||||
|
|
||||||
|
| Pricing Model | Description |
|
||||||
|
| ------------------ | -------------------------------------------------------------------- |
|
||||||
|
| **Per-day rate** | Standard hire rate per day — used for equipment rental |
|
||||||
|
| **Per-event rate** | Flat rate per event — used for service-oriented pricing |
|
||||||
|
| **Tiered rates** | Discounted rates for longer hires (e.g. weekly, monthly) |
|
||||||
|
| **Seasonal rates** | Different pricing for peak vs. off-season (future enhancement) |
|
||||||
|
| **Weekend rates** | Different pricing for weekday vs. weekend hires (future enhancement) |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Related Documentation
|
## Related Documentation
|
||||||
|
|||||||
@@ -205,6 +205,27 @@ Companies can grant different permission levels to each partner:
|
|||||||
|
|
||||||
Trust levels can be **changed or revoked** at any time by either party.
|
Trust levels can be **changed or revoked** at any time by either party.
|
||||||
|
|
||||||
|
### Sub-hire Pricing
|
||||||
|
|
||||||
|
Sub-hire prices are **negotiated per-transaction** out-of-band (phone, email). The federation protocol tracks equipment movement, not pricing. Each instance records its own costs:
|
||||||
|
|
||||||
|
| Party | Records |
|
||||||
|
| ------------ | -------------------------------------------------------------- |
|
||||||
|
| **Lender** | Revenue from sub-hire, return deadline, condition at dispatch |
|
||||||
|
| **Borrower** | Day rate / agreed cost, event allocation, condition at receipt |
|
||||||
|
|
||||||
|
### Asset Ownership Transfer
|
||||||
|
|
||||||
|
Assets can be **permanently transferred** between instances (e.g. selling equipment to a partner):
|
||||||
|
|
||||||
|
| Step | Action |
|
||||||
|
| ---- | --------------------------------------------------------------------- |
|
||||||
|
| 1 | Seller initiates transfer request via federation |
|
||||||
|
| 2 | Buyer accepts — asset data (history, maintenance) transferred |
|
||||||
|
| 3 | Asset UUID remains the same — QR code URL updated to new instance |
|
||||||
|
| 4 | Seller's instance marks asset as "Transferred" (end of local history) |
|
||||||
|
| 5 | Buyer's instance creates asset with full imported history |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Global Asset Identity
|
## Global Asset Identity
|
||||||
|
|||||||
@@ -2,6 +2,7 @@
|
|||||||
tags:
|
tags:
|
||||||
- eventkit
|
- eventkit
|
||||||
---
|
---
|
||||||
|
|
||||||
# Barcode & QR Scanning
|
# Barcode & QR Scanning
|
||||||
|
|
||||||
## Purpose
|
## Purpose
|
||||||
@@ -20,6 +21,17 @@ Enable fast, accurate equipment tracking through QR code scanning. Every [[01 -
|
|||||||
| **Kit / Set** | QR Code (optional) | URL → `https://{instance}/kit/{id}` | Kit card / bag tag |
|
| **Kit / Set** | QR Code (optional) | URL → `https://{instance}/kit/{id}` | Kit card / bag tag |
|
||||||
| **Consumable** | Barcode (EAN/UPC) | Product ID or manufacturer barcode | Existing packaging or custom label |
|
| **Consumable** | Barcode (EAN/UPC) | Product ID or manufacturer barcode | Existing packaging or custom label |
|
||||||
|
|
||||||
|
### Legacy Barcode Support
|
||||||
|
|
||||||
|
Companies migrating to EventKit may already have existing barcode/label schemes. EventKit supports **dual scanning** — both legacy barcodes and new QR codes are recognised:
|
||||||
|
|
||||||
|
| Feature | Description |
|
||||||
|
| ---------------------- | ---------------------------------------------------------------------------- |
|
||||||
|
| Legacy barcode import | Import existing barcode-to-asset mappings during onboarding |
|
||||||
|
| Dual scanning | Scan either a legacy barcode or an EventKit QR code — both resolve the asset |
|
||||||
|
| Gradual migration | No need to re-label everything at once; legacy barcodes remain valid |
|
||||||
|
| Barcode format support | Code 128, Code 39, EAN-13, UPC-A, QR — any standard 1D/2D format |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## QR Code Design
|
## QR Code Design
|
||||||
@@ -34,13 +46,13 @@ https://inventory.company-a.com/asset/550e8400-e29b-41d4-a716-446655440000
|
|||||||
|
|
||||||
### Why URLs?
|
### Why URLs?
|
||||||
|
|
||||||
| Benefit | Description |
|
| Benefit | Description |
|
||||||
| ----------------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------ |
|
| ----------------------- | --------------------------------------------------------------------- |
|
||||||
| **Universal** | Any phone camera can scan it and open the asset page in a browser |
|
| **Universal** | Any phone camera can scan it and open the asset page in a browser |
|
||||||
| **Federation-friendly** | The domain tells any EventKit instance who owns the asset (see [[04 - Federation Architecture#Global Asset Identity | Global Asset Identity]]) |
|
| **Federation-friendly** | The domain tells any EventKit instance who owns the asset |
|
||||||
| **App-aware** | A dedicated EventKit app can intercept the URL and handle it natively |
|
| **App-aware** | A dedicated EventKit app can intercept the URL and handle it natively |
|
||||||
| **Offline-capable** | The app can extract the UUID locally and sync the action later |
|
| **Offline-capable** | The app can extract the UUID locally and sync the action later |
|
||||||
| **Future-proof** | No proprietary encoding — standard URLs work forever |
|
| **Future-proof** | No proprietary encoding — standard URLs work forever |
|
||||||
|
|
||||||
### Label Design
|
### Label Design
|
||||||
|
|
||||||
@@ -106,13 +118,13 @@ sequenceDiagram
|
|||||||
participant App as EventKit App
|
participant App as EventKit App
|
||||||
participant API as API Server
|
participant API as API Server
|
||||||
|
|
||||||
User->>App: Open [[02 - Planning Module#Pull Lists / Equipment Planning|Event Pull List]]
|
User->>App: Open Event Pull List
|
||||||
App-->>User: Show items to dispatch
|
App-->>User: Show items to dispatch
|
||||||
|
|
||||||
loop For each item/case
|
loop For each item/case
|
||||||
User->>App: Scan QR code
|
User->>App: Scan QR code
|
||||||
App->>API: POST /scan/checkout {asset_uuid, event_id}
|
App->>API: POST /scan/checkout {asset_uuid, event_id}
|
||||||
API-->>App: ✅ Asset status → "[[01 - Inventory Management#Asset Lifecycle & Statuses|Checked Out]]"
|
API-->>App: ✅ Asset status → "Checked Out"
|
||||||
App-->>User: ✅ Item confirmed on list
|
App-->>User: ✅ Item confirmed on list
|
||||||
end
|
end
|
||||||
|
|
||||||
@@ -192,7 +204,7 @@ sequenceDiagram
|
|||||||
participant A_API as Company A API
|
participant A_API as Company A API
|
||||||
|
|
||||||
User->>B_App: Scan QR code on received item
|
User->>B_App: Scan QR code on received item
|
||||||
Note over B_App: URL domain = company-a.com → [[04 - Federation Architecture|federated asset]]
|
Note over B_App: URL domain = company-a.com → federated asset
|
||||||
B_App->>B_API: POST /scan/subhire-receive {url, condition}
|
B_App->>B_API: POST /scan/subhire-receive {url, condition}
|
||||||
B_API->>A_API: GET /federation/asset/{uuid}
|
B_API->>A_API: GET /federation/asset/{uuid}
|
||||||
A_API-->>B_API: Asset details (Shure SM58, SN: 00142)
|
A_API-->>B_API: Asset details (Shure SM58, SN: 00142)
|
||||||
|
|||||||
@@ -15,14 +15,14 @@ Non-functional requirements, deployment model, API design, and infrastructure co
|
|||||||
|
|
||||||
### Core Decisions
|
### Core Decisions
|
||||||
|
|
||||||
| Layer | Technology | Rationale |
|
| Layer | Technology | Rationale |
|
||||||
| -------------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
|
| -------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
|
||||||
| **Backend language** | **Go** | Fast compilation, single binary deployment, excellent concurrency, strong ecosystem for network services |
|
| **Backend language** | **Go** | Fast compilation, single binary deployment, excellent concurrency, strong ecosystem for network services |
|
||||||
| **API protocol** | **ConnectRPC** (gRPC wrapper) | Type-safe, code-generated clients, supports gRPC, gRPC-Web, and Connect protocols — works in browsers natively |
|
| **API protocol** | **ConnectRPC** (gRPC wrapper) | Type-safe, code-generated clients, supports gRPC, gRPC-Web, and Connect protocols — works in browsers natively |
|
||||||
| **API definition** | **Protocol Buffers (Protobuf)** | Schema-first API design, backward-compatible evolution, generates Go server stubs + TypeScript/JS clients |
|
| **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 |
|
| **Database** | **PostgreSQL 15+** | Robust, proven, excellent JSON support, full-text search, strong ecosystem |
|
||||||
| **Frontend** | TBD (React, Vue, Svelte, or SolidJS) | ConnectRPC generates typed client SDKs for any JS/TS framework |
|
| **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 |
|
| **File storage** | Local filesystem or S3-compatible | Configurable per deployment |
|
||||||
|
|
||||||
### Why ConnectRPC
|
### Why ConnectRPC
|
||||||
|
|
||||||
@@ -41,6 +41,26 @@ This means:
|
|||||||
- **Mobile apps** can use gRPC natively
|
- **Mobile apps** can use gRPC natively
|
||||||
- **One `.proto` definition** generates server code (Go), browser client (TypeScript), and mobile client code
|
- **One `.proto` definition** generates server code (Go), browser client (TypeScript), and mobile client code
|
||||||
|
|
||||||
|
### Frontend Stack
|
||||||
|
|
||||||
|
| Component | Technology | Notes |
|
||||||
|
| ----------------- | ---------------------------- | -------------------------------------------------- |
|
||||||
|
| **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 |
|
||||||
|
| **API client** | ConnectRPC generated TS code | Type-safe from `.proto` definitions |
|
||||||
|
| **Build tool** | Vite | Fast dev server and optimised builds |
|
||||||
|
|
||||||
|
### Mobile App
|
||||||
|
|
||||||
|
| Component | Technology | Notes |
|
||||||
|
| ----------------- | ---------------------------- | ------------------------------------------------ |
|
||||||
|
| **Framework** | React Native / Expo | Shared knowledge with web React team |
|
||||||
|
| **Data fetching** | @tanstack/query | Same patterns as web client |
|
||||||
|
| **API client** | ConnectRPC generated TS code | Same `.proto` definitions as web |
|
||||||
|
| **Priority** | Planned but not prioritised | PWA / responsive web covers initial mobile needs |
|
||||||
|
| **Offline** | Nice-to-have | Queue scan operations and sync when reconnected |
|
||||||
|
|
||||||
### Project Structure (Proposed)
|
### Project Structure (Proposed)
|
||||||
|
|
||||||
```
|
```
|
||||||
@@ -95,6 +115,18 @@ eventkit/
|
|||||||
|
|
||||||
Each company runs their own instance. The deployment should be **simple and reproducible**.
|
Each company runs their own instance. The deployment should be **simple and reproducible**.
|
||||||
|
|
||||||
|
### Multi-Tenancy (Managed SaaS)
|
||||||
|
|
||||||
|
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 |
|
||||||
|
| **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 |
|
||||||
|
|
||||||
| Approach | Description |
|
| Approach | Description |
|
||||||
| ---------------------- | -------------------------------------------------------------------- |
|
| ---------------------- | -------------------------------------------------------------------- |
|
||||||
| **Docker Compose** | Recommended for single-server deployments — all services in one file |
|
| **Docker Compose** | Recommended for single-server deployments — all services in one file |
|
||||||
@@ -315,6 +347,18 @@ erDiagram
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## Notifications
|
||||||
|
|
||||||
|
| Channel | Supported | Notes |
|
||||||
|
| --------------- | --------- | --------------------------------------------- |
|
||||||
|
| **Email** | ✅ Yes | Transactional emails (SMTP or provider API) |
|
||||||
|
| **Web push** | ✅ Yes | Browser push notifications via service worker |
|
||||||
|
| **Native push** | ✅ Yes | Via Expo push / APNs / FCM for mobile app |
|
||||||
|
| **Webhooks** | ✅ Yes | Outbound webhooks for third-party integration |
|
||||||
|
| **SMS** | ❌ No | Not planned |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Monitoring & Observability
|
## Monitoring & Observability
|
||||||
|
|
||||||
| Feature | Description |
|
| Feature | Description |
|
||||||
|
|||||||
@@ -13,73 +13,73 @@ Remaining decisions and questions that need answers before or during implementat
|
|||||||
|
|
||||||
## Business & Scope
|
## Business & Scope
|
||||||
|
|
||||||
| # | Question | Options / Notes |
|
| # | 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 will be supported first? | Audio, lighting, video, staging, rigging, power, furniture, décor — prioritise for MVP |
|
||||||
| 2 | **Target company size** — small (1-5 people) or larger (20+)? | Affects complexity of RBAC, approval workflows, and UI |
|
| 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? |
|
| 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 |
|
| 4 | **MVP scope** — which module to build first? | Inventory + Scanning → Planning → CRM → Federation is a natural order |
|
||||||
| 5 | **Data migration** — what systems are companies migrating from? | Spreadsheets, Rentman, Current RMS, HireHop, custom systems — affects import tooling |
|
| 5 | ~~**Data migration** — what systems are companies migrating from?~~ | ✅ **Answered**: Nice-to-have future feature. Import tooling not a priority for MVP |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Technical
|
## Technical
|
||||||
|
|
||||||
| # | Question | Options / Notes |
|
| # | Question | Options / Notes |
|
||||||
| --- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
|
| --- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
|
||||||
| 6 | ~~**Tech stack** — backend language and framework?~~ | ✅ **Decided: Go** with ConnectRPC |
|
| 6 | ~~**Tech stack** — backend language and framework?~~ | ✅ **Decided: Go** with ConnectRPC |
|
||||||
| 7 | **Frontend framework** | React, Vue, Svelte, SolidJS? PWA vs native mobile app? (ConnectRPC generates typed TS clients for any framework) |
|
| 7 | ~~**Frontend framework**~~ | ✅ **Decided: React** with @tanstack/router + @tanstack/query. Mobile: React Native / Expo (planned, not priority) |
|
||||||
| 8 | ~~**Database**~~ | ✅ **Decided: PostgreSQL 15+** |
|
| 8 | ~~**Database**~~ | ✅ **Decided: PostgreSQL 15+** |
|
||||||
| 9 | **Search engine** | Built-in DB search, or dedicated (Meilisearch, Typesense) for large catalogues? |
|
| 9 | **Search engine** | Built-in DB search, or dedicated (Meilisearch, Typesense) for large catalogues? |
|
||||||
| 10 | **File storage** | Local filesystem, S3-compatible, or both? |
|
| 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? |
|
| 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)? |
|
| 12 | **Background jobs** | Go goroutines + internal queue, or external (Redis, NATS)? |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Federation
|
## Federation
|
||||||
|
|
||||||
| # | Question | Options / Notes |
|
| # | Question | Options / Notes |
|
||||||
| --- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- |
|
| --- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
|
||||||
| 13 | **Discovery** — how do companies find each other? | Public directory, manual URL exchange, QR code handshake, or invitation link? |
|
| 13 | ~~**Discovery** — how do companies find each other?~~ | ✅ **Answered: Manual URL exchange** between companies |
|
||||||
| 14 | ~~**Protocol format**~~ | ✅ **Decided: gRPC via ConnectRPC** with Protobuf service definitions |
|
| 14 | ~~**Protocol format**~~ | ✅ **Decided: gRPC via ConnectRPC** with Protobuf service definitions |
|
||||||
| 15 | **Pricing in federation** — should sub-hire rates be shared automatically? | Or negotiate out-of-band and just track the equipment movement? |
|
| 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? | Or only sub-hire (temporary)? |
|
| 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 |
|
| 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 |
|
| 18 | **Dispute resolution** — what happens if companies disagree about asset condition? | Photo evidence at dispatch/return, timestamped condition logs |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Scanning & Hardware
|
## Scanning & Hardware
|
||||||
|
|
||||||
| # | Question | Options / Notes |
|
| # | Question | Options / Notes |
|
||||||
| --- | ------------------------------------------------------------------ | ------------------------------------------------------------ |
|
| --- | ------------------------------------------------------------------- | ----------------------------------------------------------------------- |
|
||||||
| 19 | **Primary scanning device** — phone cameras or dedicated scanners? | Phones (lower cost) vs. Bluetooth scanners (faster) vs. both |
|
| 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? |
|
| 20 | **Label printer** — should EventKit support direct printing? | Or generate PDFs and let users print on any printer? |
|
||||||
| 21 | **Existing barcodes** — do companies already have asset labels? | Need import/migration path for existing barcode schemes |
|
| 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? | Determines investment in offline-first architecture |
|
| 22 | ~~**Offline requirements** — how often will users be offline?~~ | ✅ **Answered: Nice-to-have**, not a hard requirement |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## CRM
|
## CRM
|
||||||
|
|
||||||
| # | Question | Options / Notes |
|
| # | Question | Options / Notes |
|
||||||
| --- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------- |
|
| --- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||||
| 23 | **Invoicing depth** — full invoicing or integration with existing accounting? | Full = more work but self-contained; integration = less reinvention |
|
| 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? | Xero, QuickBooks, FreshBooks, DATEV — prioritise for target market |
|
| 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 |
|
| 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.)? |
|
| 26 | **Marketing features** — email campaigns needed? | Or leave marketing to dedicated tools (Mailchimp, etc.)? |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Planning
|
## Planning
|
||||||
|
|
||||||
| # | Question | Options / Notes |
|
| # | Question | Options / Notes |
|
||||||
| --- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------- |
|
| --- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
|
||||||
| 27 | **Crew management depth** — basic assignment or full scheduling? | Basic: assign people to events. Full: shifts, timesheets, payroll integration |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 30 | **Calendar integration** — which platforms? | Google Calendar, Outlook/Exchange, CalDAV — for crew and event sync |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -87,12 +87,12 @@ Remaining decisions and questions that need answers before or during implementat
|
|||||||
|
|
||||||
Suggested priority for answering these questions:
|
Suggested priority for answering these questions:
|
||||||
|
|
||||||
| Priority | Questions | Reason |
|
| Priority | Questions | Reason |
|
||||||
| -------------------------------------- | ------------------------------ | ------------------------------------------------- |
|
| -------------------------------------- | --------------------------- | ------------------------------------------------- |
|
||||||
| ✅ **Answered** | 6, 8, 14 | Go, PostgreSQL, ConnectRPC/gRPC |
|
| ✅ **Answered** | 2, 5-8, 13-16, 21-24, 27 | See strikethrough items above |
|
||||||
| 🔴 **Must answer before starting** | 1, 4, 7 | Scope and frontend framework |
|
| 🔴 **Must answer before starting** | 1, 4 | Scope (which equipment sectors first, MVP order) |
|
||||||
| 🟡 **Answer during early development** | 2, 3, 9, 10, 11, 19, 23 | Affects architecture but can be deferred slightly |
|
| 🟡 **Answer during early development** | 3, 9-11, 19 | Affects architecture but can be deferred slightly |
|
||||||
| 🟢 **Answer before beta** | 5, 12, 13, 15-18, 20-22, 24-30 | Important but not blocking initial development |
|
| 🟢 **Answer before beta** | 12, 17-18, 20, 25-26, 28-30 | Important but not blocking initial development |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -106,3 +106,4 @@ Suggested priority for answering these questions:
|
|||||||
- [[05 - Barcode and QR Scanning]] — Scanning and hardware
|
- [[05 - Barcode and QR Scanning]] — Scanning and hardware
|
||||||
- [[06 - Module Integration]] — Cross-module workflows
|
- [[06 - Module Integration]] — Cross-module workflows
|
||||||
- [[07 - Technical Requirements]] — Technical decisions made and remaining
|
- [[07 - Technical Requirements]] — Technical decisions made and remaining
|
||||||
|
- [[09 - Discovery Questions]] — Original discovery questionnaire with answers
|
||||||
|
|||||||
148
Test/EventKit/09 - Discovery Questions.md
Normal file
148
Test/EventKit/09 - Discovery Questions.md
Normal file
@@ -0,0 +1,148 @@
|
|||||||
|
---
|
||||||
|
tags:
|
||||||
|
- eventkit
|
||||||
|
---
|
||||||
|
|
||||||
|
# Discovery Questions
|
||||||
|
|
||||||
|
Fill in your answers below each question. These will feed back into the existing documentation — see [[08 - Open Questions]] for the current list of unresolved items.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎨 Frontend & User Experience
|
||||||
|
|
||||||
|
### 1. Frontend Framework
|
||||||
|
|
||||||
|
Do you have a preference? (e.g. React, Vue, Svelte, HTMX + Go templates, or something else?) Will it be a SPA or server-rendered?
|
||||||
|
|
||||||
|
> **Answer:** Personally, I'm mostly experienced with React. Since SEO isn't really an requirement I'd go with React. Personal preference: @tanstack/router & @tanstack/query.
|
||||||
|
|
||||||
|
### 2. Mobile App
|
||||||
|
|
||||||
|
Is a native mobile app planned (iOS/Android), or will a PWA / responsive web app cover mobile scanning use cases?
|
||||||
|
|
||||||
|
> **Answer:** A native mobile app is planned, but not prioritized. The native app should be written in react-native / expo using @tanstack/query.
|
||||||
|
|
||||||
|
### 3. Offline Support
|
||||||
|
|
||||||
|
How important is offline capability? Should warehouse staff be able to scan and queue operations when connectivity drops?
|
||||||
|
|
||||||
|
> **Answer:** If possible, not a 100% requirement
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 💰 Commercial & Business Logic
|
||||||
|
|
||||||
|
### 4. Pricing Model
|
||||||
|
|
||||||
|
How is equipment hire priced? Per-day? Per-event? Tiered rates for longer hires? Weekend vs weekday rates?
|
||||||
|
|
||||||
|
> **Answer:** It depends. Per day (rental) or per Event (service). Yes tiered rates would be an interesting feature and weekend vs. weekday rates. Or on and off season rates would also be an interesting feature, but without priority.
|
||||||
|
|
||||||
|
### 5. Accounting Integration
|
||||||
|
|
||||||
|
You mentioned Xero/QuickBooks — is one of these the priority? How deep should the sync go (invoices only, or also payments/purchase orders)?
|
||||||
|
|
||||||
|
> **Answer:** I want to provide users with integrated accounting features, but also give the options to use Xero / QuickBooks. But integrated accounting features have the priority and Xero and QuickBooks is optional. Invoices, payments and purchases.
|
||||||
|
|
||||||
|
### 6. Multi-Currency
|
||||||
|
|
||||||
|
Is this a real requirement now, or a future nice-to-have? If now, do you need live exchange rates or manual rates?
|
||||||
|
|
||||||
|
> **Answer:** It's a future nice-to-have. Live exchange rates.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 👥 Users & Access
|
||||||
|
|
||||||
|
### 7. Multi-Tenancy
|
||||||
|
|
||||||
|
In the managed SaaS model, is it one database per tenant (instance), or a shared database with tenant isolation?
|
||||||
|
|
||||||
|
> **Answer:** In the SaaS model a shared database with tenant isolation is prefered
|
||||||
|
|
||||||
|
### 8. Crew Portal
|
||||||
|
|
||||||
|
Do crew members get their own login to see schedules, confirm availability, submit timesheets? Or is crew management admin-only?
|
||||||
|
|
||||||
|
> **Answer:** Crewmembers should be able to login and confirm availability.
|
||||||
|
|
||||||
|
### 9. Client Portal
|
||||||
|
|
||||||
|
Should clients be able to log in to view/approve quotes, see event status, or download invoices?
|
||||||
|
|
||||||
|
> **Answer:** Yes Client should also be able to login an view/approve/deny/... quotes/...
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🔗 Federation & Sub-hire
|
||||||
|
|
||||||
|
### 10. Federation Discovery
|
||||||
|
|
||||||
|
How do companies find each other? Manual URL exchange? A public directory? An invite-link mechanism?
|
||||||
|
|
||||||
|
> **Answer:** Manual URL exchange
|
||||||
|
|
||||||
|
### 11. Sub-hire Pricing
|
||||||
|
|
||||||
|
When sub-hiring from a partner, are prices negotiated per-transaction, or are rate cards pre-agreed in the trust relationship?
|
||||||
|
|
||||||
|
> **Answer:** Prices should be negotiated per-transaction
|
||||||
|
|
||||||
|
### 12. Asset Ownership Transfer
|
||||||
|
|
||||||
|
Can an asset permanently change ownership between instances (e.g. selling equipment to a partner)?
|
||||||
|
|
||||||
|
> **Answer:** Yes
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📦 Inventory Specifics
|
||||||
|
|
||||||
|
### 13. Existing Barcodes
|
||||||
|
|
||||||
|
Many companies already have barcode/label systems. Should EventKit support importing/mapping legacy barcodes alongside the new QR system?
|
||||||
|
|
||||||
|
> **Answer:** Yes, but only if possible
|
||||||
|
|
||||||
|
### 14. Consumable Procurement
|
||||||
|
|
||||||
|
Should the system generate actual purchase orders, or just alert that stock is low?
|
||||||
|
|
||||||
|
> **Answer:** Generate purchase orders, which should be manually confirmed.
|
||||||
|
|
||||||
|
### 15. Insurance & Compliance
|
||||||
|
|
||||||
|
Should the system track PAT testing, LOLER certificates, insurance expiry, and gate these against dispatch?
|
||||||
|
|
||||||
|
> **Answer:** Yes, but with Austrian / European testing standards.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🚀 Deployment & Operations
|
||||||
|
|
||||||
|
### 16. Target Scale
|
||||||
|
|
||||||
|
What's a "typical" customer? 100 assets or 100,000? 5 concurrent events or 500? This affects architecture decisions significantly.
|
||||||
|
|
||||||
|
> **Answer:** This is not completely discussed. Both should be possible, but main target are small to medium sized companies wanting to share ressources.
|
||||||
|
|
||||||
|
### 17. Data Migration
|
||||||
|
|
||||||
|
Will customers be migrating from existing systems (CurrentRMS, Rentman, HireTrack, spreadsheets)? Should import tooling be a priority?
|
||||||
|
|
||||||
|
> **Answer:** Importing should be a cool nice to have future feature
|
||||||
|
|
||||||
|
### 18. Notification Channels
|
||||||
|
|
||||||
|
Email only, or also push notifications, SMS, Slack/Teams webhooks?
|
||||||
|
|
||||||
|
> **Answer:** EMail, Web and Native push. Webhooks. No SMS
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Related Documentation
|
||||||
|
|
||||||
|
- [[00 - System Overview]] — High-level system overview
|
||||||
|
- [[08 - Open Questions]] — Existing open questions list
|
||||||
|
- [[07 - Technical Requirements]] — Technical decisions already made
|
||||||
Reference in New Issue
Block a user