- Spegnimento
- 2 settembre 2026 alle ore 01:31 UTC
- Autore
- Kamo
- Impegno
- 1b4e247
Due difetti dietro un rapporto: l'editor PDF non si apriva e l'eliminazione era offerto a un membro che non può cancellare. L'editore. DocManager post a /api/docs/form-fillable/{id} e che Next il percorso non è mai stato creato. Non vi è alcun catch-all sotto /api/docs — ogni altro proxies area attraverso app/api/ <area>/[[...path] ma questo file di route file — quindi Successivo ha risposto con il proprio 404 HTML e la chiamata non è riuscita per EVERY membro, tra cui una holding EDIT DOCUMENTS la cui richiesta il backend sarebbe hanno concesso. E 'superato come il generico "Failed to open document" banner, che legge esattamente come un problema di permesso e non è uno. A monte endpoint è stato dal vivo per tutto il tempo: E' il momento giusto. risposte 401 sul docsservice distribuito e attraverso il relè APIService, dove il percorso inventato risponde 404. Il nuovo percorso rispecchia i suoi /api/docs/open sibling e passa il corpo (imgId, originaleImgId, classicoEditable) attraverso intatto. **Il pulsante di cancellazione.** Ogni riga resa elimina incondizionatamente, quindi l'unico cosa che ha rifiutato era il server — come una lettura di avviso "DELETE DOCUMENTS richiesto" su un pulsante che non avrebbe dovuto essere lì. Il reporter è proprio la diagnosi aveva ragione. Gated ora, insieme con la barra degli strumenti eliminazione di massa, che chiama lo stesso punto e avrebbe prodotto il rifiuto identico momento di una riga è stato selezionato. Modificare è gated su EDIT DOCUMENTS per lo stesso ragione: entrambe le modalità dietro di esso rifiutano senza quel diritto, quindi un membro di sola vista potrebbe solo raggiungere un errore attraverso di esso. Scaricare, legare e condividere il soggiorno non assegnati -- seguono da VIEW DOCUMENTS, già stabilito dalla griglia avendo caricato per niente. Questa è la presentazione, non l'esecuzione. ImagingController e DocumentController controllare questi diritti su ogni chiamata e rimanere l'autorità; nascondere un pulsante rimuove un vicolo cieco, non protegge nulla. La regola di gating vive in app/lib/ accanto a modificareOptions.ts e per la stessa ragione: vitest corre nell'ambiente nodo, quindi una regola all'interno di un componente non può essere coperto affatto. La guardia del percorso è portata a /api/docs perché questo è l'area senza un catch-all, e fallisce su esattamente questo bug quando il il percorso viene rimosso.