Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/pabloeferreyra/Turnero/llms.txt

Use this file to discover all available pages before exploring further.

A Medic record is the bridge between an ASP.NET Identity user and a doctor who appears in the appointment booking interface. Creating an Identity account gives someone the ability to log in; creating the corresponding Medic record is what makes that person selectable when scheduling appointments and what enables the real-time SignalR notification system to route alerts directly to their browser session. Both pieces must be in place before the doctor can fully participate in the system.

​
The Medic Model

public class Medic
{
    [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public Guid    Id       { get; set; }
    public string? Name     { get; set; }    // Doctor's display name
    public string? UserGuid { get; set; }    // IdentityUser.Id

    public ICollection<Turn>?  Turns  { get; set; }
    public ICollection<Visit>? Visits { get; set; }
}
FieldTypePurpose
IdGuid (auto-generated)Primary key for the Medic record
NamestringDisplay name shown in appointment dropdowns
UserGuidstringThe IdentityUser.Id of the doctor’s login account
TurnsNavigationAppointments associated with this doctor
VisitsNavigationVisit/medical records associated with this doctor
When an appointment is updated, Turnero uses SignalR to push a real-time notification to the affected doctor’s browser. The hub method UpdateTableDirected targets a specific connected client by calling Clients.User(medic.UserGuid), which matches the SignalR user identifier against the doctor’s ASP.NET Identity ID. If UserGuid is blank or points to the wrong user, that doctor will never receive live appointment alerts. 
// TurnsController.cs — sending a directed SignalR notification
await hubContext.Clients
    .User(medic.UserGuid)
    .SendAsync("UpdateTableDirected", medic.Name, turnMsj, t.DateTurn.ToShortDateString());

​
The MedicDto Projection

Appointment and dropdown views use a lightweight projection rather than the full entity to avoid loading navigation properties unnecessarily: 
public class MedicDto
{
    public Guid?   Id   { get; set; }
    public string? Name { get; set; }
}
MedicDto is what populates the doctor dropdown in the appointment booking form, and it is the type returned by GetCachedMedics().

​
Caching

Medic records are loaded from the database once at application startup and stored in memory via GetCachedMedics(). Subsequent requests for the medic list — such as those made by the appointment create and edit forms — read from this in-memory cache rather than hitting the database on every call. 
// Program.cs — cache warm-up at startup
await medicsRepository.GetCachedMedics();
Because the list is cached, a newly created or edited Medic record may not appear in appointment dropdowns until the application is restarted. In development, restart the app after adding a new medic to see the change reflected immediately.

​
Prerequisites

Before creating a Medic record, two steps must be completed:
1

Register the user account

An administrator must register the doctor’s login account via the Register page (/Identity/Account/Register). The registration form requires an email, username, password, and role selection.
2

Assign the Medico role

The newly registered user must be assigned the Medico role. The Create Medic form queries userManager.GetUsersInRoleAsync("Medico") to populate its dropdown — users who are not in the Medico role will not appear as options.
If you create a Medic record but the linked user is later removed from the Medico role, that doctor will no longer appear as an option in the appointment dropdown for new bookings, even though their Medic record still exists.

​
Creating a Medic

1

Open the Create form

Navigate to GET /Medics/CreateAsync. The controller calls userManager.GetUsersInRoleAsync("Medico") and populates a ViewBag.User dropdown with all users in the Medico role. A placeholder entry labelled “Seleccione…” is inserted at position zero.
2

Fill in the medic details

Enter the doctor’s Name (their display name throughout the system) and select the corresponding User from the dropdown. The selected user’s IdentityUser.Id is stored as UserGuid.
3

Save the record

Submit the form to POST /Medics/Create. On a valid model the controller calls insertMedicServices.Create(medic) and redirects to the medic index at /Medics/Index.

​
Editing a Medic

GET /Medics/Edit/{id} does not render an edit form — it validates that the record exists and then immediately redirects to the medic index at /Medics/Index. To update a medic’s details, submit directly to POST /Medics/Edit with the updated Medic model. The controller verifies the record exists via MedicExists(medic.Id) before calling updateMedicServices.Update(medic) and redirecting to the index.
If you need to relink a medic to a different Identity user (for example, after recreating a login account), update the UserGuid field to the new user’s IdentityUser.Id. The SignalR notifications will then route to the new account’s browser session.

​
Deleting a Medic

1

Trigger the deletion

GET /Medics/Delete/{id} does not display a confirmation view — it validates that the record exists and immediately redirects to /Medics/Index. Deletion is confirmed by submitting directly to the POST endpoint.
2

Confirm the deletion

Submit to POST /Medics/Delete (action name Delete, mapped to DeleteConfirmed). The controller calls updateMedicServices.Delete(medic) — a soft delete via the update service — and redirects to the index.
Deleting a Medic record does not cascade-delete the associated Turn (appointment) or Visit records. Those rows retain their MedicId foreign key but the doctor will no longer appear in the booking dropdown for new appointments. Additionally, any pending SignalR notifications targeting the deleted medic’s UserGuid will have no connected client to deliver to.

​
All Medic Routes at a Glance

MethodRouteDescription
GET/Medics/IndexList all medic records
GET/Medics/Details/{id}View a single medic’s details
GET/Medics/CreateAsyncShow the create form (loads Medico-role users)
POST/Medics/CreateSave a new medic record
GET/Medics/Edit/{id}Validates record exists, then redirects to Index
POST/Medics/EditSave changes to an existing medic
GET/Medics/Delete/{id}Validates record exists, then redirects to Index
POST/Medics/DeleteSoft-delete the medic record (via updateMedicServices.Delete)
All routes under /Medics/ require the Admin role. Doctors themselves cannot edit or delete their own medic records.

Build docs developers (and LLMs) love

Get started for freeTalk to us