I can’t edit it anymore! but @erlend_sh did it for us.
if this is a giant post, how do you call that one you’ve linked?! 
1 Mi Piace
We’ve got two excellent use cases for this.
-
Personal journal outlining a member’s trading strategy (think stocks or options trading). Majority of members change their strategy often over the course of their trading lifecycle, and that definitely happens outside of our edit window of 10 days. We have members that are going on 5+ years membership, who still tweak their strategy and want to journal that for themselves or for the rest of the community.
-
Informational posts, where the first post is edited to reflect changes to say a list of companies that caters to our members. The company names changes, some stop catering to us, etc. We have a topic that’s been running for over 8 years. The first several posts are a running list, with company information. The remaining posts are the discussion about said companies.
The workaround has been the wiki post, but that doesn’t give the OP complete control over the post, and leaves us open to spammy actions.
We’re looking for a hybrid approach, give the OP indefinite edits on at least the first post, or allow the OP to set how many of the first several posts he can edit (as long as he’s the author of those posts, so something like the first 5 posts, for instance). All existing permissions/rules about the edit window would still apply, except for the OP.
vBulletin had/has this in a plugin.
Not really, since spammers are quite unlikely to reach trust level 1, and that is required to edit wikis.
1 Mi Piace
We’ve experienced… committed spammers who’ve done that in the past. Not at any large scale, but it’s happened. We’re actually dealing with a web of such folks (a company) who purposefully created 10+ accounts to legitimately discuss the topics at hand while name dropping their most favorite broker (their company) every couple of weeks. We just uncovered this going back over a year on a handful of accounts. It’s very subtle, but upon further investigation, IPs are similar, locations are close, email address are created in the same style (name+number@domain.com), and the accounts exhibit the same posting behavior (times, frequency, categories they post to, who they like, who they reply to). It’s pretty crazy the lengths they go to.
3 Mi Piace
Here on Meta there have been spam users who earned the wiki editor badge, but as wiki edits aren’t shown in activity I wasn’t able to revert whatever it was they changed before reporting them.
1 Mi Piace
Il Forum di Elixir dispone di alcune categorie (ad esempio, “Community / Profili degli sviluppatori”, “Le tue librerie e progetti”) il cui contenuto tende a essere persistente ma in continua evoluzione. Di conseguenza, beneficerebbero di una maggiore granularità nella limitazione del tempo per la modifica.
Recentemente, AstonJ ha fatto il seguente commento nel thread (solo per membri) Puoi aumentare il limite di tempo per la modifica dei post?:
Sarebbe fantastico se Discourse permettesse di impostare determinate sezioni in modo che l’autore del thread possa modificare il primo post nei thread da lui avviati all’infinito. Questo sarebbe utile anche per thread dedicati a librerie
Sarei disposto a provare a creare una PR a riguardo, ma prima vorrei sapere se l’idea generale è accettabile. Saranno apprezzati anche suggerimenti su come e dove configurare questa opzione.
-r
1 Mi Piace
Perché? I post della wiki soddisfano già questo obiettivo.
I post wiki non consentono all’autore originale di controllare le modifiche successive.
È stato un problema solo in teoria o anche nella pratica? Spesso le due cose sono molto diverse.
Oltre a questo, perché non estendere semplicemente il tempo limite per le modifiche in base al livello di fiducia (TL2+) a qualcosa di molto lungo, come 2 anni?
Non sono sicuro del motivo per cui serva un’altra impostazione qui.
Oggi ho avuto proprio questo problema. Circa un anno fa, ho pubblicato un post nella sezione “Community / Profili Sviluppatori” del Forum di Elixir. Conteneva un URL che sto deprecando, quindi volevo sostituirlo con quello nuovo. Anche se AstonJ è stato così gentile da eseguire la modifica per me, sarebbe stato più comodo poterlo fare da solo.
Oltre a ciò, perché non estendere semplicemente il timeout per la modifica in base al livello di fiducia (TL2+) a qualcosa di molto lungo, come 2 anni?
Questo potrebbe funzionare per alcuni casi d’uso, ma in generale non sembra una buona idea. (Se un post ha accumulato risposte e viene poi modificato, il flusso della discussione potrebbe confondersi.) Quindi, solo alcune categorie dovrebbero comportarsi in questo modo.
3 Mi Piace
Forse l’opzione più semplice sarebbe modificare le wiki in modo che possano essere impostate per consentire la modifica solo al creatore del post (diventando così, in un certo senso, una wiki personale).
Ciò ci permetterebbe di utilizzare la funzionalità esistente delle wiki (dove possiamo impostare le categorie per rendere automaticamente il primo post una wiki), evitando al contempo gli inconvenienti del loro utilizzo in casi come questo, in cui chiunque potrebbe potenzialmente modificare ciò che è altrimenti un post o una wiki personale di qualcuno.
1 Mi Piace
Penso che il wiki consenta il controllo.
Il proprietario del post viene notificato ad ogni modifica. Se viene apportata una modifica errata, può annullarla. Se si verifica una lite, il post può essere segnalato e i moderatori possono intervenire.
Un grande motore per una nuova funzionalità sarebbe il fatto che abbiamo già provato quanto sopra, ma viene creato un’enorme quantità di lavoro inutile.
Ci sono esempi reali di problemi in questo ambito?
Non funzionerebbe una nota a piè di pagina del tipo: “Questo è un wiki personale, correggere solo per errori di battitura”?
Un’interessante sfumatura che sostengo in parte è la segnalazione automatica dei post wiki quando il proprietario non è più disponibile; in questi casi, i moderatori dovrebbero o rimuovere la modalità wiki o riassegnare la proprietà.
4 Mi Piace
Query rapida per “Creatori di Wiki Assenti”:
SELECT (current_timestamp - users.last_seen_at) idle_duration,
(current_timestamp - posts.created_at) post_made_ago,
posts.id post_id, users.id user_id
from posts
join users on posts.user_id = users.id
join topics on posts.topic_id = topics.id
where posts.wiki = true
and posts.deleted_at IS NULL
and topics.deleted_at IS NULL
and users.last_seen_at < CURRENT_TIMESTAMP - INTERVAL '90 days'
order by idle_duration desc
4 Mi Piace
