ti2 1.0.109 → 1.0.111

package/controllers/graphql-schemas/itinerary-booking.js

@@ -1,3 +1,6 @@
+/**
+ * SDL + document for ti2 plugins
+ */
 const typeDefs = `
   type Passenger {
     firstName: String
@@ -16,8 +19,15 @@ const typeDefs = `
     passengers: [Passenger]
   }
 
+  type PuDoInfo {
+    date: String
+    time: String
+    remarks: String
+  }
+
   type ServiceLine {
     serviceLineId: ID!
+    serviceLineUpdateCount: Int
     optionId: String!
     optionName: String
     linePrice: String
@@ -28,14 +38,20 @@ const typeDefs = `
     paxList: [Passenger]
     paxConfigs: [PaxConfig]
     status: String
+    puInfo: PuDoInfo
+    doInfo: PuDoInfo
   }
 
   type Query {
     bookingId: ID!
     name: String!
     bookingStatus: String
+    bookingStatusId: String
+    isBooking: Boolean
+    bookingAgent: String
     ref: String!
     agentRef: String
+    agentId: String
     totalPrice: String!
     currency: String!
     travelDate: String!
@@ -49,8 +65,12 @@ const query = `{
   name
   bookingId
   bookingStatus
+  bookingStatusId
+  isBooking
+  bookingAgent
   ref
   agentRef
+  agentId
   totalPrice
   currency
   travelDate
@@ -58,15 +78,25 @@ const query = `{
   canEdit
   serviceLines {
     serviceLineId
+    serviceLineUpdateCount
     linePrice
     quantity
     optionId
     optionName
     supplierId
     supplierName
-    supplierId
     startDate
     status
+    puInfo {
+      date
+      time
+      remarks
+    }
+    doInfo {
+      date
+      time
+      remarks
+    }
     paxConfigs {
       roomType
       adults

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ti2",
-  "version": "1.0.109",
+  "version": "1.0.111",
   "description": "Tourist Industry Exchange (TI2)",
   "main": "index.js",
   "scripts": {

package/.windsurfrules

@@ -1,9 +0,0 @@
-This is a Node.js project using Sequelize for database operations and Express.js for the web server.
-The API is defined in api.yml using OpenAPI 3.0.2
-The database is defined in models/index.js
-The models are defined in models/
-to run tests you have to run them on the ti2 named docker container, and consider this codebase is part of node_modules/ti2 path for example : 
-`` $ docker exec ti2 bash -c "cd /ti2 && npx jest lib/__tests__/callback.js --forceExit"``
-When writing / editing tests, make use of test/utils.js and review their implementation to understand how to mock the environment.
-Do not make any changes until you 95% confident of the changes you want to make, ask follow up questions until you have that confidence.
-when sending jobs to the background worker using the queue, asssume a worker is always runing to execute it but is on a different instance thread, so to review / wait for jobs we have to use the wokrer/queue.js listJobs fn to check for it

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.