Continuando la discussione da Come funzionano i badge di lettura delle linee guida?:
Come si potrebbe riutilizzare questo per un badge personalizzato, dove l’utente riceverà automaticamente il badge dopo aver letto i termini?
Questo per il badge “leggi le linee guida”:
e anche questo… anche se non so dove inserire l’SQL per il badge:
…oltre alla domanda sottostante se /tos è considerato un argomento se gli utenti possono vederlo solo dalla visualizzazione delle schede:
Questo aiuta?
Ooh, sembra che mi aiuterà/guiderà nella giusta direzione! Grazie!
Non sono sicuro che sia possibile collegarne uno simile ai ToS invece nello stesso modo. 
Quello di read_faq si basa sul fatto che read_faq sia registrato nella tabella user_stats e attualmente non esiste un meccanismo per fare lo stesso per i ToS.
Poiché la versione visualizzabile dall’utente non è l’argomento effettivo, non credo che la visualizzazione di quella pagina sia registrata da qualche parte (come topic_views ecc.).
È possibile modificare il database/le tabelle per includere un nuovo read_tos?
Esiste potenzialmente una soluzione alternativa brutta…
…pubblicare un argomento come una pagina pubblicata invece di usare l’integrazione senza interruzioni come FAQ e Chi siamo. Non so se funzionerà davvero…
Test e risultati:
La query SQL restituisce gli utenti che hanno letto l’argomento e quindi dovrebbero ricevere il badge, ma non ho ricevuto tale notifica.
Posso confermare che le visite a /pub/slug senza visitare direttamente l’argomento aggiorneranno il conteggio delle visualizzazioni dell’argomento… tuttavia, anche con un tempo di lettura incredibilmente basso, il badge non è stato concesso automaticamente.
È anche da notare che l’argomento stesso indica ancora come nuovo e non letto per l’utente.
…
Ulteriori risultati di test di isolamento indicano che la query SQL implica che gli utenti devono visitare direttamente l’argomento per essere considerati come aver letto l’argomento. Non posso confermare né negare, poiché il badge non è stato assegnato, ma è molto plausibile.
Quando viene eseguito il trigger di “aggiornamento giornaliero”?
Sai per caso cosa ha fatto il team quando ha aggiornato i Termini di Servizio (ToS) in cui dovevamo confermare di averli letti? Anche se non era un badge, potrebbe essere stato il plugin Policy?
Puoi velocizzare questa parte attivando manualmente jobs::BadgeGrant dalla tua pagina /sidekiq/scheduler (per chi ha accesso). Il mio è stato eseguito 3 ore fa, ma varierà da sito a sito.
Se non ti dispiacesse averli in un normale topic, potresti crearne uno nuovo e aggiungere il link alle tue impostazioni di amministrazione tos url in modo che appaia comunque nelle schede. Potresti quindi assegnare un badge abbastanza facilmente in base alle persone che visualizzano quel topic (anche se i tuoi esperimenti con le pagine pubblicate potrebbero dare buoni risultati 
)
Penso che per farlo allo stesso modo di “Leggi le linee guida” dovresti creare un plugin per replicare il comportamento per i ToS (anche se non è il mio forte, quindi prendi questa informazione con le pinze 
)
Questo è un campo personalizzato obbligatorio, che penso funzioni abbastanza bene per questo scopo. Anche se dici solo di averli letti piuttosto che averli effettivamente letti, quindi potrebbe dipendere da qual è lo scopo principale dell’assegnazione del badge.
Aspetta, questo è davvero intelligente!
Potresti quindi anche chiudere e rimuovere l’elenco dall’argomento in modo che non possa essere risposto e debba essere accessibile tramite un link diretto.
Sfortunatamente, questo non funzionerebbe in modo così diretto come sopra.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
