Portale richieste

Questo secondo tutorial costruisce una mini-app completa: un form pubblico per le richieste, una coda backoffice per lo staff e un'e-mail al cambio di stato. Presuppone che tu abbia già completato My First App.

Cosa costruirai

Public visitor ──► Submit request ──► Staff reviews ──► Status e-mail to requester

• Portale Public — chiunque può inviare una richiesta
• Portale Backoffice — lo staff elenca, apre e aggiorna le richieste
• Oggetto Request — i dati condivisi
• Oggetto Operator — lo staff che accede al backoffice

1. Modello dati

Crea l'oggetto Request con i campi:

Campo	Tipo	Note
title	Text	Riepilogo breve
description	Long Text	Dettagli
requester_email	E-mail	Dove inviare le notifiche
requester_name	Text	Opzionale
status	Choice	New, In progress, Done, Rejected — default New
staff_notes	Long Text	Solo interno
submitted_at	Date and Time	Opzionale; impostato via form task o auto field

Crea l'oggetto Operator con almeno:

Campo	Tipo
email	E-mail
password	Password
name	Text

Aggiungiti come record operator nel Builder.

2. Portale pubblico

1. Crea una pagina di primo livello Public (lasciala senza login).
2. Aggiungi un'intro Rich Text ("Come inviare una richiesta").
3. Aggiungi un Form che crea una Request.
4. Mostra title, description, requester_name, requester_email. Nascondi status e staff_notes al pubblico (o omettili e imposta i default con una form task).
5. All'invio, aggiungi una form task che imposta status su New se necessario, e opzionalmente notifica lo staff a una casella fissa.
6. Configura il follow-up verso una pagina figlia di ringraziamento con un breve messaggio di conferma.

Apri l'URL del portale pubblico e invia una richiesta di test.

3. Backoffice staff

1. Crea una pagina di primo livello Backoffice.
2. Abilita il login su quel portale usando l'oggetto Operator.
3. Aggiungi una Grid dei record Request: colonne title, status, requester_email, submitted_at. Abilita i filtri su status.
4. Aggiungi una pagina figlia Request detail con:
   • un widget Detail per la richiesta;
   • un Form che aggiorna la richiesta — includi status e staff_notes (e mantieni i campi del richiedente in sola lettura se utile).

Accedi come operator e apri la richiesta di test.

4. E-mail di stato al richiedente

Sul form di aggiornamento (o una task a livello oggetto eseguita da un pulsante nella griglia), aggiungi una task:

• Condition: status cambiato in Done (o esegui solo quando lo status è Done / Rejected all'invio)
• Action: Send e-mail a {requester_email} con un breve template che spiega l'esito e include {title} / {staff_notes} dove appropriato

Segna una richiesta come Done e verifica che il messaggio arrivi. Se non arriva, vedi Troubleshooting.

5. Rifinitura (opzionale)

• Menu consapevole dei ruoli sulla home del backoffice
• Chart delle richieste per status per i manager
• Display rules per richiedere staff_notes quando lo status è Rejected
• Proteggi i campi riservati allo staff così non compaiono mai sul form pubblico

Checklist

• Il form pubblico crea una richiesta New
• Lo staff può accedere al Backoffice e vedere la coda
• Lo staff può cambiare status e note
• Il richiedente riceve un'e-mail al completamento (o al rifiuto)

Prossimi passi

• Trasforma questo in un blueprint più ricco: Customer portal tutorial
• Rafforza i pattern di accesso: Security overview
• Promuovi in sicurezza in seguito: Production playbook