Review plugin

A cosa serve

La review plugin è disponibile per chi partecipa al programma sviluppatori dell’Hub XIQUIL. Permette di revisionare le versioni di un plugin prima della pubblicazione nel marketplace — utile per team che sviluppano plugin internamente o contribuiscono al marketplace ufficiale.

La sezione Review plugin dell’Hub XIQUIL è il backoffice usato dagli amministratori per controllare le versioni inviate dagli sviluppatori prima della pubblicazione nel Marketplace.

Una versione caricata da uno sviluppatore non diventa visibile agli utenti finché non viene inviata in review, approvata e firmata.

Tab Review

Il tab Review riunisce coda e storico in un’unica vista. Per impostazione predefinita mostra solo le versioni in stato pending_review: sono le versioni che uno sviluppatore ha inviato con Invia per review e che attendono una decisione amministrativa.

Da questa vista puoi aprire la scheda della versione, leggere metadata e changelog, controllare l’esito dello scan automatico, valutare eventuali giustificazioni ai warning e decidere se approvare o rifiutare.

Le azioni di review sono disponibili solo per le versioni in pending_review.

La scheda mostra anche il confronto del manifest firmato rispetto alla release approvata precedente, quando esiste: campi cambiati, valore precedente e valore nuovo. Per la prima pubblicazione, il backoffice segnala che non esiste uno storico da confrontare.

Filtri e ricerca

Usa i filtri stato per passare tra:

Filtro	Cosa mostra
In attesa	Review pending azionabili
Approvate	Versioni già approvate
Rifiutate	Versioni respinte
Tutte	Storico completo delle review visibili

La ricerca testuale filtra plugin, slug, autore, versione, tier, changelog, note developer e campi modificati rispetto alla release precedente. I conteggi accanto ai filtri arrivano dal server e restano coerenti anche quando lo storico cresce.

Mostra bozze

Il toggle Mostra bozze aggiunge alla vista le bozze create dagli sviluppatori ma non ancora inviate in review.

Queste bozze servono solo per controllo interno:

puoi vederle per capire cosa è stato caricato;
puoi controllare metadata, archivio e scan se presenti;
sono marcate con il chip Bozza non sottomessa;
non puoi approvarle o rifiutarle perché lo sviluppatore non le ha sottomesse.

Per rendere una bozza azionabile, lo sviluppatore deve completare la checklist e premere Invia per review dal proprio pannello Developer.

Catalogo

Il tab Catalogo mostra i plugin che hanno almeno una versione approvata. È la vista utile per controllare cosa può comparire nel Marketplace, distinguendo versioni beta e stabili secondo il canale approvato.

Un plugin senza versioni approvate non appartiene al catalogo pubblico, anche se esistono bozze o versioni in review.

Nel catalogo backoffice le versioni hanno accenti colore per stato: bozza grigio, archiviata rosso, in review arancione, beta viola, stable verde. Le versioni archiviate sono nascoste di default; attiva il relativo flag per mostrarle. Puoi archiviare una bozza o ripristinare una versione archiviata come nuova bozza attiva.

Richieste modifiche

Il tab Richieste modifiche raccoglie le richieste post-pubblicazione inviate dai developer, per esempio aggiornamenti metadata o richieste di disattivazione.

La vista mostra per default le richieste In attesa, con filtro per vedere anche lo storico. Un amministratore può approvare la richiesta, applicando la modifica, oppure rifiutarla con una motivazione comprensibile per il developer.

Le richieste di modifica non sostituiscono la review di una nuova versione: servono per modifiche su plugin live, quando il salvataggio diretto dei metadati non è consentito.

Approva o rifiuta

I pulsanti Approva e Rifiuta sono disponibili solo per versioni in stato pending_review.

Quando approvi una versione:

confermi che metadata, changelog, archivio e scan sono stati valutati;
scegli o confermi il canale di pubblicazione previsto;
controlli o correggi release version e compatibilità Core (min_core_version, max_core_version);
l’Hub genera il plugin.json effettivo unendo form Hub e manifest tecnico;
l’Hub firma il pacchetto con firma RSA-PSS e inserisce il keyid della chiave Marketplace;
la versione diventa distribuibile secondo canale, tier e compatibilità dichiarati.

La firma RSA-PSS permette al Core XIQUIL di verificare che il pacchetto distribuito provenga dall’Hub e non sia stato alterato dopo l’approvazione. Il keyid consente al Core di scegliere la chiave pubblica corretta quando l’Hub ruota le chiavi di firma Marketplace.

Quando rifiuti una versione, inserisci una motivazione comprensibile per lo sviluppatore. La versione non viene pubblicata e lo sviluppatore dovrà caricare o preparare una nuova bozza corretta.

Una versione approvata entra nel catalogo solo se viene firmata correttamente dall’Hub. I KPI della dashboard backoffice e il Marketplace pubblico contano come pubblicati solo i plugin con almeno una versione beta o stable approvata e firmata.

Scan score e severity

Nel dettaglio review il backoffice mostra i risultati dello scan automatico tramite punteggio e riepilogo severity. Il punteggio aiuta a leggere rapidamente il rischio, mentre le severity indicano quanti finding richiedono attenzione.

Lo scan include anche i finding dettagliati. Se ci sono warning, controlla le note del developer: l’Hub richiede una giustificazione prima dell’invio quando la bozza presenta warning.

Riesegui scan

Nel backoffice è disponibile anche il pulsante Riesegui scan. Serve a rigenerare punteggio e finding sulla versione caricata, senza chiedere allo sviluppatore di ricaricare l’archivio.

Il pulsante è disponibile solo per versioni draft o pending_review. Per versioni già approvate, rifiutate o archiviate lo scan è storico e non viene rianalizzato da questa vista.

Usalo quando:

lo scan precedente è vecchio o incompleto;
vuoi ricontrollare una versione prima dell’approvazione;
una giustificazione ai warning richiede un nuovo confronto con i finding;
sono cambiati i controlli automatici disponibili.

Il nuovo esito sostituisce quello consultato nella review. Se emergono warning, valuta se la giustificazione dello sviluppatore è sufficiente o se serve una richiesta di modifica.

Cosa controllare prima dell’approvazione

Prima di approvare, verifica almeno:

descrizione, categoria, tag e tier coerenti con il plugin;
changelog comprensibile per gli utenti;
archivio corretto e riferito alla versione dichiarata;
scan completato, punteggio e finding letti;
warning giustificati in modo chiaro;
eventuali limiti di compatibilità Core dichiarati;
differenze di manifest rispetto alla versione precedente, se presenti;
eventuali variazioni di permessi, pacchetti di sistema o capability tecniche;
canale beta o stabile adatto al livello di maturità della release.

Una volta approvata e firmata, la versione può essere distribuita agli utenti compatibili tramite Marketplace.

Vedi anche

Marketplace plugin — installare plugin già pubblicati
Per sviluppatori — Plugin SDK — sviluppare un plugin
Per sviluppatori — Pubblicazione — processo di pubblicazione