Client PostIt:
- JoinedRooms, SelectedRoom, messages et utilisateurs par salle
(FocusedMessages/FocusedUsers), OnRoomJoined alimente depuis la
valeur de retour du Join
- ChatPage : ComboBox de choix de la salle en focus, listes bindees
sur les vues de focus
Serveur:
- AddSignalR().AddJsonProtocol(IncludeFields=true) : ChatRoomInfo
n'expose que des champs publics, STJ ne les serialisait pas et le
client recevait des objets vides (JoinedRooms jamais alimente)
ChatUserNames n'etait jamais alimente (relique d'un SetUserName disparu),
ce qui faisait lever KeyNotFoundException a chaque connexion SignalR et
fermait immediatement la connexion cote client ("Déconnecté (The server
closed the connection...)" dans PostIt).
- IConnexionManager.OnConnected prend desormais le userName en parametre
- HubConnectionManager.OnConnected alimente ChatUserNames et ChatCxIds
- ChatHub.OnConnectedAsync passe le userName resolu depuis les claims
Inclut aussi les changements PostIt lies (bandeau de statut avec
commande d'action, handlers Reconnecting/Reconnected/Closed).
DeleteUserDirOrFile (and DeleteUserFile) read FileInfo.Length AFTER
fi.Delete(), and FileInfo.Length throws FileNotFoundException once
the file is gone. The controller's catch turned that into a 400, so
the user saw "le fichier n'existe pas sur le serveur" while the delete
had in fact succeeded. Capture the length before deleting.
Adds FileSystemApiTests.Delete_fs_removes_the_file_and_returns_200
(asserts 200 + file gone from disk). 8/8 FileSystemApiTests pass.
Co-Authored-By: Claude Code <noreply@anthropic.com>
The action buttons inside ItemsControl item templates (Télécharger /
Supprimer / Joindre on MyFiles; download/detach on the attachment
lists of BillingQueryDetailsPage and EstimateEditionPage) were bound
with $parent[vm:XxxViewModel].Cmd, which searches for an ancestor
CONTROL of type XxxViewModel — a viewmodel, not a control — so the
binding resolved to null and the Button stayed disabled (grayed) and
inert on click. Switch to the working CirclesPage/EstimateListPage
syntax: $parent[ContentPage].((vm:XxxViewModel)DataContext).Cmd.
Adds MyFilesPageHeadlessTests: mounts MyFilesPage via NavigationPage
+ Window.Show() and asserts each row button's Command is bound,
armed (CanExecute), and fires the API call on click. 136/136 pass.
Co-Authored-By: Claude Code <noreply@anthropic.com>
GET api/v1/fs passed User.GetUserId() (the "sub" claim — a GUID in
production) to GetUserFiles, so the listing looked under
{Blog}/{sub-GUID}. But the personal-storage tree is keyed by the
user's login everywhere else: EnsureDestinationDirectory writes under
{Blog}/{name-claim}, the download endpoint and avatar paths use
user.UserName. So once the upload path was fixed (previous commit),
files landed under {Blog}/{login} while the listing still looked under
{Blog}/{GUID} — an empty tree — hence the PostIt "Mes fichiers" page
listing nothing.
GetDir now resolves the user from the DB (as Post already does) and
lists under user.UserName. UploadedFile.OwnerId stays "sub", so
EnrichWithFileIds still queries by uid.
Tests:
- TestTokenIssuer.Issue gains an optional `name` param (defaults to
subject, preserving existing behavior) so a test token can mirror
production where sub (GUID) ≠ name (login).
- FileSystemApiTests.Get_fs_lists_files_stored_under_the_user_login
decouples sub from the login, uploads under the login, and asserts
GET /api/v1/fs returns the file (and the subject-named directory does
NOT exist). Verified to fail when the controller uses uid for the
listing.
Co-Authored-By: Claude Code <noreply@anthropic.com>
