# Post degli utenti in fase di approvazione bloccati in coda

**URL:** https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025
**Category:** Self-hosting
**Created:** [9 Settembre 2026, 6:37pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025 "2026-09-09T18:37:04Z")
**Posts on this page:** 11
**Page:** 1

<div class="post-metadata">

### Author: ![tknospdr](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tknospdr/32/529762_2.png) [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [9 Settembre 2026, 6:37pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/1 "2026-09-09T18:37:04Z")

</div>

Il mio sito è online da oltre un anno e questo problema è iniziato a verificarsi solo di recente.  
Abbiamo molti utenti in fase di approvazione, poiché il sito funziona principalmente come help desk / centro di gestione ticket.

Nell’ultima settimana circa, i ticket con media incorporati (screenshot) sono rimasti bloccati nella coda di approvazione.

Ho verificato che il gruppo “TL0” è presente nelle “media groups” con revisione saltata, ma immagino che gli utenti in fase di approvazione possano avere una flag leggermente diversa.

Questo problema va risolto, perché gli utenti stanno perdendo dei ticket. Perché è iniziato solo adesso?

Grazie!  
David

---

<div class="post-metadata">

### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [9 Settembre 2026, 7:13pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/2 "2026-09-09T19:13:02Z")

</div>

Mi sembra che questo potrebbe essere un report sullo stesso problema

> [@Una nuova interfaccia di revisione con tutte le nuove funzionalità](https://meta.discourse.org/t/a-new-review-queue-layout-with-all-new-features/388194/49):
>
> Di recente, la coda di revisione ha iniziato a mostrare notifiche relative a email in arrivo da newsletter. Ora devo validare ogni utente già registrato che pubblica in categorie dedicate alla ricezione di email. In precedenza, questi post creavano automaticamente argomenti, ma ora vengono filtrati. Tuttavia, non ho trovato alcun modo per aggiungere quegli utenti a un elenco di autorizzazione. Esiste un’opzione per farlo?

Penso che gli utenti in fase di staging fossero immuni alla maggior parte dei limiti. Ecco perché esisteva l’impostazione di sito separata `Approva a meno che non sia in staging`. Ma non ho mai usato quella funzione, quindi non sono sicuro.

Quale motivo viene mostrato nella coda di revisione?

---

<div class="post-metadata">

### Author: ![tknospdr](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tknospdr/32/529762_2.png) [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [9 Settembre 2026, 7:17pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/3 "2026-09-09T19:17:56Z")

</div>

Al momento non ne ho uno in revisione, ma si riferiva al fatto che nei post erano presenti sempre contenuti multimediali incorporati.

Ho verificato l’impostazione “Approva se non è in bozza” e non è selezionata.

---

<div class="post-metadata">

### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [9 Settembre 2026, 8:06pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/4 "2026-09-09T20:06:11Z")

</div>

> [@tknospdr](#):
>
> Al momento non ne ho nessuno in fase di revisione.

Dovresti essere in grado di visualizzarne di precedenti modificando il filtro di stato in alto.

Cercherò di dare un’occhiata. Ma non posso dire quando riuscirò a farlo. Spero che qualcun altro si faccia avanti.

---

<div class="post-metadata">

### Author: ![tknospdr](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tknospdr/32/529762_2.png) [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [9 Settembre 2026, 8:10pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/5 "2026-09-09T20:10:32Z")

</div>

Oh, capisco.

> Questo post include media incorporati. Vedi gruppi di media da rivedere.

E quell’impostazione include amministratori, moderatori, trust\_level\_0

---

<div class="post-metadata">

### Author: ![tknospdr](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tknospdr/32/529762_2.png) [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [11 Settembre 2026, 2:56pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/6 "2026-09-11T14:56:54Z")

</div>

Ricevo ancora questi messaggi. C’è qualcosa che posso fare per risolvere il problema?  
Sta davvero compromettendo il nostro flusso di lavoro.

 ![Screenshot 2026-09-11 at 10.55.19 AM](https://global.discourse-cdn.com/meta/original/4X/0/9/c/09cc89a2ba61ec3d93207b5a7a2ae61460e2bfaa.png)

---

<div class="post-metadata">

### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [11 Settembre 2026, 3:04pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/7 "2026-09-11T15:04:11Z")

</div>

Scusa, non ho ancora avuto il tempo di dare un’occhiata. Se è così importante per te, dovresti considerare di chiedere aiuto su #Marketplace.

Penso che sia legato alle modifiche in [Incoming emails with signatures/tables/inline images rejected with “Access Denied” - #2 by Ethsim2](https://meta.discourse.org/t/incoming-emails-with-signatures-tables-inline-images-rejected-with-access-denied/409538/2). Quindi forse @Ethsim2 ha un’idea.

---

<div class="post-metadata">

### Author: ![tknospdr](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tknospdr/32/529762_2.png) [@tknospdr](https://meta.discourse.org/u/tknospdr)
#### Post date: [11 Settembre 2026, 3:09pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/8 "2026-09-11T15:09:57Z")

</div>

Nessuna scusa necessaria. L’aiuto gratuito è sempre aiuto gratuito. Stavo solo cercando di inviarti uno screenshot completo.

Avresti potuto dire altrettanto facilmente: “Calma, la correzione arriverà appena ci arriverò!”

🙂

---

<div class="post-metadata">

### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [11 Settembre 2026, 4:17pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/9 "2026-09-11T16:17:18Z")

</div>

Ho testato questa configurazione su un’istanza self-hosted attuale.

Gli utenti in fase di staging non sono membri di `trust_level_0`, quindi l’inclusione di `trust_level_0` in `skip review media groups` non li esenta dalla revisione.

Tuttavia, aggiungere `logged_in_users` a `skip review media groups` funziona.

 ![image](https://global.discourse-cdn.com/meta/original/4X/9/4/e/94e6adde473938147d60bf780a411270a0591b02.png)

Ho testato questo sia direttamente su `NewPostManager` sia attraverso il percorso reale di ricezione email. Un’email da un nuovo utente in fase di staging contenente media incorporati è stata pubblicata immediatamente, senza passare dalla coda di revisione.

Quindi, per una configurazione di tipo helpdesk in cui vengono creati nuovi mittenti arbitrari come utenti in fase di staging, l’aggiunta di `logged_in_users` sembra fornire il comportamento previsto senza la necessità di attivare gli utenti o di mantenere un gruppo separato.

Un dettaglio leggermente sorprendente è che gli utenti in fase di staging corrispondono al pseudo-gruppo `logged_in_users` per questo controllo, anche se non sono account attivati o registrati nel senso usuale.

---

<div class="post-metadata">

### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [11 Settembre 2026, 5:01pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/10 "2026-09-11T17:01:31Z")

</div>

Ho inoltre aperto una PR per aggiungere una copertura di regressione per questo comportamento:

> <https://github.com/discourse/discourse/pull/43591>
>
> This adds regression coverage for media-containing incoming email from a newly-c…reated staged user when \`logged\_in\_users\` is included in \`skip\_review\_media\_groups\`.
> 
> This came up in Meta topic 412025 following the staged-email media handling covered by #42515.
> 
> The new spec verifies that:
> 
> \- a previously unknown sender is created as a staged user;
> \- their media-containing email creates a topic directly when \`logged\_in\_users\` is configured to skip media review; and
> \- no \`ReviewableQueuedPost\` is created.
> 
> This complements the existing test which verifies that the same kind of staged email is queued with \`contains\_media\` when the sender is not in an exempt group.
> 
> No production code is changed.
> 
> One slightly surprising aspect of the current behavior is that staged users match the \`logged\_in\_users\` pseudo-group for this check. This PR makes that dependency explicit for review and regression coverage.
> 
> Tests:
> 
> \- \`bin/rspec spec/lib/email/receiver\_spec.rb\` — 213 examples, 0 failures
> \- \`bin/rubocop spec/lib/email/receiver\_spec.rb\` — no offenses
> \- \`git diff --check\`

Verifica che un utente “staged” appena creato con media incorporati non venga messo in coda quando `logged_in_users` è incluso in `skip_review_media_groups`.

Questo dovrebbe chiarire anche se i maintainer considerano intenzionale che gli utenti “staged” corrispondano a `logged_in_users` in questo contesto, in modo da poter fare affidamento su questo comportamento in futuro.

---

<div class="post-metadata">

### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [15 Settembre 2026, 6:38pm UTC](https://meta.discourse.org/t/staged-users-posts-stuck-in-queue/412025/11 "2026-09-15T18:38:23Z")

</div>

@tknospdr, aggiungere `logged_in_users` alle impostazioni del sito ha risolto il tuo problema?

> [@Una nuova interfaccia di revisione con tutte le nuove funzionalità](https://meta.discourse.org/t/a-new-review-queue-layout-with-all-new-features/388194/50?u=ethsim2):
>
> Ho notato che aggiungere logged\_in\_users all’impostazione del sito skip review media groups fa sì che gli utenti in fase di staging appena creati vengano pubblicati automaticamente in un argomento, anziché nella coda di revisione. Ho inoltre aperto una PR solo per test, per confermare che il comportamento attuale, per cui gli utenti in fase di staging corrispondono a logged\_in\_users per questo controllo, è intenzionale e quindi qualcosa su cui si può fare affidamento senza rischiare regressioni…
