tc-useraccount-telephonecontracts-api
Small ASP.NET Core 2.1 REST API (TC.UserAccount.Telephony.Api) exposing read/write CRUD over user-account telephony contract records in the UserAccount database for the live-agent telephony domain.
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 2.1, Entity Framework Core 3.1, Autofac |
| Runtimes | .NET Core 2.1 |
| Tests / CI | none / CI in place |
| Last commit | 2021-11-08 |
| 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 | On-prem Deployed to our own machines
|
| Releases | 2 release pipeline(s): \finance\live-agent\tc-useraccount-telephonecontracts-api CI; \finance\live-agent\tc-useraccount-telephonecontracts-api Stealth |
| Integration | rest |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
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
Not applicableNot a deployed service (libraries, database definitions, desktop apps) or a retirement candidate not worth the investment. Retirement or consolidation candidate; do not invest in ZDD adoption.
SQL Server exit
Retire insteadThis repo is a retirement or consolidation candidate. Do not invest in a database migration; execute the retirement and the SQL Server dependency disappears with it.
Containerisation
Retire insteadThis repo is a retirement or consolidation candidate; containerising it would be investment in something we intend to switch off.
Recommended actions
Rotate the credentials committed to tc-useraccount-telephonecontracts-api
Risk flags indicate credentials or keys in source (plaintext-credentials, secrets-in-source). Rotate now and enable secret scanning in CI; this is independent of all other work.
Impact: Closes a live security exposure at near-zero cost
proposedReview tc-useraccount-telephonecontracts-api for retirement
Dormant (last commit 2021-11-08) yet still release-linked, and nothing depends on it. Confirm remaining use, then retire and disarm its pipeline.
Impact: Shrinks the estate before the expensive work begins
proposedAssessment notes
tc-useraccount-telephonecontracts-api
Purpose
CRUD API for user telephony contract details: a ReadController (all/single telephony details per user GUID) and a WriteController, plus a ping endpoint, over a single EF Core UserAccountTelephony entity. It shares its DTOs with consumers via the TC.UserAccount.Telephony.ServiceContract NuGet package from the sibling servicecontract repo. Used within the finance live-agent telephony flow.
Tech stack
C# targeting netcoreapp2.1 with a mismatched dependency set: ASP.NET Core MVC 2.2 packages, EF Core 3.1 (SqlServer), Autofac 4.9, and the retired TC.Swagger.Versioning 1.1.3 for versioned Swagger. Docker compose files exist for local development; web.config indicates IIS hosting in anger.
Deployment
prod_application with 2 releases: classic build pipelines tc-useraccount-telephonecontracts-api CI and release feeding release pipelines \finance\live-agent\... CI and ... Stealth (no YAML in repo). Seven per-environment appsettings files (Development, TestQA, DataFixQA, LiveProviderQA, PreProduction, Training, Live).
Dependencies
Internal packages: TC.UserAccount.Telephony.ServiceContract (tc-useraccount-telephonecontracts-servicecontract) and TC.Swagger.Versioning (tc-swagger-versioning, itself retired). No ConnectionBroker — connection strings are raw in config. External: none.
Data stores
SQL Server UserAccount database — the same database owned by backoffice-useraccount-service and also used by phenix-user-api, accessed directly with EF Core rather than through the owning service. Every appsettings file, including Live, embeds a full SQL connection string with plaintext SQL-auth username and password committed to source.
Integration points
Inbound versioned REST with Swagger only; no AddAuthentication/[Authorize] in the code, so the API relies entirely on network/IIS-level protection.
Code health
No test projects. Boilerplate README. Dormant since 2021-11-08. Small codebase (three controllers, one entity, one repository) so the surface is easy to reason about, but hygiene is poor: committed credentials, mixed 2.1/2.2/3.1 package versions, and a dependency on a retired internal library.
Modernisation risks
High: .NET Core 2.1 has been end-of-life since 2021 and the app is production-deployed in the finance live-agent path. Plaintext production SQL credentials in source need rotating and moving to the connection broker or a secret store regardless of any rewrite. Given its size, folding it into backoffice-useraccount-service or rebuilding on .NET 8 with proper auth is a small, high-value job.