Code Quality

The most complex business logic is embedded in Mongoose pre/post hooks on models (especially Ledger, License, Invoice, Booking). This makes it:

• Hard to test — logic is tightly coupled to database operations
• Hard to debug — hooks fire implicitly, creating non-obvious side effects
• Hard to reason about — a single save() call can trigger chains of hooks across models

Example: The Ledger model's pre-save hook alone handles: currency derivation, org validation, permission checks, fund validation, wallet splitting, overflow logic, and parking wallet auto-creation.

Recommendation: Extract to explicit service layer functions that can be tested independently.

Three different auth mechanisms with unclear precedence:

1. Session-based — Express sessions with Redis store
2. API key — x-api-key header for service-to-service
3. JWT tokens — in query parameters for login flows

No unified authentication middleware enforces consistency or priority. Different routes use different mechanisms ad-hoc.

Despite being a monorepo with separate packages, the services share models directly via file paths. The openmembers package imports models from ../../models/ directly rather than going through the API.

Impact: Cannot deploy or test packages independently. Changes to models affect all services simultaneously.

packages/cron/cron.js

Schedule records store JavaScript code strings in the action field, executed at runtime via eval(). This is a code injection risk if the database is compromised, and makes it impossible to statically analyse what the cron system does.

The codebase lacks input validation middleware. req.body is passed directly to database operations without schema validation.

// CURRENT - no validation
const organisation = await req.apihelper.getOne("organisation", req.params.organisation_id);
if (!req.body.industrysector_id) { req.body.industrysector_id = [] }
await req.apihelper.put("organisation", req.session.user.organisation_id, req.body);

Recommendation: Add schema validation (Zod, Joi, or express-validator) at every API boundary.

Multiple patterns of poor error handling:

• packages/api/libs/messagequeue.js: console.error() with no re-throw (errors silently swallowed)
• packages/openmembers/routes/login.js: Generic error messages provide no debugging info
• packages/api/bin/server.js: MongoDB errors only logged, not handled

Errors may contain sensitive information in some paths, while being swallowed entirely in others.

Secrets are sourced from at least four different locations with no centralised management:

Source	Usage
config.secret	Session encryption in some modules
config.openmembers.secret	OpenMembers-specific encryption
process.env.APIKEY	API authentication in some routes
JSON keyfiles on disk	Google Cloud credentials

No rotation mechanism exists for any of these secrets.

The platform uses three different frontend approaches:

• Handlebars — server-rendered templates (OpenMembers, CRM)
• Svelte — Xero integration, Doors module
• Vue 2 — POS, some components

This creates cognitive overhead for developers and inconsistent user experiences.

• PhantomJS 2.1.16 — deprecated headless browser, used for PDF generation
• Node 8 "carbon" — in OpenMembers Dockerfile (EOL Dec 2019)
• Node 16 — in API Dockerfile (EOL Sept 2023)
• Vue 2 — end of life (Dec 2023)
• Requires --openssl-legacy-provider flag for Webpack builds

For a platform of this size and complexity, the test suite is notably sparse:

• ~9 test files total across the entire codebase
• API tests cover basic CRUD and login only
• No security-focused tests (auth bypass, injection, etc.)
• No integration tests for complex workflows (invoice run, booking lifecycle)
• Selenium tests exist but cover limited UI scenarios
• No tests for the wallet/ledger deduction logic (the most complex code)

What exists:

Suite	Command	Scope
API	yarn test:api	Basic CRUD, login
OpenMembers	yarn test:openmembers	Limited
Shared	yarn test:shared	Shared utilities
Reports	yarn test:reports	Report generation
Selenium	yarn test:selenium	Basic UI flows