viewing-as-api
.NET 8 API that lets head-office users 'view as' another Travel Counsellor — listing impersonatable user accounts from MongoDB, filtered by view-as configuration, plus a temporary gold-status lookup pending the Gold API's move to the cloud.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | ASP.NET Core 8, MediatR 12, Serilog |
| Runtimes | .NET 8 |
| Tests / CI | some / CI in place |
| Last commit | 2025-10-03 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Identity and access (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | rest, jwt |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Already deploys as a container to AWS, which releases without downtime today. Separating it from the three-week release is a process decision, not a technical one.
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Already containerisedIts pipelines already build containers and deploy to AWS. Nothing to do here.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
viewing-as-api
Purpose
Supports the "viewing as" impersonation feature: a versioned Users controller offers GetUsers, GetUsersByApplication and GetUserGoldStatus, with MediatR handlers that require the caller to be a head-office user (JWT claims), then return the user accounts they may impersonate based on ViewingAs configuration. The gold-status endpoint is explicitly documented in code as "temporary until the Gold API is in the cloud". Notably, GetUsersByApplication accepts an applicationName parameter that the handler currently ignores.
Tech stack
C# on .NET 8 (Api, Common, DataAccess projects). ASP.NET Core MVC with Asp.Versioning 8, MediatR 12, PhenixAuth.AspNetCore.AuthenticationScheme plus Phenix.Auth.JWTBearer/Cognito JWT services, Serilog compact JSON logging, request/response logging and exception middlewares, Swashbuckle with annotations, MongoDB.Driver 3.4 via TC.ConnectionBroker.Mongo with TC.ScriptRunner.Mongo initialisation, config-driven CORS. One pinned pre-release package (TC.Diagnostics.HealthChecks 7.2.2-g3ebc8534cc).
Deployment
Included as prod_application with 0 releases — YAML/AWS only. Build pipeline viewing-as-api CI from azure-pipelines.yml on the shared InternalOSS/azure-pipelines-templates jobs/ci.yml (SDK 8.x): container into the phenix namespace, ECS deployment with tfvars, eu-west-1, functional area phenix. Per-environment appsettings (qa, preproduction, production).
Dependencies
Internal: TC.ConnectionBroker.* (tc-connectionbroker), TC.Exceptions.WebApiClient.AspNetCore (tc-exceptions), TC.Diagnostics.HealthChecks (tc-diagnostics-portal). Phenix.Auth.JWTBearer, PhenixAuth.AspNetCore.AuthenticationScheme and WebApi.Logger map to no included repo. No external services.
Data stores
Reads three shared MongoDB databases via the connection broker: UserAccounts (user accounts), ViewingAs (Configuration collection it is nominally the owner of) and Gold (sales-person gold status and groups, owned by tc-gold-api). The same three databases — and near-identical repository/model code — appear in useraccount-api, which also exposes view-as endpoints.
Integration points
Inbound REST with Phenix/Cognito JWT bearer auth and CORS; head-office authorisation enforced in handlers. No outbound calls, bus or streams.
Code health
Some tests: one test project with ~17 facts over handlers, mappers and the health check. README is untouched boilerplate, and the ignored applicationName parameter plus the admitted-temporary gold endpoint suggest a feature midway through evolution. Last commit 2025-10-03.
Modernisation risks
Low technically (current .NET 8, containerised). The real question is redundancy: useraccount-api duplicates this service's data models, databases and view-as endpoints, so the estate is carrying two overlapping impersonation APIs against the same shared Mongo databases — a consolidation candidate once callers migrate, at which point the temporary gold-status shim should also be retired.