@clidey/dory 0.1.0 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (53) hide show
  1. package/README.md +1 -1
  2. package/docs/api-playground-demo.mdx +119 -0
  3. package/docs/api-reference/openapi.json +366 -0
  4. package/docs/api-reference/operations/create.mdx +5 -0
  5. package/docs/api-reference/operations/delete.mdx +5 -0
  6. package/docs/api-reference/operations/get.mdx +5 -0
  7. package/docs/api-reference/operations/update.mdx +5 -0
  8. package/docs/assets/dory.jpeg +0 -0
  9. package/docs/dory.json +12 -131
  10. package/docs/favicon.svg +75 -0
  11. package/docs/features.mdx +440 -0
  12. package/docs/introduction.mdx +44 -0
  13. package/docs/logo/logo.png +0 -0
  14. package/package.json +9 -10
  15. package/src/mdx/fence.tsx +2 -1
  16. package/src/mdx/mermaid.tsx +39 -11
  17. package/src/mdx/source.tsx +15 -4
  18. package/docs/README.md +0 -2
  19. package/docs/configuration/app-settings/feature-flags.mdx +0 -157
  20. package/docs/configuration/app-settings/user-settings.mdx +0 -201
  21. package/docs/configuration/installation-setup/env-vars.mdx +0 -198
  22. package/docs/configuration/installation-setup/installation.mdx +0 -127
  23. package/docs/integrations/analytics-monitoring/error-tracking.mdx +0 -199
  24. package/docs/integrations/analytics-monitoring/notifications.mdx +0 -189
  25. package/docs/integrations/analytics-monitoring/user-analytics.mdx +0 -182
  26. package/docs/integrations/shopify-integration/shopify-setup.mdx +0 -226
  27. package/docs/integrations/shopify-integration/shopify-webhooks.mdx +0 -207
  28. package/docs/overview/developer-overview/dev-architecture.mdx +0 -292
  29. package/docs/overview/product-intro/app-overview.mdx +0 -167
  30. package/docs/overview/product-intro/architecture.mdx +0 -203
  31. package/docs/overview/product-intro/core-concepts.mdx +0 -267
  32. package/docs/platform-admin/billing-subscriptions/billing.mdx +0 -176
  33. package/docs/platform-admin/system-maintenance/db-migrations.mdx +0 -184
  34. package/docs/platform-admin/system-maintenance/health-monitoring.mdx +0 -222
  35. package/docs/platform-admin/system-maintenance/queue-management.mdx +0 -234
  36. package/docs/platform-admin/user-team-management/teams.mdx +0 -170
  37. package/docs/platform-admin/user-team-management/users.mdx +0 -185
  38. package/docs/support/legal/dependency-analysis.mdx +0 -132
  39. package/docs/support/legal/privacy-terms.mdx +0 -73
  40. package/docs/support/troubleshooting/common-issues.mdx +0 -159
  41. package/docs/usage/api-usage/api-inventory.mdx +0 -213
  42. package/docs/usage/api-usage/api-products.mdx +0 -249
  43. package/docs/usage/api-usage/api-purchase-orders.mdx +0 -289
  44. package/docs/usage/api-usage/api-reports.mdx +0 -227
  45. package/docs/usage/api-usage/api-suppliers.mdx +0 -171
  46. package/docs/usage/api-usage/api-user-management.mdx +0 -171
  47. package/docs/usage/ui-workflows/bundles.mdx +0 -157
  48. package/docs/usage/ui-workflows/demand-planning.mdx +0 -210
  49. package/docs/usage/ui-workflows/favorites.mdx +0 -167
  50. package/docs/usage/ui-workflows/inventory-management.mdx +0 -179
  51. package/docs/usage/ui-workflows/onboarding.mdx +0 -215
  52. package/docs/usage/ui-workflows/purchase-orders.mdx +0 -200
  53. package/docs/usage/ui-workflows/reports.mdx +0 -257
@@ -1,157 +0,0 @@
1
- ---
2
- title: 'Feature Flags'
3
- description: 'Manage and understand feature flags affecting the application behavior.'
4
- ---
5
-
6
- # Feature Flags
7
-
8
- ## Purpose and Scope
9
-
10
- The Feature Flags module provides a centralized mechanism to enable or disable specific features within the Genie application dynamically. This approach allows controlled rollout, testing, and gradual adoption of new functionalities without deploying new code versions.
11
-
12
- This module primarily parses and validates feature flag configurations from environment variables and exposes them for use throughout the web and API services.
13
-
14
- ## Technical Overview
15
-
16
- Feature Flags are defined and validated using the `zod` schema validation library to ensure that flag values comply with expected types. Flags can generally be boolean or strings convertible to booleans (`"true"`), permitting flexibility in how environment variables are specified.
17
-
18
- The parsing logic safely attempts to read environment variables, falling back to an empty object on failure and capturing exceptions with Sentry for monitoring.
19
-
20
- ### Key Locations
21
-
22
- - **Web client feature flags:** Defined and parsed in `apps/web/src/utils/feature-flags.ts`.
23
- - **API service feature flags:** Defined under API config schemas in `apps/api/src/config/schemas/index.ts`.
24
-
25
-
26
- ## Core Concepts and Responsibilities
27
-
28
- - **Feature Flags Schema:** A set of typed mappings that describe each flag's expected type and optional presence.
29
- - Flags can be a boolean or a string (`"true"` interpreted as `true`) or undefined.
30
- - Certain flags have additional typed definitions such as arrays, e.g., `DEMAND_PLANNER_SHOP_ALLOW_LIST` which is an optional array of strings.
31
-
32
- - **Error Handling:** Parsing errors are logged to Sentry via `Sentry.captureException(error)` to facilitate early detection of misconfiguration.
33
-
34
- - **Environmental Scope:** Flags are read from environment variables prefixed with `NEXT_PUBLIC_FEATURE_FLAGS` for frontend exposure or `FEATURE_FLAGS` for the backend.
35
-
36
- - **Security and Scope:** Flags must be explicitly defined in environment configuration, preventing undefined or unexpected flags from being used.
37
-
38
- ## Code Structure
39
-
40
- ### `apps/web/src/utils/feature-flags.ts`
41
-
42
- This file implements the feature flag parsing logic for the web frontend.
43
-
44
- - `flagSchema`: Accepts either a boolean or a string representing booleans and transforms the string to a boolean.
45
- - `featureFlagsSchema`: Defines known feature flags such as `UI_PAGE`, `DEMAND_PLANNER`, `MOV`, `PAYMENT_TERMS`, and others. Some flags are booleans, others arrays of strings.
46
- - `parseFeatureFlags()`:
47
- - Attempts to JSON parse the environment variable `NEXT_PUBLIC_FEATURE_FLAGS`.
48
- - Validates it against the schema.
49
- - On error, logs to Sentry and returns an empty object.
50
- - `FEATURE_FLAGS`: Exported constant representing the parsed flags for app-wide consumption.
51
-
52
- ```ts
53
- import { z } from "zod";
54
- import * as Sentry from "@sentry/nextjs";
55
-
56
- const flagSchema = z.union([
57
- z.boolean(),
58
- z.string().transform((val) => val === "true")
59
- ]).optional();
60
-
61
- const featureFlagsSchema = z.object({
62
- UI_PAGE: flagSchema,
63
- DEMAND_PLANNER: flagSchema,
64
- DEMAND_PLANNER_SHOP_ALLOW_LIST: z.array(z.string()).optional(),
65
- MOV: flagSchema,
66
- PAYMENT_TERMS: flagSchema,
67
- MANUAL_STATUS: flagSchema,
68
- REPORTS_ALERTS: flagSchema,
69
- PAYMENTS_PAGE: flagSchema,
70
- });
71
-
72
- type FeatureFlags = z.infer<typeof featureFlagsSchema>;
73
-
74
- const parseFeatureFlags = (): FeatureFlags => {
75
- try {
76
- return featureFlagsSchema.parse(
77
- JSON.parse(process.env.NEXT_PUBLIC_FEATURE_FLAGS || "{}")
78
- );
79
- } catch (error) {
80
- Sentry.captureException(error);
81
- return {};
82
- }
83
- };
84
-
85
- export const FEATURE_FLAGS = parseFeatureFlags();
86
- ```
87
-
88
- ### `apps/api/src/config/schemas/index.ts`
89
-
90
- This file extends feature flag support within the API backend.
91
-
92
- - The API uses a similar schema (`featureFlagSchema`) that accepts booleans or strings convertible to booleans.
93
- - `featureFlagsSchema` is defined but currently empty (`z.object({} satisfies Record<string, typeof featureFlagSchema>)`).
94
- - The `FEATURE_FLAGS` environment variable is parsed and coerced to a string, then JSON parsed and validated.
95
-
96
- The config schema merges the feature flags, along with many other env vars, into a consolidated validation schema.
97
-
98
- ```ts
99
- const featureFlagSchema = z.union([
100
- z.boolean(),
101
- z.string().transform((value) => value === "true")
102
- ]).optional();
103
-
104
- const featureFlagsSchema = z.object(
105
- {} satisfies Record<string, typeof featureFlagSchema>
106
- );
107
-
108
- export type FeatureFlags = z.infer<typeof featureFlagsSchema>;
109
-
110
- export const configSchema = z.object({
111
- // ... other config fields ...
112
- FEATURE_FLAGS: z.coerce.string().optional().transform((jsonString = "{}") =>
113
- featureFlagsSchema.parse(JSON.parse(jsonString))
114
- ),
115
- // ... other config fields ...
116
- }).merge(databaseConfigSchema).strip();
117
- ```
118
-
119
- ## Environment & Configuration
120
-
121
- ### Environment Variables
122
-
123
- - `NEXT_PUBLIC_FEATURE_FLAGS` (frontend): JSON string representing flags.
124
- - `FEATURE_FLAGS` (API backend): JSON string representing flags.
125
-
126
- Example environment value for frontend (simplified):
127
-
128
- ```json
129
- {
130
- "UI_PAGE": true,
131
- "DEMAND_PLANNER": "true",
132
- "DEMAND_PLANNER_SHOP_ALLOW_LIST": ["shop1", "shop2"],
133
- "MOV": false
134
- }
135
- ```
136
-
137
- The environment variable must be valid JSON and correctly typed for each feature flag.
138
-
139
- ## Integration & System Boundaries
140
-
141
- - **Web UI:** Uses parsed `FEATURE_FLAGS` to enable/disable UI features.
142
- - **API:** Reads feature flags from environment on startup to alter backend behavior.
143
- - **Error Logging:** Parsing issues send errors to Sentry for diagnosis.
144
-
145
- ## Observability & Error Handling
146
-
147
- - Parsing errors of feature flags are monitored via Sentry.
148
- - Apps fall back gracefully to default empty flags on error, ensuring stability.
149
-
150
- ## Summary
151
-
152
- This feature flags module provides a robust, type-safe approach to managing application features dynamically through environment configuration. It ensures flags are validated on startup and exposes them as constants for consistent use across frontend and backend components.
153
-
154
- ## References
155
-
156
- - [Feature Flags in Web Frontend](apps/web/src/utils/feature-flags.ts)
157
- - [Feature Flags in API Config](apps/api/src/config/schemas/index.ts)
@@ -1,201 +0,0 @@
1
- ---
2
- title: 'User and Team Settings'
3
- description: 'Configuration of user preferences, team settings, saved views, and insights settings.'
4
- ---
5
-
6
- ## User and Team Settings - Internal Developer Documentation
7
-
8
- ### 1. Purpose and Scope
9
-
10
- This module handles **user and team settings management** within the Genie application, enabling users to configure team-wide preferences, manage memberships, and control notifications. It provides REST API endpoints to update and retrieve team general settings, insights settings, shop settings, and manage invitations and team members.
11
-
12
- The module's responsibilities include:
13
- - CRUD operations on team settings (general, insights, shop).
14
- - Managing team member invitations and acceptance.
15
- - Deactivating users from a team.
16
- - Querying team membership and invitation status.
17
- - Managing user notification preferences.
18
-
19
- It acts as a boundary between frontend clients and backend services managing persistent storage and business logic related to teams and user contexts.
20
-
21
- ### 2. Technical Overview
22
-
23
- The main components involved are:
24
-
25
- - **TeamsController** (`apps/api/src/user-management/controllers/teams.controller.ts`): API entrypoint defining HTTP routes for team settings and team user management.
26
- - **SettingsService** (`apps/api/src/user-management/services/settings.service.ts`): Business logic for retrieving and updating team settings.
27
- - **TeamsService** (`apps/api/src/user-management/services/teams.service.ts`): Business logic for user and invitation management within teams.
28
- - **UserContextController** (`apps/api/src/user-management/controllers/user-context.controller.ts`): Manages retrieval of user context and notification preferences.
29
-
30
- The module leverages **NestJS** for structuring controllers and services and **TypeORM** for database interactions with `TeamEntity`, `UserEntity`, and `MemberInvitationEntity`.
31
-
32
- Dependencies include:
33
- - Shared DTOs and schemas from `@genie/shared` for payload validation.
34
- - Zod validation pipes for input validation.
35
- - JWT service for token handling during invitation acceptance.
36
-
37
- #### Architectural Pattern:
38
- - The system follows an **MVC-style architecture** where Controllers handle HTTP requests, delegate to Services for business logic, and Services interact with entities via repositories.
39
-
40
- ### 3. Core Concepts and Responsibilities
41
-
42
- - **Team Settings** are divided into:
43
- - **General Settings**: Business name, contact info, VAT, and address.
44
- - **Insights Settings**: Sales period days, stock levels, and grading strategy parameters.
45
- - **Shop Settings**: Currency and timezone.
46
-
47
- - **Users and Invitations**:
48
- - Invitations are managed as entities with statuses (Pending, Accepted, Expired).
49
- - An invitation can be sent, accepted with validation and token generation, or expired.
50
- - Only Admin users can deactivate users.
51
-
52
- - **Notification Settings**:
53
- - Stored as JSON config inside team entity under `notifications`.
54
- - Users can retrieve and update their notification preferences.
55
-
56
- - **Error Handling**:
57
- - If requests come from users with no team association, `GenieException` with "User not in a team" message is thrown.
58
- - Role-based authorization on critical operations like user deactivation.
59
-
60
- - **Security**:
61
- - Invitation acceptance requires a valid code (invitation ID) and checks for expiration.
62
- - JWT tokens are issued upon invitation acceptance.
63
-
64
- ### 4. Code Structure
65
-
66
- | File | Description |
67
- |-------|-------------|
68
- | `teams.controller.ts` | API endpoints for team settings and user management (send invitations, deactivate users, retrieve members) |
69
- | `settings.service.ts` | Implements logic to get and update team settings in the DB, including insights and shop settings |
70
- | `teams.service.ts` | Handles user retrieval, invitations, notification states, team user management, and tokenized invitation acceptance |
71
- | `user-context.controller.ts` | API endpoints to get user context and manage user notification preferences |
72
- | `team.entity.ts` | Defines Team entity schema, including settings fields and onboarding states |
73
- | `user.entity.ts` | Defines User entity schema and relations to team |
74
-
75
-
76
- #### Example snippet from TeamsController showing settings update endpoint:
77
- ```ts
78
- @Put("settings")
79
- @HttpCode(204)
80
- async updateTeamSettings(@Request() { user }: RequestWithUser, @Body(new ZodValidationPipe(teamSettingsDtoSchema)) settings: TeamSettingsDto) {
81
- if (!user.teamId) throw new GenieException("User not in a team");
82
- await this.settingsService.updateTeamSettings(user.teamId, settings);
83
- }
84
- ```
85
-
86
- ### 5. API and Interfaces
87
-
88
- #### TeamsController Endpoints Summary
89
-
90
- | Endpoint | Method | Description | Req. Auth | Input (DTO) | Output |
91
- |-------------------------------|--------|-----------------------------------------------------|-----------|-------------------------------------|--------------------------|
92
- | `/teams/settings` | PUT | Update complete team settings | Yes | `TeamSettingsDto` | 204 No Content |
93
- | `/teams/settings/general` | PUT | Update team general settings | Yes | `TeamGeneralSettingsDto` | 204 No Content |
94
- | `/teams/settings/general` | GET | Get team general settings | Yes | - | `TeamGeneralSettingsDto` |
95
- | `/teams/settings/insights` | PUT | Update team insights settings | Yes | `InsightsSettingsDto` | 204 No Content |
96
- | `/teams/settings/insights` | GET | Get team insights settings | Yes | - | `InsightsSettingsDto` |
97
- | `/teams/settings/shop` | GET | Get team shop settings (currency, timezone) | Yes | - | `GetShopSettingsResponseDto` |
98
- | `/teams/members` | GET | Get all team members and invitations | Yes | - | `GetTeamUsersInfoResponseDto` |
99
- | `/teams/send-invitations` | POST | Send invitations to new members | Yes | `SendInvitationsRequestDto` | `SendInvitationsResponseDto` |
100
- | `/teams/user/:id/deactivate` | PATCH | Deactivate a user (admin-only) | Yes | - | 204 No Content |
101
- | `/teams/invitations/:email` | DELETE | Remove an invitation by email | Yes | - | 204 No Content |
102
- | `/teams/accept-invitation` | POST | Accept invitation and obtain auth token | No | `AcceptInvitationRequestDto` | `{ token: string }` |
103
-
104
- #### UserContextController Endpoints
105
-
106
- | Endpoint | Method | Description | Auth | Input | Output |
107
- |-------------------------|--------|--------------------------------|--------|-------------------------|-------------------------------|
108
- | `/user-context` | GET | Get current user context | Yes | - | `GetUserContextResponseDto` |
109
- | `/user-context/notifications` | GET | Get user/team notification prefs | Yes | - | `UserNotificationsSchema` |
110
- | `/user-context/notifications` | PUT | Update notification preferences | Yes | `UserNotificationsSchema` | 204 No Content |
111
-
112
- #### API Validation
113
- - All request bodies are validated using `ZodValidationPipe` based on shared DTO schemas.
114
- - User authorization checks confirm user belongs to a team before proceeding.
115
-
116
- #### Failure Modes
117
- - Throws `GenieException` with clear messages for unauthorized or invalid operations, e.g. "User not in a team", "Only team admins can remove users".
118
- - Invitation acceptance fails with `ForbiddenException` for invalid or expired codes.
119
-
120
- ### 6. Environment & Configuration
121
-
122
- - Uses environment variables for:
123
- - Intercom secret (`INTERCOM_IDENTITY_VERIFICATION_SECRET`) for generating user hashes.
124
- - Team integration tokens for Mantle subscription management.
125
-
126
- - Slack app token and channel IDs are used indirectly via injected `SlackService` for notifications when related to teams.
127
-
128
- - Team settings updates impact DB table `team` via TypeORM repository.
129
-
130
- - JWT secret utilized by `JwtService` for signing tokens on invitation acceptance.
131
-
132
- ### 7. Testing, Monitoring, and Deployment
133
-
134
- - Standard NestJS testing practices apply. Unit and integration tests should cover:
135
- - Controller endpoint authorization and validation.
136
- - Service method's DB interactions and error handling.
137
-
138
- - Observability:
139
- - Errors throw `GenieException` which integrates with centralized error handling.
140
- - Logging and tracing occur in related services (not detailed here).
141
-
142
- - Deployment follows standard service lifecycle as per NestJS backend.
143
-
144
- ### 8. Troubleshooting & Known Issues
145
-
146
- - Common failure if the user is not assigned to a team is consistently checked in controllers.
147
- - Admin-only restrictions on deactivation ensure minimal privilege violations.
148
- - Expired or invalid invitation codes are handled explicitly with meaningful exceptions.
149
-
150
- ### 9. Style and Tone Guidelines
151
-
152
- - Terminology consistent with codebase entities: "team", "user", "invitation", "settings".
153
- - Methods first check authorization and preconditions, then perform updates.
154
- - API uses HTTP 204 status for successful PUT/PATCH requests with no response body.
155
-
156
- ---
157
-
158
- ## Mermaid Diagram: Teams and User Settings Module Architecture
159
-
160
- ```mermaid
161
- flowchart TD
162
- subgraph API Layer
163
- TeamsController["TeamsController<br/>(HTTP API)" ]:::api
164
- UserContextController["UserContextController<br/>(User Context API)"]:::api
165
- end
166
-
167
- subgraph Services Layer
168
- SettingsService["SettingsService<br/>Team Settings Logic"]:::service
169
- TeamsService["TeamsService<br/>User & Invitations Logic"]:::service
170
- end
171
-
172
- subgraph Persistence Layer
173
- TeamEntity["TeamEntity<br/>(Postgres DB)"]:::db
174
- UserEntity["UserEntity<br/>(Postgres DB)"]:::db
175
- MemberInvitationEntity["MemberInvitationEntity<br/>(Postgres DB)"]:::db
176
- end
177
-
178
- %% Relationships
179
- TeamsController -->|calls| SettingsService
180
- TeamsController -->|calls| TeamsService
181
- UserContextController -->|calls| TeamsService
182
-
183
- SettingsService -->|reads/writes| TeamEntity
184
- TeamsService -->|reads/writes| UserEntity
185
- TeamsService -->|reads/writes| TeamEntity
186
- TeamsService -->|reads/writes| MemberInvitationEntity
187
-
188
- %% Classes styles
189
- classDef api fill:#f9f,stroke:#333,stroke-width:1px,color:#000
190
- classDef service fill:#bbf,stroke:#333,stroke-width:1px,color:#000
191
- classDef db fill:#bfb,stroke:#060,stroke-width:1px,color:#060
192
-
193
- %% Click events
194
- click TeamsController "apps/api/src/user-management/controllers/teams.controller.ts"
195
- click UserContextController "apps/api/src/user-management/controllers/user-context.controller.ts"
196
- click SettingsService "apps/api/src/user-management/services/settings.service.ts"
197
- click TeamsService "apps/api/src/user-management/services/teams.service.ts"
198
- click TeamEntity "apps/api/src/user-management/entities/team.entity.ts"
199
- click UserEntity "apps/api/src/user-management/entities/user.entity.ts"
200
- click MemberInvitationEntity "apps/api/src/user-management/entities/member-invitation.entity.ts"
201
- ```
@@ -1,198 +0,0 @@
1
- ---
2
- title: 'Environment Variables & Configuration'
3
- description: 'Details of required environment variables, example values, and configuration across dev, staging, and prod.'
4
- ---
5
-
6
- # Environment Variables & Configuration
7
-
8
- ## Purpose and Scope
9
-
10
- This document provides a detailed technical overview of the environment variables and configuration management within the Genie application, specifically focusing on how team, shop, and general settings are handled. It covers the backend service responsible for settings management, the structure of configuration data, integration points with external services (notably Shopify), and the interaction with frontend components for settings updates.
11
-
12
- The scope is limited to the environment and configuration aspects related to team settings, insights, shop configurations, and business details within the Genie platform. It clarifies the flow and storage of configuration data, including environment-dependent settings like time zone and currency.
13
-
14
- ## Technical Overview
15
-
16
- The SettingsService in the backend manages the core configuration and environment-specific settings at the team level. It acts as the interface to stored data for team general settings, insights settings, and shop settings, primarily through the `TeamEntity` persisted in the database.
17
-
18
- ### System Boundaries and Architecture
19
-
20
- - **Backend:** The `SettingsService` uses TypeORM repository to read and update the `TeamEntity` database representation.
21
- - **Frontend:** React-based web UI components fetch and mutate settings by invoking API endpoints which under the hood use `SettingsService`.
22
- - **External API Integration:** Shopify data such as shop currency and time zone are imported into the team settings and validated.
23
-
24
- ### Key Technologies and Patterns
25
-
26
- - **NestJS** with the `@Injectable()` pattern for service injection.
27
- - **TypeORM** to interface with PostgreSQL or relational DB for `TeamEntity` storage.
28
- - **Data Transfer Objects (DTOs)** encapsulate settings data structures for transmission between layers.
29
- - **React Query** in the frontend for data fetching and mutation.
30
-
31
- ### Configuration Data Flow
32
-
33
- 1. Shopify data (currency, time zone) imported via webhooks or manual sync.
34
- 2. Stored persistently in the `TeamEntity` fields (`currency`, `timeZone`).
35
- 3. General team business settings stored as JSON in `generalSettings` in the same entity.
36
- 4. Insights settings regarding inventory grading, sales periods, etc., stored via dedicated columns.
37
- 5. Frontend reads/writes through APIs that delegate to `SettingsService` methods.
38
-
39
- ```mermaid
40
- flowchart TD
41
- subgraph Backend
42
- SS["SettingsService"]:::service
43
- TE["TeamEntity (DB Model)"]:::database
44
- end
45
-
46
- subgraph Frontend
47
- GU["GeneralSettings UI Component"]:::frontend
48
- end
49
-
50
- subgraph Shopify
51
- SH["Shopify API / Webhook"]:::external
52
- end
53
-
54
- GU -->|"API calls for get/update settings"| SS
55
- SS -->|"Read/Write settings"| TE
56
- SH -->|"Push shop data (currency/timezone)"| SS
57
-
58
- classDef service fill:#1976d2,color:#fff,stroke:#0b3d91,stroke-width:1px;
59
- classDef database fill:#795548,color:#fff,stroke:#5d4037,stroke-width:1px;
60
- classDef frontend fill:#388e3c,color:#fff,stroke:#2e7d32,stroke-width:1px;
61
- classDef external fill:#fbc02d,color:#000,stroke:#f9a825,stroke-width:1px;
62
-
63
- click SS "apps/api/src/user-management/services/settings.service.ts"
64
- click TE "apps/api/src/user-management/entities/team.entity.ts"
65
- click GU "apps/web/src/components/pages/settings/general-settings.tsx"
66
- ```
67
-
68
- ## Core Concepts and Responsibilities
69
-
70
- ### Team Settings
71
-
72
- - Represented primarily by `TeamEntity`.
73
- - Contains both simple scalar settings (e.g., `name`, `currency`, `timeZone`) and complex JSON blobs (e.g., `generalSettings`, `stockLevelsSettings`).
74
- - Manages onboarding, enabled state, and disables reasons.
75
-
76
- ### Insights Settings
77
-
78
- - Includes inventory grading strategy and threshold levels.
79
- - Important validation: `InventoryItemGradingStrategy.SalesFrequency` is explicitly unsupported and raises exceptions.
80
-
81
- ### Shopify Integration
82
-
83
- - The Shopify shop data (e.g., currency, time zone) is imported and validated. Time zone validation is done via `isValidTimeZone`.
84
- - Defaults to `Etc/UTC` if invalid or missing.
85
-
86
- ### Error Handling
87
-
88
- - Uses `GenieException` to encapsulate errors with context, such as team ID or invalid states.
89
-
90
- ### Ownership
91
-
92
- - Maintained by the user management backend module.
93
- - Settings changes propagate via API and frontend UI.
94
-
95
- ### Non-functional Requirements
96
-
97
- - Time zone and currency are critical for correct operation and must always be valid.
98
- - The system must guard against unsupported grading strategies.
99
- - Updates must be atomic and error-resilient.
100
-
101
- ## Code Structure
102
-
103
- | File/Folder | Role Description |
104
- |---------------------------------|--------------------------------------------------------|
105
- | `apps/api/src/user-management/services/settings.service.ts` | Core backend logic for loading and updating team settings. |
106
- | `apps/api/src/user-management/entities/team.entity.ts` | Database entity modeling the team configuration persistently. |
107
- | `apps/web/src/components/pages/settings/general-settings.tsx` | Frontend UI component for managing general team and shop settings. |
108
- | `apps/web/src/api/resources/settings` | API layer exports for settings-related calls. |
109
-
110
- ### Key Code Snippet from `SettingsService`
111
-
112
- ```ts
113
- async updateTeamGeneralSettings(teamId: string, settings: TeamGeneralSettingsDto) {
114
- const { businessName: name, ...generalSettings } = settings;
115
- try {
116
- await this.teamRepository.update(teamId, {
117
- name,
118
- generalSettings,
119
- });
120
- } catch (error) {
121
- throw new GenieException("Failed to update team general settings", {
122
- error,
123
- teamId,
124
- settings,
125
- });
126
- }
127
- }
128
- ```
129
-
130
- This method extracts the business name to the `name` column and stores other general settings in the JSON field `generalSettings`.
131
-
132
- ## API and Interfaces
133
-
134
- ### Key Methods in `SettingsService`
135
-
136
- | Method | Description | Input | Output |
137
- |-------------------------------|----------------------------------------------------|---------------------------------|----------------------------------|
138
- | `getTeamGeneralSettings` | Retrieves general team settings. | `teamId: string` | `TeamGeneralSettingsDto` |
139
- | `updateTeamGeneralSettings` | Updates general team settings. | `teamId: string`, `TeamGeneralSettingsDto` | void |
140
- | `getTeamInsightsSettings` | Retrieves team insights settings. | `teamId: string` | `InsightsSettingsDto` |
141
- | `updateTeamInsightsSettings` | Updates insights settings including grading configs.| `teamId: string`, `InsightsSettingsDto` | void |
142
- | `getShopSettings` | Retrieves the shop-level config like currency, timezone.| `teamId: string` | `GetShopSettingsResponseDto` |
143
- | `saveShopSettings` | Saves Shopify shop currency and time zone settings.| `teamId: string`, Optional Shopify webhook payload | void |
144
-
145
- ### Error Conditions
146
-
147
- - Unsupported inventory grading strategies throw a `GenieException`.
148
- - Any update failure results in a thrown exception with contextual info including the failing settings and team ID.
149
-
150
- ### Frontend Integration
151
-
152
- - Uses React Query hooks such as `useGetTeamGeneralSettingsQuery` and mutation hooks `useUpdateTeamGeneralSettingsMutation`.
153
- - UI includes controlled forms managing business details and Shopify sync status.
154
-
155
- ## Environment & Configuration
156
-
157
- ### Team Configuration Properties
158
-
159
- | Setting | Type | Description | Default / Validation |
160
- |------------------------------------|--------------------------|-----------------------------------------------------------|--------------------------------------|
161
- | `name` | string | Business name of the team. | Nullable, stored in `name` column. |
162
- | `generalSettings` | JSON object | Business address, VAT number, contact info, etc. | Stored in JSON column. |
163
- | `currency` | string | Team's accounting/display currency. | From Shopify, nullable. |
164
- | `timeZone` | string | IANA time zone identifier for the team/shop. | Default: `Etc/UTC`, validated against timezone list. |
165
- | `averageDailySalesPeriodDaysSetting` | integer Enum (7,30,60,90,180) | Period for sales averaging in analysis. | Default: 30 |
166
- | `inventoryItemGradingPeriodDaysSetting` | integer Enum | Period over which inventory grading is calculated. | Default: 30 |
167
- | `inventoryItemGradingStrategySetting` | Enum `InventoryItemGradingStrategy` | The strategy for inventory grading (e.g., SalesRevenue). | Default: `SalesRevenue`, `SalesFrequency` disallowed. |
168
- | `inventoryItemGradingLevelAThresholdSetting` | integer | Threshold % for grading level A. | Default: 80 |
169
- | `inventoryItemGradingLevelBThresholdSetting` | integer | Threshold % for grading level B. | Default: 15 |
170
- | `inventoryItemGradingLevelCThresholdSetting` | integer | Threshold % for grading level C. | Default: 5 |
171
- | `stockLevelsSettings` | JSON object | Settings for stock buffer, lead time, reorder frequency. | Defaults to leadTime=30, stockBuffer=10, reorderFrequency=EveryTwoMonths |
172
-
173
- ### Shopify Environment Integration
174
-
175
- - Shopify shop data such as currency and IANA time zone are pulled from webhook payloads or API calls.
176
- - Time zone validation is performed by `isValidTimeZone` utility.
177
- - If invalid or missing, time zone falls back to `Etc/UTC`.
178
-
179
- ### Local Development and Environment Setup
180
-
181
- - Environment variables managing database and Shopify credentials are outside the scope of this document.
182
- - Configuration for environment management likely handled in `ConfigModule` and `ConfigService` (referenced exports), but specific environment variables are not detailed here.
183
-
184
- ## Testing, Monitoring, and Deployment
185
-
186
- - Test details for settings service and UI are unspecified.
187
- - Error conditions raise `GenieException` logged with context for debugging.
188
- - Frontend mutation success triggers user notifications.
189
-
190
- ## Troubleshooting & Known Issues
191
-
192
- - Attempting to use the unsupported `SalesFrequency` grading strategy results in explicit exceptions.
193
- - Manual Shopify sync on the frontend has race-condition warnings (HTTP 409) if multiple syncs are attempted simultaneously.
194
-
195
-
196
- ---
197
-
198
- This document is aimed at backend and frontend developers managing and extending the Genie platform's environment and team settings system. It should serve as a guide for understanding configuration storage, validation, API design, and usage patterns for consistent, reliable environment configuration handling.