v0.29.10 — Admin UI refonte (modals + onglets), emails de release, 4-digit versions

Admin backoffice — UI redesign :
 - Pages versions.php + licenses.php : remplace les <details> inline qui
   débordaient horizontalement par UN bouton « ✎ Modifier » par row qui
   ouvre une modal <dialog> avec onglets. 5 tabs versions (Méta, Notes,
   BÊTA, Channels, Avancé) + 6 tabs licenses (Prolonger, Slots, Channel,
   BÊTA, Lock, Contacts, Machines). Délégation JS unique pour les onglets.
 - Bouton 📋 Copier la clé license dans chaque row (Clipboard API + feedback
   visuel ✓ vert 1.5s). Évite le détour par phpMyAdmin pour transmettre la
   clé aux clients.
 - Overlay « hashing en cours » plein écran sur tous les boutons de hash
   (3-5 min sur OVH pour 13 Go ZIP). Spinner CSS + message contextualisé
   par scope (bulk vs single).
 - Date de release passée de datetime-local à date (l'heure n'a pas de
   sens UX), avec défaut = aujourd'hui pour release_at et aujourd'hui-1an
   pour min_license_date (= license standard couvre les releases sur 1 an).

Emails de notification release :
 - Migration 004 : colonne contact_emails TEXT NULL sur licenses (CSV)
 - Onglet « Contacts » sur la modal licenses pour saisir les emails par
   license (parsing tolérant : CSV, ligne par ligne, point-virgule)
 - Bouton « ✉ Notifier » par version : POST notify_release filtre les
   licenses éligibles (channel match + min_license_date + can_see_betas
   pour BÊTA) et envoie un email HTML à chaque contact (dédup global)
 - Template email table-based + bgcolor (compat Outlook/Word engine),
   navy foncé #0F172A, logo Asterion en CID embed (= affichage direct
   sans demande de permission Outlook), bouton download installer
   centré (align="center" + margin auto), release notes en <pre>
 - Mailer.php helper : parse emails, multipart/related avec attachments
   inline, fallback execCommand pour clipboard

4-digit version support (X.Y.Z.B) :
 - SemVer Parse/CompareTo/ToString gèrent 3 ou 4 digits ; Build absent =
   0 implicite (1.5.4 == 1.5.4.0 < 1.5.4.13). HasExplicitBuild préserve
   le format d'origine au round-trip.
 - Regex InstallationRegistry étendue avec (?:\.\d+)? → reconnaît
   « PROSERVE v1.5.4.13 » côte-à-côte avec « PROSERVE v1.5.4 » sur disque
 - Server-side : versions.php, launcher.php, DownloadUrl.php, api/index.php,
   Releasenotes.php — toutes les regex de validation acceptent le 4ᵉ digit
 - Use case : dev/test iterations cohabitant avec leur release stable

Bugs fixes :
 - migrate.php : strip ligne par ligne les commentaires SQL avant le
   check is-empty. Sans ça, le PREMIER chunk d'un fichier migration
   (= header + premier ALTER) commençait par `--` et était silencieusement
   skip → ALTER jamais appliqué. Affectait migrations 003, 004.
 - SignManifest::getOrComputeSha256 ignorait son cache interne quand force
   demandé par le caller, retournant l'ancien hash en 0 ms même après
   re-upload SFTP (avec mtime préservé). Propage maintenant le flag $force.
   Bouton « 🔁 Hash » per-row force maintenant un re-calcul systématique.
 - DownloadManager : 416 (Range Not Satisfiable) ajouté aux URL-refresh
   triggers, avec HEAD probe pour comparer taille serveur vs manifest →
   message d'erreur explicite si ZIP tronqué. Bps display lissé sur une
   fenêtre glissante de 12 samples (3 s) → plus de clignotement quand un
   segment finit / Polly retry. SHA mismatch popup enrichi avec les
   deux SHAs (attendu vs calculé) extraits via regex de l'exception.
 - DownloadUrl.php : signature de l'URL utilisait un template hardcodé
   /builds/proserve-{version}.zip, ignorant tout rename serveur. Lit
   maintenant download.url du manifest et signe le filename réel.

Strings i18n (5 langues) :
 - ~15 nouveaux : SHA mismatch enrichi avec sources, 416 size mismatch,
   stale manifest, manifest refreshed auto-retry, force fresh menu

Bumps : 0.29.7 → 0.29.10 (4-digit support + accumulated UI fixes).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-28 17:24:50 +02:00
parent 50da755a92
commit 500f7d12e6
21 changed files with 1674 additions and 264 deletions

View File

@@ -1330,6 +1330,26 @@ public sealed partial class MainViewModel : ObservableObject
return list.ToArray();
}
/// <summary>
/// Extrait les deux hashes SHA-256 du message de l'<see cref="InvalidDataException"/>
/// jetée par <c>VerifyAndFinalizeAsync</c>. Format source :
/// <c>"Checksum SHA-256 invalide : attendu {expected}, calculé {computed}"</c>
/// Si parsing échoue (changement de format, log custom, etc.), retourne
/// "?" pour les deux — le reste du message reste informatif.
/// Méthode statique sans dépendance externe (regex pure), facile à tester.
/// </summary>
private static (string Expected, string Computed) ParseShaMismatchValues(string exceptionMessage)
{
// 64 chars hex = SHA-256 hex. Non-greedy, case-insensitive — couvre les
// cas où le format de message évolue légèrement (ponctuation, langue).
var m = System.Text.RegularExpressions.Regex.Match(
exceptionMessage,
@"attendu\s+([0-9a-fA-F]{64}).*calcul[eé]\s+([0-9a-fA-F]{64})",
System.Text.RegularExpressions.RegexOptions.IgnoreCase);
if (m.Success) return (m.Groups[1].Value, m.Groups[2].Value);
return ("?", "?");
}
/// <summary>
/// Point d'entrée UNIQUE pour le lancement auto avec countdown. Utilisé par :
/// 1. Clic sur bouton AUTO → désigne la version + lance après countdown
@@ -2038,7 +2058,14 @@ public sealed partial class MainViewModel : ObservableObject
var sourceLabel = _currentPeerHost is null
? Strings.SourceOvh
: Strings.SourcePeer(_currentPeerHost);
var body = Strings.MsgShaMismatchBody(row.Version, sourceLabel);
// Extrait les deux SHAs depuis le message de l'exception (format :
// "Checksum SHA-256 invalide : attendu X, calculé Y") — permet à
// l'opérateur de comparer ce qui est attendu (manifest signé) vs ce
// qui a été effectivement téléchargé (= ce que la source a servi).
// Si parse échoue, on tombe en fallback avec "?" — le message a
// toujours du sens grâce au texte explicatif.
var (expectedSha, computedSha) = ParseShaMismatchValues(shaEx.Message);
var body = Strings.MsgShaMismatchBody(row.Version, sourceLabel, expectedSha, computedSha);
ThemedMessageBox.Show(body, Strings.MsgBoxShaMismatch,
MessageBoxButton.OK, MessageBoxImage.Warning);
StatusMessage = Strings.StatusShaMismatch(row.Version);
@@ -2145,6 +2172,40 @@ public sealed partial class MainViewModel : ObservableObject
MessageBoxButton.OK, MessageBoxImage.Warning);
StatusMessage = Strings.StatusManifestRefreshed;
}
// Cas spécifique HTTP 416 : range demandé hors du fichier. Le ZIP
// sur le serveur est plus PETIT que ce que le manifest annonce
// (sizeBytes). Causes typiques :
// • Upload SFTP tronqué (coupé en cours) → le ZIP fait p.ex. 7 Go
// au lieu des 13 Go attendus, le manifest a la vieille taille
// • Le manifest n'a pas été re-synchronisé après un rebuild
// (nouvelle taille pas re-hashée → sizeBytes obsolète)
//
// On AUTO-PURGE le cache local (state.json + partial + LAN cache
// .zip + sidecar) pour éviter qu'un partial à mi-route reste en
// ligne et garbage les futurs retries. L'opérateur reçoit un message
// d'erreur explicite avec les tailles, et l'action concrète à faire
// côté serveur (re-upload + re-sync manifest).
else if (ex.Message.Contains("HTTP 416", StringComparison.OrdinalIgnoreCase)
|| ex.Message.Contains("416 on segment", StringComparison.OrdinalIgnoreCase))
{
_logger.LogError(
"416 detected during install of v{Version} — file size mismatch server vs manifest",
row.Version);
try
{
_downloadManager.DiscardResumableState(row.Version);
await _zipCacheStore.InvalidateAsync(row.Version, CancellationToken.None);
}
catch (Exception purgeEx)
{
_logger.LogWarning(purgeEx, "Could not purge after 416 for v{Version}", row.Version);
}
ThemedMessageBox.Show(
ex.Message,
Strings.MsgBoxSizeMismatch,
MessageBoxButton.OK, MessageBoxImage.Warning);
StatusMessage = Strings.StatusSizeMismatch(row.Version);
}
else
{
ThemedMessageBox.Show(