vault backup: 2026-02-27 10:43:35
This commit is contained in:
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
|
||||
Reference in New Issue
Block a user