Work Report — 2026-05-25 to 2026-06-08
Period: 2026-05-25 to 2026-06-08 Generated: 2026-06-08
Summary
The dominant theme of this period was security: a coordinated hardening sprint touched six backend services simultaneously, closing two separate credential-exposure vulnerabilities before they could be exploited. Alongside that, a soft-delete mechanism was delivered for clinical data models in two services, removing the risk of permanent accidental data loss during normal clinical workflows.
What Was Delivered
1. Credential-exposure fix across all backend services
Impact: Authentication tokens and application secret keys can no longer leak into log files or be read from insecure environment configurations in any of the six core backend services (patient, notifications, organisations, consultation, analyses, biobank).
Risk removed: Without this fix, any engineer or administrator reading application logs — or any attacker who obtained log access — would have been able to extract valid user tokens and impersonate patients or clinicians on the platform. The insecure SECRET_KEY configuration additionally exposed every session cookie on the platform to forgery.
Effort: A single coordinated branch was opened, the fix was applied and tested service by service, and six pull requests were merged on the same day to avoid a window where some services were patched and others were not.
2. Soft-delete for clinical data records (two services)
Impact: When a clinician deletes a Suspected Disease entry or a Chronic Disease record, the record is deactivated rather than permanently erased, and can be restored if the deletion was a mistake.
Risk removed: Without this, a misclick during a consultation could have permanently destroyed clinical history with no recovery path. In a public-health surveillance context, a silently missing Suspected Disease record means an epidemiological alert may never be triggered.
Effort: The feature required coordinated changes to the database model, query layer, API view, and reference data CSV files for four languages, plus migration scripts verified to be safe for existing rows. It was delivered for both the consultation service and the patient service within the same sprint.
3. OpenAPI documentation locked behind debug flag (dashboard service)
Impact: The interactive API documentation interface (which lists every endpoint, parameter, and authentication scheme) is no longer publicly accessible on production deployments.
Risk removed: An exposed API schema hands an attacker a complete map of the system — every endpoint, every parameter, every authentication mechanism. On a production instance accessible from outside the local network, this would have dramatically reduced the time and skill required to find and exploit a vulnerability.
Effort: A single targeted change; no functional behaviour was modified.
4. Docker image re-tagging automation tool
Impact: Operators can now re-tag a batch of Docker images (the packaged software containers used for deployment) across the private registry with a single command, with a confirmation step and a full success/failure report at the end.
Risk removed: Without this, re-tagging images for a release was done manually, image by image. A missed image or a mistyped tag name during a production release directly causes a deployment failure or, worse, a silent rollback to an older version.
Effort: Delivered with a full test suite and executable shebang entry point. Skopeo (a remote registry inspection tool) is used to verify remotely that a tag does not already exist before any write operation is attempted.
5. SQL migration execution script (hardened)
Impact: Running database schema changes (SQL scripts that alter production database tables) is now a single command that validates inputs, stops immediately on the first failure, and reports exactly which scripts succeeded and which failed.
Risk removed: Without a fail-fast approach, a partially applied migration can leave the database in an inconsistent state that is extremely difficult to diagnose and roll back under pressure.
Effort: Rebuilt from an informal "quick and dirty" script into a production-grade tool, with argument validation, structured failure reporting, and support for passing a directory of ordered SQL files.
6. User guide — translation completeness and rendering quality
Impact: The platform's user documentation is now fully translated into English, Spanish, and Portuguese in sync with the French source, and a verification script flags any future drift between language versions. PDF rendering quality for embedded screenshots was also improved.
Risk removed: An outdated translation means field workers in non-French-speaking deployments operate from stale instructions — a patient safety risk if workflows have changed since the last update.
Effort: Covered the full document lifecycle: translation, image optimisation, PDF/HTML rendering pipeline migration (switched to a single unified tool), and a Makefile target for automated translation-completeness checks.
What Was Prevented
1. Token theft via application logs
What almost happened: If the JWT (authentication token) scrubbing had not been applied, the next time a developer or operations team member ran a log query — a routine daily activity — they would have been reading live authentication credentials. Any of those credentials could be replayed to authenticate as a real user.
How it was caught: A security audit of the consultation service surfaced the pattern; it was then systematically searched for and removed across all six services in a single coordinated change.
2. Permanent loss of clinical records due to missing soft-delete
What almost happened: The Django REST Framework (the web API layer) default behaviour for a DELETE request is a hard database deletion. Before this sprint, a clinician accidentally pressing "delete" on a Suspected Disease record would have erased it from the database with no recovery path — and no alert.
How it was caught: Identified during a review of the API surface before a new feature was added on top of the same models.
What Is In Progress and Why It Takes Time
1. Analyses service — filter consistency between display and export endpoints
What it is: The filtered display endpoint and the CSV export endpoint for laboratory analyses currently apply different filter logic, meaning a user can see results on screen that are not present in the downloaded export.
Why it cannot be rushed: The two endpoints were built independently and produce structurally different data (the export performs a pivot transformation and joins an external reference table). Aligning the filters without breaking either endpoint requires mapping the full data lineage for both paths before touching the code. A careless shortcut risks silently corrupting exported epidemiological data.
2. Consultation microservice — domain logic centralisation
What it is: Business logic (filtering, status checks, domain rules) is currently scattered across view files instead of being centralised in model or query-layer code. The work identifies which logic should move and where.
Why it cannot be rushed: Moving logic from views to models in a live system requires verifying every call site. Missed call sites result in silent behavioural changes — the API appears to work but applies different rules than before.
Report covers git activity and engineering work sessions from 2026-05-25 to 2026-06-08. Generated 2026-06-08.