- Shipped
- 15 agosto 2026 alle ore 05:52 UTC
- Author
- Kamo
- Commit
- 166043b
AiModelController e AiUsageController hanno controllato la proprietà dell'organizzazione e nessun diritto. I 403 già nel controller del modello confrontano provider.getOrganizationId() al — l'isolamento reale dell'inquilino, e una domanda diversa dal fatto che il caller può amministrare i modelli a tutti. MANAGE AI MODELS ora porta tutti e quattro i modelli endpoints e VIEW AI USAGE entrambi i endpoint di utilizzo. Ottenere il modello LIST è sicuro qui, e questo è stato controllato piuttosto che assunto. Uno cluster fa l'elenco della casella di posta equivalente si è rivelato per nutrire il destinatario autocompleto, cosi' facendo, avrebbe svuotato i libri di indirizzi delle persone. Ogni chiamante di /api/ai/modelli è una scheda impostazioni — SecurityModelsTab e ProviderSetupTab — e nessuna chat o superficie di compositore lo legge. Identica dal punto di vista, di fronte una volta che seguire il consumatore. SessionHelper di AIService non aveva alcun hasRight, quindi uno è stato aggiunto, chiuso dal mancato prima riga: nessuna sessione, nessun array di diritti, o un valore di diritti del tipo sbagliato tutti rifiutare. L'equivalente di KBService ha concesso tutto quando l'elenco era vuoto o assente e silenziosamente disabilitato ogni cancello costruito su di esso fino a che non è stato fissato; motivo per ripeterlo qui. Non si vede. MANAGE AI SETTINGS, MANAGE AI MODELS e VIEW AI USAGE sono tenuti da stessi 14 ruoli e 33 membri. ExportUsage restituisce ResponseEntity <byte[]> e trasmette un file, quindi il suo rifiuto è byte semplici piuttosto che la mappa JSON ogni altro cancello in questo passaggio ritorna.