ti2 1.0.115 → 1.0.118

package/CLAUDE.md

@@ -1,159 +0,0 @@
-# CLAUDE.md
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-## Project Overview
-
-Ti2 (Tourism Information Interchange) is an open-source integration framework for the tourism industry. It provides standardized functions for bookings, content, and rates management through a plugin-based architecture.
-
-## Critical Development Rules
-
-1. **Docker Container Execution**: ALL commands must be run inside the `ti2` Docker container
-   - The codebase is located at `/ti2` path inside the container
-   - This project is part of `node_modules/ti2` in the container environment
-   - **NEVER run npm, node, or npx commands on the host machine**
-   - Always use: `docker exec ti2 bash -c "cd /ti2 && <command>"`
-   - Example for npm install: `docker exec ti2 bash -c "cd /ti2 && npm install <package>"`
-
-2. **Testing Rules**:
-   - Tests MUST be run inside the Docker container
-   - Example: `docker exec ti2 bash -c "cd /ti2 && npx jest lib/__tests__/callback.js --forceExit"`
-   - Use `test/utils.js` for mocking the environment
-   - Review test utility implementations before writing/editing tests
-
-3. **Background Jobs**:
-   - Jobs sent to the queue run on a separate worker thread/instance
-   - Use `worker/queue.js` `listJobs` function to check job status
-   - Workers are always assumed to be running
-
-4. **Code Confidence**: Do not make changes until 95% confident. Ask follow-up questions if uncertain.
-
-## Common Development Commands
-
-```bash
-# Run tests (inside Docker container)
-docker exec ti2 bash -c "cd /ti2 && npm test"
-docker exec ti2 bash -c "cd /ti2 && npx jest [test-file] --forceExit"
-
-# Run specific test file
-docker exec ti2 bash -c "cd /ti2 && npx jest controllers/__tests__/bookings.js --forceExit"
-
-# Database migrations
-docker exec ti2 bash -c "cd /ti2 && npm run sequelize db:migrate"
-
-# Generate documentation
-docker exec ti2 bash -c "cd /ti2 && npm run doc"
-```
-
-## Architecture
-
-### Core Components
-
-1. **Main Entry Point** (`index.js`):
-   - Initializes Express server on port 10010 (default)
-   - Sets up Swagger documentation at `/api-docs`
-   - Handles plugin instantiation and middleware
-   - Implements caching mechanism
-   - Manages background job processing via `worker/queue.js`
-
-2. **API Definition** (`api.yml`):
-   - OpenAPI 3.0.0 specification
-   - Defines all endpoints and schemas
-   - JWT Bearer authentication
-
-3. **Plugin System**:
-   - Two types: Integration Plugins (connect systems) and App Plugins (value-added tools)
-   - Plugins are instantiated with cache, axios, events, and configuration
-   - Plugin schemas are merged with main API schema
-   - Each plugin gets its own routes under `/apps/{pluginName}`
-
-4. **Controllers** (`controllers/`):
-   - `app.js`: Core application controller
-   - `bookings.js`: Booking operations (searchProducts, createBooking, etc.)
-   - `admin.js`: Administrative functions
-   - `user.js`: User management
-   - `ping.js`: Health check endpoints
-   - `allotment.js`: Allotment management
-
-5. **Database Models** (`models/`):
-   - Sequelize ORM with MySQL
-   - Key models: Integration, User, UserAppKey, CronJobs, ApiCronJobs
-   - Migrations in `migrations/` directory
-
-6. **Worker System** (`worker/`):
-   - Bull queue for background job processing
-   - Redis-backed job queue
-   - Supports plugin jobs, API jobs, and callback jobs
-   - Multi-worker support with throng
-
-7. **Authentication** (`auth/authHandler.js`):
-   - JWT-based authentication
-   - Bearer token scheme
-
-### Key Features
-
-- **Caching**: Redis-based caching with configurable TTL
-- **Event System**: EventEmitter2 for plugin communication
-- **Background Jobs**: Async job processing with Bull/Redis
-- **Cron Jobs**: Scheduled task execution
-- **Multi-tenancy**: Support for multiple integrations/plugins
-
-### Plugin Development
-
-Plugins must implement standard methods:
-- `validateToken`: Token validation
-- `tokenTemplate`: Token configuration template
-- Booking methods: `searchProducts`, `searchAvailability`, `createBooking`, `cancelBooking`
-- Content methods: `getProducts`, `getProduct`, `createProduct`, `updateProduct`
-
-### Testing Strategy
-
-- Jest testing framework
-- Test fixtures in `__fixtures__/`
-- Mock plugins in `__mocks__/`
-- Use `test/utils.js` for creating test environments
-- Tests organized by controller in `controllers/__tests__/`
-
-## Database
-
-- Sequelize ORM with MySQL/MariaDB
-- Connection managed through `models/db.js`
-- Migrations handled via sequelize-cli
-- Models auto-loaded from `models/` directory
-
-## Environment Variables
-
-Key variables:
-- `PORT`: Server port (default: 10010)
-- `REDIS_URL`: Redis connection (default: redis://redis:6379)
-- `jwtSecret`: JWT signing secret
-- `adminKey`: Admin authentication key
-- `WEB_CONCURRENCY`: Number of workers
-- `MAX_JOBS_PER_WORKER`: Job concurrency per worker
-- `SSL_INSECURE_ALLOWED_DOMAINS`: Pipe-separated list of domains where SSL certificate verification is skipped (e.g., `localhost|staging.example.com|192.168.1.100`)
-
-Plugin-specific variables follow pattern: `ti2_{pluginName}_{setting}`
-
-### SSL Configuration
-
-The `SSL_INSECURE_ALLOWED_DOMAINS` environment variable allows you to specify domains where SSL certificate verification should be skipped. This is useful for:
-- Development environments with self-signed certificates
-- Testing against staging servers with invalid certificates
-- Local development with HTTPS
-
-Example usage:
-```bash
-# Skip SSL verification for specific domains
-export SSL_INSECURE_ALLOWED_DOMAINS="localhost|staging.api.com|192.168.1.100"
-
-# Multiple domains separated by pipe
-export SSL_INSECURE_ALLOWED_DOMAINS="dev.example.com|test.example.com"
-```
-
-**Important Implementation Notes**:
-- SSL configuration is ONLY applied to plugin axios instances (for external API calls) and worker axios instances
-- Internal communication (callbacks, per-request axios) do NOT use SSL configuration  
-- SSL configuration uses a per-request interceptor approach for better isolation
-- The configuration checks domains dynamically on each request
-
-**Warning**: Only use this in development/testing environments. Never skip SSL verification in production for security reasons.