Blog ·
Una scorciatoia è un riferimento, non un diritto
Sei schede da aggiungere al cruscotto e scorciatoie che compaiono solo se chi guarda ha ancora il diritto di vedere l’oggetto oggi. Due ritrovamenti veri.
Di Provibr
Il cruscotto di un pannello di hosting è la schermata che tutti vedono per prima e su cui quasi nessuno ha un’opinione finché non è impostata male per lui. La richiesta era modesta: lasciare che le persone aggiungano schede, e che mettano scorciatoie verso un server o un’integrazione a cui tornano di continuo.
Le richieste modeste sono il luogo in cui si nascondono le decisioni interessanti, perché una scorciatoia è una preferenza salvata che punta a un oggetto reale con permessi reali. Sbagliare quel rapporto è il modo in cui un pannello finisce per mostrare a qualcuno una macchina da cui è stato tolto tre mesi fa.
Sei schede, nessuna migrazione, e nulla arriva senza chiederlo
Le schede aggiungibili sono sei: un elenco di agenti, un elenco di server, un elenco di integrazioni, un elenco di segnalazioni, il credito e una scorciatoia. Tutte e sei sono a mezza larghezza, perché sono panoramiche affiancate e non qualcosa che richieda l’intera riga.
La disposizione è salvata come JSON, e questo giro non ha aggiunto migrazioni. È una decisione e non una dimenticanza. Una voce era un identificativo e un indicatore di nascosto; ora porta anche un identificativo di istanza e una configurazione per scheda. Una riga vecchia si rilegge pulita nella forma nuova, con l’identificativo di istanza completato da quello della scheda e la configurazione vuota, e una prova verifica esattamente questo: una disposizione vecchia si rilegge come le stesse schede nello stesso ordine. Qui una migrazione metterebbe solo una marca temporale nel diario, e una marca temporale che poi risulta troppo alta è un problema vero per il giro successivo.
La seconda regola è che una scheda facoltativa non compare mai da sola. Esiste un ciclo che aggiunge le schede che una disposizione non nomina, così che una nuova scheda fissa compaia da tutti, e quel ciclo copre di proposito solo quelle fisse. Se ne facesse parte una facoltativa, «aggiungere» smetterebbe di essere un’azione e ogni cruscotto del prodotto crescerebbe a ogni pubblicazione di una scheda che nessuno ha chiesto.
Quali schede manchino è una decisione tanto quanto quali ci siano. La sorveglianza e le copie di sicurezza esistono nel codice dietro bandiere di rilascio spente, quindi una scheda per loro sarebbe una scheda senza utenti. L’attività recente è rimasta fuori perché esiste già come scheda fissa.
Due metà di una sola regola
Nella disposizione salvata di una persona una scorciatoia non è altro che un tipo e un identificativo. Tutto ciò che arriva sullo schermo, il nome, lo stato, il collegamento, viene recuperato di nuovo a ogni caricamento di pagina con i permessi di chi guarda in quel momento. Quella regola ha due metà ed entrambe servono.
La prima è il modulo. Un membro che perde il modulo degli agenti smette di vedere la sua scorciatoia verso un agente, anche se resta nella sua disposizione. Questa porta conosce anche le superfici: sul dominio di marca proprio di un cliente, dove la fatturazione non esiste affatto, la scorciatoia verso il credito sparisce quindi per costruzione e non per una seconda regola scritta apposta.
La seconda è l’interrogazione sull’oggetto. L’identificativo di organizzazione sta in ogni WHERE, il filtro di cancellazione morbida accanto, e per un server accanto ancora l’ambito di server di quel membro. Un server mai assegnato a un membro per lui non esiste, e questo deve valere anche per una scorciatoia creata quando ancora poteva vederlo.
La scheda scorciatoia è anche l’unica senza modulo e l’unica che può esistere più di una volta. È corretto e non trascurato: una scorciatoia non è una schermata a sé, è un riferimento a una schermata che porta già il proprio diritto. Se il tipo di scheda portasse un modulo, chi ha quel modulo potrebbe vedere una scorciatoia verso qualcosa che non può aprire.
Modulo tolto e oggetto sparito sono eventi diversi
Due cose che sullo schermo sembrano uguali ricevono trattamenti opposti.
| Cosa è successo | Cosa vede chi guarda |
|---|---|
| Il modulo è stato tolto | La scheda sparisce senza una parola, e torna con il modulo |
| L’oggetto non è stato trovato | Una scheda che dice che non esiste più, con un pulsante per toglierla |
La prima è silenziosa perché la scorciatoia non è la storia. Se il ruolo di qualcuno è cambiato, la scorciatoia mancante è un sintomo, e annunciarla sul cruscotto sarebbe rumore sopra un cambiamento che già conosce. Torna inoltre intatta appena torna il modulo, cosa possibile solo perché non è stato cancellato nulla.
La seconda è rumorosa perché la persona non ha sbagliato nulla e le è stato tolto qualcosa. Di proposito non è un 404 né un messaggio di errore: solo una scheda che nomina la situazione e si offre di sistemarsi da sola.
Mostrare con tolleranza, non ripulire alla cancellazione
L’alternativa ovvia è togliere le scorciatoie quando il loro oggetto viene cancellato. Non l’abbiamo fatto, e il ragionamento merita di essere annotato perché la decisione opposta è stata presa altrove nella stessa base di codice: quando un membro lascia un account, la sua disposizione salvata viene davvero dimenticata, perché quella riga non tocca alcuna cascata e altrimenti resterebbe per sempre in un account dove non torna mai.
Qui la bilancia pende dall’altra parte, per tre motivi.
Sparire ha più cause che cancellare. Un membro perde un modulo, cambia il suo ambito di server, guarda su un dominio di marca. Nessuna routine di pulizia intercetta quei tre casi, quindi la via tollerante deve esserci comunque, e un secondo meccanismo diventa solo un posto in più che può sfasarsi.
La disposizione è salvata per persona. Un server cancellato costringerebbe a riscrivere il JSON di ogni membro dell’organizzazione, dentro una transazione sulla via di cancellazione. È amplificazione di scrittura su una via calda in cambio di una preferenza di schermata.
E non c’è nulla da proteggere. La riga salvata è un UUID di un oggetto della propria organizzazione e nient’altro. Non lascia trapelare nulla, non cresce, e la persona vede subito che può andarsene.
La prova da capo a fondo è ruvida di proposito. Dopo una cancellazione morbida il server non torna, e il suo nome non compare in nessun punto dell’uscita. Un membro senza il modulo degli agenti non ottiene né agente né integrazione, e il selettore non glieli propone. Un ambito di server vuoto dà zero righe e non tutto.
Due ritrovamenti che solo una prova reale ha dato
I due difetti veri di questo giro erano entrambi invisibili alle prove unitarie, ed entrambi sono costati una decina di secondi non appena qualcosa di reale era in funzione.
Il selettore ha un campo di ricerca, e cercare integrazioni rompeva l’intero selettore con un errore di base dati. Il motivo è che la colonna del tipo di integrazione è un tipo enumerato di Postgres, e per un enumerato non esiste un operatore di modello insensibile alle maiuscole: l’interrogazione ha restituito 42883 operator does not exist, e poiché quell’interrogazione alimentava tutto il selettore non compariva assolutamente nulla. Convertire la colonna in testo lo risolve. Nessuna prova unitaria con un esecutore simulato l’avrebbe visto, perché una simulazione non ha tipi.
Il secondo è uscito dalla scansione di accessibilità. Una piastrella di scorciatoia è un nome, uno stato e un tipo, e l’insieme è cliccabile. La prima versione metteva tutto in un solo collegamento, e la verifica ha segnalato uno scarto tra il nome accessibile e l’etichetta visibile, perché il testo nascosto conta per il nome accessibile. La piastrella ora è un contenitore ordinario con un collegamento che porta solo il nome e un’area di clic assoluta e vuota che raccoglie il clic. Questo ha portato un secondo problema, più piccolo: la classe di troncamento sul collegamento tagliava quell’area alla larghezza del testo, così la maggior parte della piastrella non era più cliccabile. Il troncamento si è spostato su un elemento interno e la copertura è stata misurata invece che supposta.
Cosa annoteremmo
- Salvi un riferimento, risolva un diritto. Nella preferenza va un identificativo. Ciò che arriva sullo schermo va recuperato ogni volta con i permessi di chi guarda.
- Una colonna senza schema è una migrazione che non deve scrivere. Ma solo se può dimostrare che la forma vecchia si rilegge identica, e questo è una prova.
- Facoltativo significa su richiesta, per sempre. Una scheda che compare da sola fa di «aggiungere» una parola senza contenuto.
- Distingua cancellato da irraggiungibile. Sullo schermo sembrano uguali e meritano il trattamento opposto: silenzio per l’uno, una spiegazione per l’altro.
- Non ripulire può essere la scelta più forte. Se lo stesso sintomo ha cause che la sua pulizia non vede, la via tollerante deve esserci comunque, e la pulizia diventa solo una seconda cosa da tenere allineata.
- Faccia girare la cosa. Un enumerato senza operatore di modello e un collegamento che taglia la propria area di clic si vedono in un attimo in un browser, e non si vedono affatto in una batteria di prove senza base dati.
Per chiarezza su cosa sia tutto questo: le schede qui descritte sono in produzione per ogni account. Diverse cose non sono dimostrate. Il riordino con il mouse non è stato guidato, le schede di sorveglianza e di copia dietro bandiera non esistono e la loro via di codice non è quindi mai stata percorsa, il dominio di marca è stato controllato in un’interrogazione e non in un browser, e una scheda appena aggiunta compare solo dopo il giro successivo del server.
Dal lavoro di piattaforma di Provibr. Cosa vede e cosa non vede un cliente del nostro cliente su un pannello di marca è spiegato in pannelli in marchio bianco: cosa vede il cliente, e perché una schermata di sintesi non riscriva mai nelle tabelle che legge è spiegato in proiettare, mai sostituire.