MACOEV.Glpi.Client

Client .NET per le API REST di GLPI 10+, condiviso fra il portale di ticketing ASL Roma 1 / PTV e il modulo Inventario Semplificato.

Target: net8.0 e net10.0.

Perche' esiste

L'integrazione GLPI viveva dentro l'applicazione Blazor di ticketing, in un unico file da 1188 righe non riusabile da fuori. Questa libreria la estrae e ne sana i difetti strutturali:

Uso

builder.Services.AddGlpiClient(builder.Configuration);

{
  "Glpi": {
    "BaseUri": "https://glpi.aslroma1.it",
    "AppToken": "...",
    "UserToken": "...",
    "SessionLifetime": "00:20:00"
  }
}

Oppure in codice:

builder.Services.AddGlpiClient(options =>
{
    options.BaseUri = "https://glpi.aslroma1.it";
    options.AppToken = appToken;
    options.UserToken = userToken;
});

BaseUri e' la radice dell'istanza GLPI senza /apirest.php.

Nota sulla sessione

Le credenziali sono quelle di un service account: la sessione aperta dal client non e' quella dell'utente finale. Di conseguenza glpiactiveprofile restituito da initSession descrive il service account e non e' utilizzabile per autorizzare l'utente applicativo. Per i ruoli vanno interrogati Group_User / Profile_User sull'utente autenticato.

Modelli

I DTO vivono tutti nel namespace unico Macoev.Glpi.Client.Models, organizzati in cartelle (Common, Session, Users, Tickets, Dropdowns, Assets, Documents, Knowbase): un solo using per il consumatore.

I nomi JSON sono il contratto con GLPI e sono coperti da test di contratto (ModelContractTests): un refuso in un JsonPropertyName non produce errori di compilazione, quindi la verifica non puo' che essere automatica.

Cosa resta fuori, di proposito

Sviluppo

dotnet test

Rilascio

La pubblicazione e' automatica su GitHub Actions ed e' legata al tag, non al branch:

git tag v26.8.1 && git push origin v26.8.1

Il workflow publish.yml ricava la versione dal tag (v26.8.1 -> 26.8.1), la inietta con -p:Version=, esegue i test, impacchetta e pubblica sul feed. Richiede il secret di repository NUGET_FEED_API_KEY. In alternativa si puo' lanciare a mano da Actions > Publish NuGet > Run workflow indicando la versione.

Versionamento YY.M.patch.build, coerente con gli altri pacchetti MACOEV.

Attenzione alla normalizzazione NuGet: una quarta cifra a zero viene rimossa, quindi 26.8.1.0 viene pubblicato come 26.8.1. Conviene taggare direttamente nella forma normalizzata, per non avere tag e pacchetto con nomi diversi.

Directory.Build.targets allinea AssemblyVersion e FileVersion alla Version finale, qualunque sia la sua provenienza.