@cdmbase/wiki-browser 12.0.18-alpha.5

package/lib/templates/content/docs/adminide-modules/billing/payments/index.md

@@ -0,0 +1,14 @@
+---
+meta:
+    title: Payments
+    description: Payments
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Payments...
+headers:
+    Cache-Control: no-cache
+---
+
+## Payments
+
+**[Stripe](/docs/payments/stripe)**

package/lib/templates/content/docs/adminide-modules/billing/payments/stripe/index.md

@@ -0,0 +1,14 @@
+---
+meta:
+    title: Stripe
+    description: Stripe
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Stripe...
+headers:
+    Cache-Control: no-cache
+---
+
+## Stripe
+
+**[Setting up stripe locally](/docs/payments/stripe/settingup-stripe-locally)**

package/lib/templates/content/docs/adminide-modules/billing/payments/stripe/settingup-stripe-locally.md

@@ -0,0 +1,25 @@
+---
+meta:
+    title: Setting up stripe locally
+    description: Setting up stripe locally
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Setting up stripe locally...
+headers:
+    Cache-Control: no-cache
+---
+
+### Handling requests from Stripe
+
+We use `webhooks` to listen to stripe event that required to update the flow in our backend. For this
+we need to make sure to run the webhook locally.
+
+In our node server, we listen to webhook events at `/webhook/stripe` so the url will be `<backend_url>/webhook/stripe`
+
+Follow the steps in the https://stripe.com/docs/webhooks/quickstart go to the section `Test the webhook`.
+
+1. Update the webhook in the Stripe Developer console to it. For example `http://localhost:8080/webhook/stripe`
+
+2. Download stripe cli and login to it
+
+3. Now perform any plan subscription in the billing to check events are used in the node environment.

package/lib/templates/content/docs/adminide-modules/billing/tier-config.md

@@ -0,0 +1,293 @@
+# Billing Tier Config
+
+The Billing Config Page allows you to configure pricing plans, features, and UI settings for your projects. This page has been updated to store billing configuration data at the project level.
+
+## Overview
+
+Previously, billing plans and features were stored under organization settings. The system now stores new and updated plans and features under **project metadata**, allowing for project-specific billing configurations.
+
+## Architecture Changes
+
+### Previous Implementation
+
+Billing plans were stored using organization-level settings:
+
+- Plans were saved using `writeSettingsMutation` with organization resource URI
+- Configuration was stored in organization settings with `ConfigFragmentName.SubscriptionPlan`
+- Plans were scoped to the entire organization
+
+### Current Implementation
+
+Billing plans and features are now stored in **project metadata**:
+
+- Plans are saved using `updateProjectMetadata` mutation
+- Configuration is stored in `project.source.metadata.subscriptionPlans`
+- Features are stored in `project.source.metadata.products`
+- Each project can have its own billing configuration
+
+## Data Structure
+
+### Project Metadata Structure
+
+Billing configuration is stored in the project's `source.metadata` field:
+
+```json
+{
+    "source": {
+        "metadata": {
+            "subscriptionPlans": {
+                "basic-1766780856401": {
+                    "id": "basic-1766780856401",
+                    "planName": "Basic",
+                    "description": "Basic plan description",
+                    "price": {
+                        "monthly": 9.99,
+                        "yearly": 99.99
+                    },
+                    "interval": "monthly",
+                    "popular": false,
+                    "features": {
+                        "feature-id": {
+                            "units": 10
+                        }
+                    }
+                }
+            },
+            "products": {
+                "feature-id": {
+                    "id": "feature-id",
+                    "name": "Feature Name",
+                    "description": "Feature description",
+                    "billingInterval": "monthly",
+                    "pricePerUnit": 5.0,
+                    "pricePerUnitYearly": 50.0,
+                    "unitLabel": "units",
+                    "unitSize": 1,
+                    "stripeMetadata": {}
+                }
+            }
+        }
+    }
+}
+```
+
+## How It Works
+
+### 1. Project Selection
+
+The billing configuration page requires selecting a project before making changes:
+
+- Users must select a project from the project selector dropdown
+- Configuration is scoped to the selected project
+- Each project maintains its own billing configuration
+
+### 2. Data Merging
+
+The system merges default plans/features from policies with project-specific overrides:
+
+1. **Default Plans**: Fetched from subscription plan policies (Basic, Premium, Enterprise)
+2. **Policy Plans**: Merged with subscription plan defaults
+3. **Project Overrides**: Project-specific plans in `project.source.metadata.subscriptionPlans` override defaults
+4. **New Plans**: Plans added at project level are included in the merged result
+
+### 3. Saving Plans
+
+When saving a pricing tier:
+
+```typescript
+await updateProjectMetadata({
+    variables: {
+        where: { id: projectId },
+        metadata: {
+            subscriptionPlans: {
+                ...existingPlans,
+                [planId]: {
+                    id: planId,
+                    planName: 'Plan Name',
+                    description: 'Description',
+                    price: { monthly: 9.99, yearly: 99.99 },
+                    interval: 'monthly',
+                    popular: false,
+                    // ... other plan properties
+                },
+            },
+        },
+    },
+});
+```
+
+### 4. Saving Features
+
+When saving a feature:
+
+```typescript
+await updateProjectMetadata({
+    variables: {
+        where: { id: projectId },
+        metadata: {
+            products: {
+                ...existingProducts,
+                [featureId]: {
+                    id: featureId,
+                    name: 'Feature Name',
+                    description: 'Feature description',
+                    billingInterval: 'monthly',
+                    pricePerUnit: 5.0,
+                    pricePerUnitYearly: 50.0,
+                    unitLabel: 'units',
+                    unitSize: 1,
+                    stripeMetadata: {},
+                },
+            },
+        },
+    },
+});
+```
+
+### 5. Deleting Plans/Features
+
+To delete a plan or feature, set its value to `null` in the metadata:
+
+```typescript
+// Delete a plan
+await updateProjectMetadata({
+    variables: {
+        where: { id: projectId },
+        metadata: {
+            subscriptionPlans: {
+                ...existingPlans,
+                [planId]: null,
+            },
+        },
+    },
+});
+
+// Delete a feature
+await updateProjectMetadata({
+    variables: {
+        where: { id: projectId },
+        metadata: {
+            products: {
+                ...existingProducts,
+                [featureId]: null,
+            },
+        },
+    },
+});
+```
+
+## GraphQL Mutation
+
+The `updateProjectMetadata` mutation is used to save billing configuration:
+
+```graphql
+mutation UpdateProjectMetadata($where: ProjectWhereInput!, $metadata: JSON!) {
+    updateProjectMetadata(where: $where, metadata: $metadata) {
+        id
+        name
+        source {
+            metadata
+        }
+    }
+}
+```
+
+### Parameters
+
+- `where`: Project identification (typically `{ id: "project-id" }`)
+- `metadata`: JSON object containing `subscriptionPlans` and/or `products`
+
+## Backend Implementation
+
+### Project Service
+
+The backend `ProjectService` includes a new method `updateProjectMetadata`:
+
+```typescript
+public async updateProjectMetadata(
+    where: IProjectWhereInput,
+    metadata: Record<string, unknown>,
+    orgId: string,
+): Promise<AsDomainType<IProjectModel>> {
+    const project = await this.get(where);
+    if (!project) {
+        throw new Error(`Project not found: ${JSON.stringify(where)}`);
+    }
+
+    const currMetadata = cloneDeep(project.source?.metadata || {});
+    const newMetadata = merge(currMetadata, metadata);
+    return this.projectRepository.updateProject(where, { source: { metadata: newMetadata } }, orgId);
+}
+```
+
+This method:
+
+- Retrieves the current project
+- Merges new metadata with existing metadata (deep merge)
+- Updates the project with merged metadata
+
+### GraphQL Schema
+
+The GraphQL schema includes the mutation:
+
+```graphql
+extend type Mutation {
+    """
+    Update a project's metadata
+    """
+    updateProjectMetadata(where: ProjectWhereInput!, metadata: JSON!): Project
+        @addAccountContext
+        @invalidateCache(queries: ["getProjects", "getFilteredProjects"])
+}
+```
+
+## Usage Example
+
+### Fetching Billing Configuration
+
+```typescript
+// Fetch project with metadata
+const { data } = useGetProjectsMinimalQuery({
+    variables: {
+        where: { id: projectId },
+    },
+});
+
+// Access billing plans
+const plans = data?.projects[0]?.source?.metadata?.subscriptionPlans || {};
+
+// Access features
+const features = data?.projects[0]?.source?.metadata?.products || {};
+```
+
+### Updating Billing Configuration
+
+```typescript
+const [updateProjectMetadata] = useUpdateProjectMetadataMutation();
+
+// Update a plan
+await updateProjectMetadata({
+    variables: {
+        where: { id: projectId },
+        metadata: {
+            subscriptionPlans: {
+                ...currentPlans,
+                [planId]: updatedPlanData,
+            },
+        },
+    },
+});
+```
+
+## Benefits
+
+1. **Project-Specific Configuration**: Each project can have its own billing plans and features
+2. **Flexibility**: Different projects can have different pricing structures
+3. **Isolation**: Changes to one project's billing don't affect others
+4. **Scalability**: Supports multi-tenant scenarios where each project is a tenant
+
+## Related Documentation
+
+- [Configuration System](/docs/preferences/Configuration) - General configuration system overview
+- [Machine Configuration](/docs/preferences/machine-configuration) - Entity-level configuration patterns
+- [Project Templates](/docs/projects/templates) - Project template system

package/lib/templates/content/docs/adminide-modules/connectors/Connector.md

@@ -0,0 +1,207 @@
+# Application Connectors - OAuth Integration Flow
+
+This document explains how users connect third-party services like Gmail to the platform.
+
+## How It Works
+
+The connector system uses OAuth 2.0 with PKCE to securely connect external services. When a user connects their Gmail account, we don't store their password. Instead, we get permission tokens directly from Google that allow us to access their account on their behalf.
+
+Tokens are stored securely in our vault service, scoped to the user's selected project and environment.
+
+---
+
+## The Connect Flow
+
+```
+┌──────────────┐      ┌──────────────┐      ┌──────────────┐      ┌──────────────┐
+│    User      │      │   Platform   │      │    Google    │      │    Vault     │
+└──────┬───────┘      └──────┬───────┘      └──────┬───────┘      └──────┬───────┘
+       │                     │                     │                     │
+       │  1. Click Connect   │                     │                     │
+       │────────────────────>│                     │                     │
+       │                     │                     │                     │
+       │                     │  2. Generate secure │                     │
+       │                     │     state & verifier│                     │
+       │                     │                     │                     │
+       │  3. Open Google     │                     │                     │
+       │     sign-in popup   │                     │                     │
+       │<────────────────────│                     │                     │
+       │                     │                     │                     │
+       │  4. Sign in and     │                     │                     │
+       │     grant access    │                     │                     │
+       │─────────────────────────────────────────>│                     │
+       │                     │                     │                     │
+       │                     │  5. Google sends    │                     │
+       │                     │     auth code back  │                     │
+       │                     │<────────────────────│                     │
+       │                     │                     │                     │
+       │                     │  6. Exchange code   │                     │
+       │                     │     for tokens      │                     │
+       │                     │────────────────────>│                     │
+       │                     │                     │                     │
+       │                     │  7. Receive access  │                     │
+       │                     │     & refresh token │                     │
+       │                     │<────────────────────│                     │
+       │                     │                     │                     │
+       │                     │  8. Store tokens    │                     │
+       │                     │     securely        │                     │
+       │                     │─────────────────────────────────────────>│
+       │                     │                     │                     │
+       │  9. Show connected  │                     │                     │
+       │<────────────────────│                     │                     │
+       │                     │                     │                     │
+```
+
+---
+
+## Step-by-Step: Connecting Gmail
+
+### 1. User Opens Connectors Page
+
+The user navigates to the Connectors page where they see a list of available integrations. Each connector shows whether it's already connected or available to connect.
+
+### 2. User Selects Project and Environment
+
+Before connecting any service, the user must select which project and environment the connection belongs to. This determines where the access tokens will be stored and which part of the application can use them.
+
+### 3. User Clicks "Connect" on Gmail
+
+A confirmation modal appears. The user clicks "Connect" to proceed.
+
+### 4. Platform Prepares the Authorization
+
+Behind the scenes, the platform:
+
+- Generates a unique security code (state) to prevent attacks
+- Creates a PKCE verifier for additional security
+- Temporarily saves this information so we can match it when Google responds
+- Builds the Google authorization URL with all required parameters
+
+### 5. Google Sign-in Popup Opens
+
+A popup window opens showing Google's sign-in page. The user enters their Google credentials and sees what permissions the app is requesting (read emails, send emails, etc.).
+
+### 6. User Grants Permission
+
+The user clicks "Allow" to grant the requested permissions. Google then redirects the popup back to our callback page with an authorization code.
+
+### 7. Callback Page Receives the Code
+
+Our callback page receives the authorization code from Google. It retrieves the security information we saved earlier and sends everything to the backend.
+
+### 8. Platform Exchanges Code for Tokens
+
+The backend contacts Google directly and exchanges the authorization code for actual access tokens. This happens server-to-server, keeping everything secure.
+
+### 9. Tokens Are Stored in Vault
+
+The access token and refresh token are stored in our secure vault, associated with the user's selected project and environment. The connector record is created in the database.
+
+### 10. Success!
+
+The popup closes and the Connectors page updates to show Gmail as "Connected".
+
+---
+
+## The Disconnect Flow
+
+```
+┌──────────────┐      ┌──────────────┐      ┌──────────────┐      ┌──────────────┐
+│    User      │      │   Platform   │      │    Google    │      │    Vault     │
+└──────┬───────┘      └──────┬───────┘      └──────┬───────┘      └──────┬───────┘
+       │                     │                     │                     │
+       │  1. Click           │                     │                     │
+       │     Disconnect      │                     │                     │
+       │────────────────────>│                     │                     │
+       │                     │                     │                     │
+       │                     │  2. Get tokens      │                     │
+       │                     │     from vault      │                     │
+       │                     │<─────────────────────────────────────────│
+       │                     │                     │                     │
+       │                     │  3. Revoke tokens   │                     │
+       │                     │     with Google     │                     │
+       │                     │────────────────────>│                     │
+       │                     │                     │                     │
+       │                     │  4. Delete tokens   │                     │
+       │                     │     from vault      │                     │
+       │                     │─────────────────────────────────────────>│
+       │                     │                     │                     │
+       │                     │  5. Delete          │                     │
+       │                     │     connector record│                     │
+       │                     │                     │                     │
+       │  6. Show            │                     │                     │
+       │     disconnected    │                     │
+       │<────────────────────│                     │                     │
+       │                     │                     │                     │
+```
+
+---
+
+## Step-by-Step: Disconnecting Gmail
+
+### 1. User Clicks "Disconnect"
+
+On the Connectors page, the user clicks the "Disconnect" button on their connected Gmail integration. A confirmation modal appears.
+
+### 2. User Confirms
+
+The user confirms they want to disconnect. This action cannot be undone - they'll need to reconnect if they want to use the integration again.
+
+### 3. Platform Retrieves Stored Tokens
+
+The backend retrieves the access and refresh tokens from the vault for this connector.
+
+### 4. Tokens Are Revoked with Google
+
+The platform contacts Google to revoke the tokens. This invalidates them immediately - even if someone had copied the tokens, they would no longer work.
+
+### 5. Tokens Are Deleted from Vault
+
+Both the access token and refresh token are permanently deleted from our vault.
+
+### 6. Connector Record Is Deleted
+
+The connector record is removed from the database.
+
+### 7. Done
+
+The UI updates to show Gmail as available to connect again.
+
+---
+
+## Security Measures
+
+**PKCE (Proof Key for Code Exchange)**
+Every authorization request includes a unique cryptographic challenge. This prevents attackers from intercepting the authorization code and using it themselves.
+
+**State Parameter**
+A random string is generated for each connection attempt. When Google redirects back, we verify this matches what we sent. This prevents cross-site request forgery attacks.
+
+**Temporary State Storage**
+The security information needed during authorization is stored temporarily and automatically deleted after 10 minutes. This ensures no sensitive data lingers if a connection attempt is abandoned.
+
+**Vault Storage**
+Tokens are never stored in plain text in the database. They're kept in our secure vault service, encrypted and access-controlled.
+
+**Token Revocation**
+When disconnecting, we don't just delete our copy of the tokens - we also tell Google to invalidate them. This ensures complete disconnection.
+
+---
+
+## What Gets Stored Where
+
+**In the Vault (Encrypted)**
+
+- Access Token - used to make API calls to Google
+- Refresh Token - used to get new access tokens when they expire
+
+**In the Database**
+
+- Connector metadata (which service, when connected, status)
+- Reference IDs pointing to the vault secrets
+- Token expiration information
+- Which project and environment the connector belongs to
+
+**Temporarily During Connect**
+
+- OAuth state and security codes (auto-deleted after 10 minutes)

package/lib/templates/content/docs/adminide-modules/file-upload/index.md

@@ -0,0 +1,16 @@
+---
+meta:
+    title: File Upload
+    description: File Upload
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: File Upload...
+headers:
+    Cache-Control: no-cache
+---
+
+## File Upload
+
+**[Setup](/docs/file-upload/setup)**
+
+**[File Uploads](/docs/file-upload/upload-file-using-signed-url)**