Skip to content

Operations & Infrastructure -- Gap Analysis

Date: 2026-03-22 Source documents: doc/operations/ (observability/, scalability/, build-and-ci/), doc/developer/ (code-quality/, frontend/)

Implemented

  • Horizontal scalability: HikariCP connection pooling, Hazelcast session clustering, health/readiness endpoints
  • Code quality: API exception handling refactoring (completed 2026-01-21), multithreading review (completed 2026-02-19)
  • Shared component library: tqpro-components.js file created
  • OIDC authentication: Steps 1-2 complete (JWT validation, hybrid mode)

Gaps

1. Observability -- Prometheus & Grafana (HIGH)

Source: observability/requirements.md, observability/prometheus-grafana-setup.md, observability/plugin-requirements.md

The entire observability stack is planned but not implemented: - No Micrometer dependencies in any build.gradle.kts - No MetricsFilter or MetricsApi endpoint (/metrics) - No Prometheus container or prometheus.yml scrape config - No Grafana container or dashboard JSON files - No alert rules configured - No plugin-level metrics (Amadeus, Rayna, GoGlobal, Tiqets call timing, DB query performance) - prometheus-grafana-setup.md is explicitly marked "Implementation Planned"

2. Containerization -- Dockerfile (HIGH)

Source: scalability/containerization.md, scalability/kubernetes-deployment.md

  • No Dockerfile exists anywhere in the project for the TQPro API server
  • No application-level docker-compose.yaml (only Keycloak/oauth2-proxy infra exists)
  • All K8s phases are unchecked in the document

3. Kubernetes Deployment Manifests (MEDIUM)

Source: scalability/kubernetes-deployment.md

Full K8s manifest specification exists (Deployment, Service, ConfigMap, Secret, HPA, RBAC, PVC) but no YAML manifests have been created. The Hazelcast discovery still uses TCP-IP with 127.0.0.1 instead of K8s service-DNS discovery.

4. CI/CD Pipeline -- TeamCity (MEDIUM)

Source: build-and-ci/build-strategy.md, build-and-ci/teamcity-setup.md

The entire CI/CD pipeline is documented but not built: - No TeamCity DSL files or .teamcity/ directory - No Jenkinsfile or GitHub Actions workflows - No Flyway database migration plugin (org.flywaydb.flyway) in build configuration - No automated deployment scripts (S3 upload, rsync) - Actual migration strategy (sequential numbered .sql files applied manually) differs from what the CI docs specify (Flyway V###__description.sql versioning)

Status (2026-04-14): IN PROGRESS — .teamcity/src/TeamCityBuildTemplateWithDeployment.kt now exists with Gradle-build + file-copy deployment DSL, and a first Flyway-style migration config/migrations/V20260221__add_currency_rates_to_tripgroup.sql has been added. Still missing: Flyway plugin in build.gradle.kts, full migration strategy rollout across the existing sequential .sql files, and automated S3/rsync deployment scripts.

5. Frontend Testing -- Robot Framework (MEDIUM)

Source: developer/frontend/testing.md

Complete guide for Robot Framework 7.1.1 + SeleniumLibrary setup exists but: - No .robot test files anywhere in the project - No requirements-test.txt file - No tests/ directory at the project root - Zero automated frontend test coverage

6. Frontend UX -- Phase 3 & 4 Incomplete (MEDIUM)

Source: developer/frontend/ux-implementation-plan.md, developer/frontend/ux-recommendations.md

Phase 2 (shared component library): tqpro-components.js created but per-module integration across Hotel, Cruise, Visa, TripMaker is incomplete.

Phase 3 (navigation overhaul): Header dropdown restructuring, breadcrumb system -- no completion marker in the plan.

Phase 4 remaining items (no completion markers): - 4.1: Dashboard live KPI API endpoints, clickable cards, Quick Actions bar - 4.2: TripMaker -- activity date/time fields, edit/remove, PDF generation button, real auto-save, status transitions - 4.3: Visa Management -- supplier dropdown, Invoice & Payment wizard step, backend API stubs - 4.4: Cruise exchange rate (currently hardcoded to 1.0)

7. OIDC Migration Steps 3-5 (LOW)

Source: developer/frontend/ux-implementation-plan.md section 4.7

Steps 1-2 complete (JWT validation, hybrid auth mode). Remaining: - Step 3: Switch to auth-mode=native-oidc - Step 4: Remove oauth2-proxy dependency - Step 5: Clean up legacy auth code

Explicitly marked PENDING in the document.

Status (2026-04-14): IN PROGRESS — config/tlinqapi.properties:73 is set to auth-mode=hybrid, confirming steps 1-2 are live (JWT validation + hybrid auth). Steps 3-5 (switch to native-oidc, remove oauth2-proxy, clean up legacy auth code) are still pending.

8. Odoo Plugin: Migrate from XML-RPC to JSON-RPC (MEDIUM)

Source: TQ-19 payment flow debugging

The Odoo plugin (tqodoo) uses Apache XML-RPC to communicate with Odoo. Odoo's own web UI uses JSON-RPC (/web/dataset/call_kw). XML-RPC has limitations: - Cannot marshal None return values without patching Odoo's core (allow_none=True in rpc.py) - Less performant than JSON-RPC for complex data structures - Odoo's XML-RPC endpoint is a legacy interface with less testing and support

Migrating OdooClientService and OdooServiceFactory to use JSON-RPC (/web/dataset/call_kw) would align with how Odoo itself operates and eliminate the None marshalling issue without requiring Odoo core patches.

Workaround applied: One-line patch in Odoo core (odoo/addons/base/controllers/rpc.py line 128: allow_none=True), plus NilAwareTypeFactory on the Java client side.

9. Externalize ERP Payment Configuration (HIGH)

Source: TQ-19 payment flow — FK constraint on hardcoded payment method line ID

OdooPaymentReg.java hardcodes ERP-specific IDs: TELR_JOURNAL = 16, PMT_IN_TELR_MANUAL = 39, CASH_JOURNAL = 6, BANK_JOURNAL = 7, PMT_IN_BANK_MANUAL = 3. These are Odoo database record IDs that can change when journals or payment methods are reconfigured, causing FK constraint errors at runtime.

These values must be externalized to configuration (e.g., odoo-client.properties or a dedicated payment config) so they can be updated without code changes. Ideally, the system should look up journal/payment method by name or code rather than by database ID.