C’è un modo per disabilitare queste notifiche senza ricorrere a un trucco CSS? In realtà non ho bisogno di tutto questo rumore visivo.
5 Mi Piace
Ma non mostrerebbe comunque un numero o un indicatore di notifiche? Ma immagino che non ci sia nulla da fare.
Non più 
5 Mi Piace
Questo mi ha tratto in inganno alcune volte e non vedo che sia menzionato sopra come problema.
Non ho l’abitudine di controllare le Modifiche imminenti cliccando sull’opzione del menu a sinistra:
https://xyz.discourse.group/admin/config/upcoming-changes
Quella pagina include un link Anteprima per ogni modifica.
Normalmente, come parte della mia routine quotidiana, controllo la casella di posta di Discourse e a volte trovo una notifica sulle modifiche imminenti, ad esempio:
https://xyz.discourse.group/admin/config/upcoming-changes?changeNamesFilter=enable_ai_bot_starred_conversations
Notate la differenza nell’URL e anche che il link Anteprima è assente.
È proprio quell’assenza del link Anteprima che mi ha tratto in inganno per alcuni giorni. Sapevo che il link esisteva, ma pensavo fosse scomparso.
Spero che questo fornisca dettagli sufficienti per comprendere il problema e possibilmente risolverlo.
Sia il link “Feedback…” che quello “Anteprima” sono opzionali per gli elementi di modifica imminenti:
- Il feedback punterà a un argomento qui su Meta per discutere la modifica
- L’anteprima aprirà uno screenshot della modifica in una lightbox sulla pagina
Spetta allo sviluppatore che aggiunge la modifica imminente specificare queste opzioni… Farò un ping a alcune persone internamente e vedrò se riesco a convincerle ad aggiungerle.
1 Mi Piace
Oggi il pulsante Anteprima appare con l’URL indicato.
https://xyz.discourse.group/admin/config/upcoming-changes?changeNamesFilter=enable_new_checkbox_style
Grazie!
2 Mi Piace
Oggi stavo pensando la stessa cosa…
So che è così sul nostro hosting, ma non ero sicuro di come gestiamo la cosa per chi ospita in autonomia.
Oggi ho cercato la fonte ufficiale per capire cosa facciamo in quel caso e ho scoperto che attualmente aspettiamo fino a stable.
Comunque, è così che abbiamo iniziato a fare le cose: FEATURE: Automatic promotion of upcoming changes - Pull Request #36211 - discourse/discourse - GitHub
E sembra che sia ancora così qui:
Mi chiedo se dovremmo cambiarlo in beta per chi ospita in autonomia?
Nel frattempo, farò una piccola modifica al primo post qui.
1 Mi Piace
Vuoi aggiornare anche la documentazione?
È davvero utile saperlo. Ora capisco perché Martin ha detto che non sposterà la modifica su stabile prima che il problema sia risolto. Avevo controllato la documentazione in quel momento e mi chiedevo quale differenza facesse se beta significasse già “abilitato di default”.
2 Mi Piace
Intendi beta qui?
Mi chiedo anche quanti amministratori perderebbero la possibilità di rinunciare e fornire feedback prima che la modifica diventi permanente, se la rimuovessero dopo averla tenuta in beta, saltando la fase stable (e permanente).
1 Mi Piace
Sì, intendevo beta. Oops, grazie. Corretto.
C’è una PR aperta per apportare quella modifica qui ora:
1 Mi Piace
Quindi stable è rilevante solo per i pochi siti in cui l’amministratore ha modificato l’impostazione del sito nascosto per abilitare le modifiche in seguito?
Come influenzerà questo cambiamento il fatto che non esiste ancora una soluzione per i componenti del tema e la sostituzione del gruppo “everyone”?
Se beta abilita la modifica per tutti, non spostarla in stable
non sembra più così utile. continuerà a causare la rottura dei componenti per quasi tutti i forum.
1 Mi Piace
Esatto. Forse vedremo più siti scegliere di modificare quell’impostazione dopo questo cambiamento. Ma l’impostazione predefinita sarebbe abilitare le cose prima.
Un cambiamento del genere causerebbe più reclami più rapidamente.
Consigliamo alle persone interessate di disabilitarlo finché non lo sistemiamo.
La modifica non diventerà permanente finché non raggiungerà lo stato stabile/permanente, non la rimuoveremo prima… la fase beta la abilita solo per default prima per gli self-hosters. Come dice Dave:
Puoi ancora disabilitarla se ci sono problemi durante la fase beta.
Sto lavorando a questo al momento, dovevo ottenere un consenso interno su come procedere. Finora non abbiamo ricevuto alcun feedback su questo, eccetto il tuo, quindi non penso che stia causando grossi problemi agli amministratori dei siti che sono attualmente in beta.
Credimi, voglio risolvere questo problema tanto quanto te, è una mia modifica, ma ho anche altre priorità che richiedono il mio tempo.
A me è sembrato che i “miglioramenti di reporting” abbiano saltato la fase “stabile”
Forse non capisco proprio come funziona
Non sono sicuro del motivo per cui questa modifica specifica sia stata rimossa in beta invece di essere portata in versione stabile/permanente, farò delle indagini interne.
1 Mi Piace
È stato un errore che abbiamo commesso e abbiamo riportato la modifica imminente in DEV: Reintroduce reporting_improvements upcoming change as permanent … · discourse/discourse@08cf6f4 · GitHub.
Mi dispiace, probabilmente ho un problema di comprensione. Nel PR che hai linkato vedo che l’impostazione è stata nuovamente aggiunta. Ciò che non capisco è quale sia ora il suo effetto. Cosa cambia esattamente a seconda che io attivi o disabiliti la modifica? Non riesco a seguirlo nel codice.
Com’è ora, il passaggio che avrebbe effettivamente abilitato la modifica per la maggior parte dei forum è stato comunque saltato, giusto? Quindi non hanno mai avuto la possibilità di uscire perché stava compromettendo il loro forum, o ho ancora frainteso il processo?
Ho anche cercato di vedere come funziona ora, ma non riesco a trovare la modifica. Qualcuno ha un’idea di cosa sto sbagliando? La versione è 08cf6f4
La funzione è ora permanente, quindi non è una modifica che puoi abilitare o disabilitare.
1 Mi Piace
Quando le modifiche diventano permanenti, appaiono invece su /whats-new. Aggiungerò queste informazioni al post originale, insieme a qualsiasi altra cosa che potremmo aver trascurato negli ultimi mesi.
Modifica: Fatto
1 Mi Piace