Implementato il flusso OAuth2 grant_type=client_credentials come alternativa
al flusso password gia' esistente per l'autenticazione Salesforce server-to-server.
La modifica e' completamente retrocompatibile (default rimane Password).
## Dettaglio modifiche
### CredentialManager/Models/CredentialModels.cs
- Aggiunto enum SalesforceGrantType con valori Password e ClientCredentials
- Aggiunta proprieta' GrantType (default: Password) su RestApiCredential
- Aggiunta proprieta' GrantType (default: Password) su SalesforceCredential
### DataConnection/REST/Configuration/RestServiceOptions.cs
- Aggiunta proprieta' SalesforceGrantType per passare il tipo di flusso al client
### DataConnection/REST/Implementations/SalesforceServiceClient.cs
- Iniettato ILogger<SalesforceServiceClient> con NullLogger come fallback
- Sostituiti ~165 Console.WriteLine con chiamate ILogger appropriate
(LogDebug per dettagli, LogInformation per eventi, LogWarning/LogError per problemi)
- Aggiunto AuthenticateWithPasswordAsync: incapsula il flusso grant_type=password
- Aggiunto AuthenticateWithClientCredentialsAsync: implementa grant_type=client_credentials
(richiede solo ClientId e ClientSecret, nessun utente, URL My Domain obbligatorio)
- Aggiunto SendTokenRequestAsync: helper condiviso per la POST al token endpoint
- Aggiornato AuthenticateAsync() override: instrada al flusso corretto in base a GrantType
- Rimosso modificatore static da NormalizeNumericValues (usava _logger, causava CS0120)
### Data_Coupler/Services/DataConnectionFactory.cs
- Mappatura del campo GrantType dalle opzioni Salesforce a RestServiceOptions
- Passaggio dell'ILogger al costruttore di SalesforceServiceClient
### CredentialManager/Services/CredentialService.cs
- SaveRestApiCredentialAsync (blocco Salesforce): serializza GrantType in AdditionalParameters
- SaveSalesforceCredentialAsync: aggiunto GrantType nel dizionario iniziale
- MapToRestApiCredential: deserializza GrantType da AdditionalParameters con Enum.TryParse
- MapToSalesforceCredential: idem per il tipo SalesforceCredential
### DataConnection/CredentialManagement/Services/DataConnectionCredentialService.cs
- TestSalesforceOAuthLogin aggiornato: per ClientCredentials invia solo client_id e
client_secret (senza username/password/security_token); per Password comportamento invariato
### Data_Coupler/Pages/CredentialManagement.razor
- Aggiunto dropdown 'Tipo di Autenticazione OAuth2' nella sezione Salesforce
- I campi Username, Password e Security Token vengono nascosti quando si seleziona
il flusso ClientCredentials
- Alert contestuale: warning My Domain URL per ClientCredentials, info per Password
- GrantType propagato correttamente in EditRestApiCredential e TestRestApiConnectionFromModal
### AGENTS.md
- Aggiunta sezione di documentazione per la nuova funzionalita' OAuth2 client_credentials
- SchedulingHistory.razor / .cs: iniettato IWebHostEnvironment per nascondere
lo stack trace (con percorsi di file) in produzione; in produzione viene
mostrato solo il messaggio di errore sanitizzato e un avviso che invita a
consultare i log dell'applicazione; in sviluppo il dettaglio completo resta
visibile invariato.
- Scheduling.razor.cs (ExecuteScheduleManually): isolata la notifica JS
(ShowSuccessMessage / ShowErrorMessage) in un blocco try-catch separato per
TaskCanceledException / OperationCanceledException. In questo modo una
disconnessione del browser durante un'esecuzione lunga non sovrascrive più
il risultato già salvato correttamente come 'success' con uno stato 'failed'
e lo stack trace di un'eccezione JSInterop. L'evento viene registrato come
avviso di log senza impatto sul record storico.
- ScheduledJobService.cs: aggiunto commento esplicativo sul motivo per cui
il dettaglio completo (ex.ToString) è salvato nel DB ma la UI ne mostra
solo la versione sanitizzata in produzione.
- Nuovo progetto MachineGuard: libreria che verifica se la macchina corrente
è autorizzata all'esecuzione tramite DPAPI (Data Protection API di Windows)
- Nuovo progetto MachineGuardSetup: tool di configurazione da eseguire come
Amministratore per registrare la macchina autorizzata
- Data_Coupler.sln: aggiunti entrambi i nuovi progetti alla soluzione
- Data_Coupler.csproj: aggiunto riferimento al progetto MachineGuard
- Program.cs: integrazione MachineGuard all'avvio dell'applicazione;
se la macchina non è autorizzata l'app viene arrestata immediatamente
con log critico e scrittura nel Windows Event Log
Senza questo flag il target GenerateVersionJson nel .csproj veniva eseguito
dentro il container Docker Windows dove:
- Non esiste .git (fatal: not a git repository)
- version.json copiato da COPY e' read-only o protetto
→ MSB3491: Access to the path '...\wwwroot\version.json' is denied
Il Dockerfile Linux aveva gia /p:ContinuousIntegrationBuild=true.
La condizione nel .csproj e':
Condition="'' != 'true' AND '' != 'true'"
quindi con il flag il target viene saltato e version.json usa quello
generato dal workflow prima del docker build.
Il workflow GitHub non generava version.json sul runner prima del build,
quindi Docker copiava il file statico del repository (con versione vecchia 2.1.0).
La Gitea Actions usava gia questo approccio correttamente.
Fix applicato: lo step 'Calcola versione' ora genera anche version.json in
Data_Coupler/wwwroot/version.json per entrambi i job Linux e Windows,
con versione, commit SHA, branch, data build e ambiente (GitHub Actions).
Il VersionService legge version.json all'avvio per display nell'UI.
Problemi risolti:
- GitHub Windows: errore PowerShell 'Missing closing )' causato da (cd Dir; cmd)
sintassi bash non valida in PowerShell
- GitHub Linux: versione 1.0.0 invece di 2.3.2 perche il tag v2.3.2 esiste solo
su Gitea e non su GitHub, quindi MinVer trovava il vecchio tag v1.0.0
Soluzione:
- Sostituito dotnet msbuild -getProperty:Version con git describe --tags --abbrev=0
che e lo strumento nativo Git per ottenere l'ultimo tag raggiungibile
- Funziona identicamente su Linux (bash) e Windows (PowerShell)
- Non richiede dotnet installato ne accesso al .git dentro Docker
- Rimosso il dotnet build intermedio sul runner (non piu necessario)
- Corretti i percorsi version.json: ora usa Data_Coupler/wwwroot/version.json
dal root del repo invece di wwwroot/ relativo dopo cd
Il problema era che MinVer veniva eseguito dentro il container Docker dove la
directory .git non esiste, causando il warning MINVER1001 e l'uso di 0.0.0-alpha.0
(poi sostituito dal fallback hardcoded 2.1.0).
Soluzione:
- La versione viene calcolata sul runner CI/CD (dove git e' disponibile)
- Esportata come variabile d'ambiente APP_VERSION via GITHUB_ENV
- Passata al Docker build tramite --build-arg APP_VERSION
- Nei Dockerfile aggiunto ARG APP_VERSION e /p:MinVerVersionOverride per imporla
a MinVer senza che tenti di accedere a git (assente nel container)
- ARG ridichiarato dopo ogni FROM in multi-stage build (comportamento Docker)
Aggiunto fetch-depth: 0 al checkout in tutti i job dei workflow GitHub Actions e Gitea Actions.
Rimosso --depth 1 dal clone manuale del job Windows in Gitea.
MinVer necessita della storia completa per risalire ai tag Git e calcolare la versione corretta.
Senza questa correzione la versione risultava sempre 2.1.0 (fallback hardcoded).
Aggiornato anche il valore di fallback da 2.1.0 a 2.3.2.
- Salesforce Composite Batch API per describe SObject: le describe sono ora
raggruppate in chunk da 25 e inviate come singole POST a /composite/batch,
riducendo le chiamate API da N a ceil(N/25); per 200 SObject: da 201 a 9 chiamate.
- Discovery entita' REST in parallelo: DiscoverEntitySummariesAsync e
DiscoverEntitiesAsync avviate simultaneamente; la lista entita' diventa
interattiva subito dopo le summaries, i dettagli completano in background
con StateHasChanged() per aggiornare l'UI istantaneamente.
- Fix scheduler - preservazione ExternalIdRelationshipsJson e DefaultValuesJson:
in DataCoupler.razor.cs entrambi i blocchi di update profilo esistente
(riattivazione profilo inattivo e sovrascrittura profilo attivo) omettevano
questi campi nella copia, causandone l'azzeramento silenzioso ad ogni
re-salvataggio. Ora entrambi i percorsi propagano correttamente i campi JSON.
- Fix scheduler - esclusione campi sorgente External ID dal mapping normale:
in ScheduledProfileExecutionService.TransformRecordForRest i campi sorgente
usati nelle External ID Relationships venivano inclusi anche nel loop di
field mapping standard, generando dati duplicati nell'entita' destinazione.
Ora il comportamento e' allineato alla UI manuale (TransformRecordToRestEntity).
- Aggiornata documentazione: README.md, AGENTS.md, copilot-instructions.md
- Disabilitato target MSBuild GenerateVersionJson durante build CI/CD
- Aggiunta condizione: non esegue se ContinuousIntegrationBuild=true
- Aggiornato Dockerfile per usare /p:ContinuousIntegrationBuild=true
- Previene sovrascrittura del version.json generato dal workflow Gitea
- Risolve problema: container mostra v1.0.0-dev invece della versione da git tag
- Cambiato immagine base da Alpine a Debian per migliore compatibilità SQLite
- Aggiunto SQLitePCLRaw.bundle_e_sqlite3 per librerie native cross-platform
- Installato sqlite3 e libsqlite3-dev in Debian
- Risolve definitivamente: 'Error loading shared library libe_sqlite3.so'
- Aggiunto MSBuild target che genera version.json automaticamente prima di ogni build
- Versione estratta dal tag git più recente (git describe --tags)
- Rimosso version.json dal tracking git (file generato automaticamente)
- Aggiornato .gitignore per escludere version.json
- Il file viene ora rigenerato ad ogni build con versione, commit SHA, branch e timestamp corretti
- Aggiunto --runtime win-x64 al comando restore
- Specificato -r win-x64 --self-contained false nella publish
- Il restore ora genera project.assets.json per net9.0/win-x64
- Sintassi corretta: --self-contained false invece di /p:SelfContained=false
- Sostituito /p:UseAppHost=false con /p:SelfContained=false in entrambi i Dockerfile
- .NET 9.0 richiede AppHost per applicazioni self-contained
- SelfContained=false è appropriato per container Docker con runtime separato
- Fix applicato sia a Dockerfile (Linux) che Dockerfile.windows
- Creato modello FieldMappingEntry per gestione unificata di field mapping e default values
- Aggiunta colonna DefaultValuesJson alla tabella DataCouplerProfile (max 4000 caratteri)
- Implementata UI con toggle per selezionare modalità Mapping o Default
- Supporto per 9 tipi di dati: string, int, long, decimal, double, float, boolean, datetime, datetimeoffset
- Aggiornata logica TransformRecordToRestEntity per applicare valori default dopo field mapping
- Implementata serializzazione/deserializzazione DefaultValues in DataCouplerProfileService
- Sistema completo di salvataggio/caricamento valori default nei profili
- Migrazione database AddDefaultValuesJsonToProfile creata e applicata
- Implementata funzionalità completa External ID Relationships nell'interfaccia di mapping
- Corretto bug double-mapping: i campi sorgente usati per External ID non vengono più inclusi nei mapping normali
- Risolto errore MALFORMED_ID causato dall'invio duplicato di campi come proprietà dirette e nested objects
- Implementata logica corretta per relationship names: oggetti standard usano il nome diretto, custom objects usano suffisso __r
- Aggiunta UI a 3 colonne (Object, External ID Field, Source Field) per configurazione External ID Relationships
- Migrazione database per supporto External ID Relationships nei profili
- Aggiornato ProfileSaver.razor.cs per salvare/caricare External ID Relationships
- Aggiornato ScheduledProfileExecutionService.cs per gestire External ID nelle esecuzioni schedulate
- Formato JSON output corretto: { 'Account': { 'CardCode__c': 'V50000' } }
Documentazione: EXTERNAL_ID_RELATIONSHIPS_IMPLEMENTATION.md
- Disabilitato trimming per compatibilità con Blazor Server (risolve crash TypeLoadException)
- Configurati PublishSingleFile e ReadyToRun per deployment ottimizzato
- Rimosso controllo eccessivamente restrittivo sui commenti SQL in validazione query
- Ora permessi commenti -- e /* */ nelle query SELECT ODBC
- Mostra stato di tutte le variabili che controllano la visibilità del mapping
- Indica quale condizione non è soddisfatta (isSourceReady, isRestConnected, selectedRestEntity)
- Pannello visibile solo per connessioni ODBC
- Aiuta a identificare rapidamente il problema
- Modificata condizione isSourceReady in DataCoupler.razor
- Per ODBC: richiede solo useCustomQuery && isQueryValid (non isDatabaseConnected)
- Per altri DB: comportamento invariato (richiede isDatabaseConnected)
- Risolto: mapping non appariva dopo validazione query ODBC
- Modificato OnDatabaseCredentialChanged per rilevare connessioni ODBC e forzare useCustomQuery = true
- Aggiunto metodo helper IsOdbcConnection() per verificare tipo credenziale
- Modificata UI DataCoupler.razor:
* Nascosto pulsante 'Connetti e Scopri Schema' per ODBC
* Mostrato messaggio esplicativo per ODBC
* Resa sezione Query Custom sempre visibile per ODBC (senza discovery)
* Nascosta sezione Lista Tabelle per ODBC
- Modificato ValidateCustomQuery per creare temporaneamente DatabaseManager per ODBC
- ODBC ora bypassa completamente il discovery e va diretto a query custom
- Aggiunta persistenza campi ODBC (OdbcDsnName, OdbcMode) in CredentialEntity
- Creata migration EF Core per nuovi campi database
- Aggiornato mapping credenziali per caricare/salvare dati ODBC
- Creato OdbcDatabaseManager dedicato (bypass EF Core che non supporta ODBC)
- Aggiornato DataConnectionFactory per usare OdbcDatabaseManager con connessioni ODBC
- Fix auto-load DSN: sostituito @onchange con @bind-Value:after in dropdown tipo database
- Fix test connessione SAP HANA: rimossa query SELECT 1 che causava errori sintassi
- Implementati tutti i metodi IDatabaseManager in OdbcDatabaseManager
- Supporto completo per discovery schema, tabelle e query ODBC
Risolve problema DbContext non configurato per ODBC e abilita connessioni ODBC complete.
- Rimosso tag 'latest' da branch development, staging e dev
- Tag 'latest' ora riservato esclusivamente al branch main
- Altri branch mantengono tag specifici (development-latest, staging-latest, dev-latest)
- Modificati workflow GitHub Actions e Gitea Actions
- Semplifica la gestione delle versioni in produzione vs sviluppo
- Aggiunto MinVer per calcolo automatico versione da git tags
- Creato modello VersionInfo e servizio VersionService
- Integrato display versione nel NavMenu (Data_Coupler v2.1.0)
- Aggiornato workflow Gitea Actions (Linux e Windows) per generare version.json
- Risolto problema inconsistenza versioning tra container Linux e Windows
- Documentazione completa: VERSIONING_SYSTEM.md e MINVER_SETUP.md
- Versione ora calcolata automaticamente da git tags (Semantic Versioning)
- Migrato immagine runtime da Debian a Alpine (riduzione ~60% dimensione)
- Aggiunto suffisso -linux ai tag per manifest multi-platform
- Disabilitate attestations/provenance per ridurre overhead push
- Implementato retry automatico in caso di fallimento push
- Corretto utilizzo apk invece di apt-get per Alpine Linux
Risolve: HTTP 524 timeout durante push immagini al registry
- Aggiunto suffisso -linux ai tag delle immagini Linux per distinguerli
- Aggiornati i comandi del manifest per usare tag espliciti -linux e -windows
- Risolto errore 'not found' durante creazione manifest su branch staging
- Applicato fix a tutti i branch (main, development, dev, staging)
- Aggiunta validazione percorsi file prima del salvataggio profili
- Implementati metodi di lettura file CSV e Excel per schedulazioni
- Supporto doppia modalità: caricamento browser (preview) e percorso manuale (schedulazione)
- Gestione completa deletion sync anche per file CSV/Excel
- Rilevamento automatico separatori CSV (virgola, punto e virgola, tab, pipe)
- Supporto formati Excel legacy (.xls) e moderni (.xlsx)
- Abilitati profili file nella UI di schedulazione
- Logging dettagliato per troubleshooting
- Documentazione completa in CSV_SCHEDULING_IMPLEMENTATION.md
- Aggiornati README.md e copilot-instructions.md con nuove feature
- Rimosso testo 'TEST' dalla pagina di login
- Sostituito download ZIP con git clone diretto
- Più veloce e affidabile
- Clone shallow (depth 1) per performance
- Verifica Dockerfile.windows dopo clone
- Git è disponibile sul runner Windows
- Usa robocopy per spostare file (più affidabile di xcopy)
- Logging dettagliato per ogni fase
- Verifica Dockerfile.windows dopo estrazione
- Error handling robusto con exit codes
- Risolve: Dockerfile.windows not found
- Stesso flusso e struttura della parte Linux
- Download e extract repository migliorato
- Debug steps per verificare file e secret
- Tagging multipli come Linux (latest, branch-sha, etc.)
- Miglior gestione errori e logging
- Usa windows-2022 come runner specifico
- Gitea Actions non clona automaticamente il repo
- Download repo da GitHub come ZIP con curl
- Estrazione con tar (nativo Windows 10+)
- Spostamento files nella working directory
- Fix: working directory vuota, nessun Dockerfile
- Aggiunto step per verificare working directory e files
- Controllo esistenza Dockerfile.windows prima del build
- Miglior error handling con exit codes
- Debug: unable to find Dockerfile.windows
- Gitea Actions clona automaticamente il repository
- Non serve checkout manuale con git
- Il codice è già presente nella working directory
- Fix: git non riconosciuto su runner Windows
Alessio
Alessio Dal Santo