- Mentioned In
- T98929: C1. "Mark as resolved" for Flow topics
T72271: Flow: Moderation reasons should accept the same limited parsing as normal edit summaries
rEFLW7d740c7c446c: Don't run editors on plaintext fields
rMEXTe51cab481209: Updated mediawiki/extensions Project: mediawiki/extensions/Flow…
T96930: Unhide comment from History produces error message
T95445: Unable to use links (and all other wikitext) for moderation reasons
- Mentioned Here
- T62552: Enforce reason requirement when moderating posts in JS
T94122: Flow actions not appearing under contributions in specific namespace, only "all", in some wikis
We might be enabling visual editor in the reason field, but the intention there was for it to always be plaintext. Links and other wikitext should be in the topic summary. At a higher level many people probably don't know how it is supposed to behave, we should reevaluate from a design perspective.
Restricting that field to plaintext will not work, as it is supposed to be the equivalent of closing discussions with templates like
where wiki syntax is widely used.
It's not set in stone, but it's always been plaintext.
Lock reason is not the equivalent to a discussion close template. The summary is the equivalent location for a discussion close template, and allows full wikitext.
[off-topic] Er, the summary is not available when one is closing (locking, in Flow's terminology) a discussion, only the lock reason textarea. Why do we need both anyway? (Just make the summary obligatory for any user locking a topic, as in T62552...) Also, since one can't add a summary once the topic is locked, this will result in people locking->unlocking->summarizing->locking again, instead of just locking+summarizing the discussion in one step.