@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.
- package/README.md +1 -1
- package/docs/api-playground-demo.mdx +119 -0
- package/docs/api-reference/openapi.json +366 -0
- package/docs/api-reference/operations/create.mdx +5 -0
- package/docs/api-reference/operations/delete.mdx +5 -0
- package/docs/api-reference/operations/get.mdx +5 -0
- package/docs/api-reference/operations/update.mdx +5 -0
- package/docs/assets/dory.jpeg +0 -0
- package/docs/dory.json +12 -131
- package/docs/favicon.svg +75 -0
- package/docs/features.mdx +440 -0
- package/docs/introduction.mdx +44 -0
- package/docs/logo/logo.png +0 -0
- package/package.json +9 -10
- package/src/mdx/fence.tsx +2 -1
- package/src/mdx/mermaid.tsx +39 -11
- package/src/mdx/source.tsx +15 -4
- package/docs/README.md +0 -2
- package/docs/configuration/app-settings/feature-flags.mdx +0 -157
- package/docs/configuration/app-settings/user-settings.mdx +0 -201
- package/docs/configuration/installation-setup/env-vars.mdx +0 -198
- package/docs/configuration/installation-setup/installation.mdx +0 -127
- package/docs/integrations/analytics-monitoring/error-tracking.mdx +0 -199
- package/docs/integrations/analytics-monitoring/notifications.mdx +0 -189
- package/docs/integrations/analytics-monitoring/user-analytics.mdx +0 -182
- package/docs/integrations/shopify-integration/shopify-setup.mdx +0 -226
- package/docs/integrations/shopify-integration/shopify-webhooks.mdx +0 -207
- package/docs/overview/developer-overview/dev-architecture.mdx +0 -292
- package/docs/overview/product-intro/app-overview.mdx +0 -167
- package/docs/overview/product-intro/architecture.mdx +0 -203
- package/docs/overview/product-intro/core-concepts.mdx +0 -267
- package/docs/platform-admin/billing-subscriptions/billing.mdx +0 -176
- package/docs/platform-admin/system-maintenance/db-migrations.mdx +0 -184
- package/docs/platform-admin/system-maintenance/health-monitoring.mdx +0 -222
- package/docs/platform-admin/system-maintenance/queue-management.mdx +0 -234
- package/docs/platform-admin/user-team-management/teams.mdx +0 -170
- package/docs/platform-admin/user-team-management/users.mdx +0 -185
- package/docs/support/legal/dependency-analysis.mdx +0 -132
- package/docs/support/legal/privacy-terms.mdx +0 -73
- package/docs/support/troubleshooting/common-issues.mdx +0 -159
- package/docs/usage/api-usage/api-inventory.mdx +0 -213
- package/docs/usage/api-usage/api-products.mdx +0 -249
- package/docs/usage/api-usage/api-purchase-orders.mdx +0 -289
- package/docs/usage/api-usage/api-reports.mdx +0 -227
- package/docs/usage/api-usage/api-suppliers.mdx +0 -171
- package/docs/usage/api-usage/api-user-management.mdx +0 -171
- package/docs/usage/ui-workflows/bundles.mdx +0 -157
- package/docs/usage/ui-workflows/demand-planning.mdx +0 -210
- package/docs/usage/ui-workflows/favorites.mdx +0 -167
- package/docs/usage/ui-workflows/inventory-management.mdx +0 -179
- package/docs/usage/ui-workflows/onboarding.mdx +0 -215
- package/docs/usage/ui-workflows/purchase-orders.mdx +0 -200
- 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.
|