Author: FT2.wiki
Description:
To allow filters to expire at a given time, as with other blocks, protects, and anti-vandalism measures.
A filter would then be "active" or "inactive" and would be capable of being switched on for a given time period (and reactivated if needed again), rather than merely an option to manually add or remove.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T20247 Allowing "per page" filters | |||
| Duplicate | None | T20246 Expiry time option, on filters |
MacGyverMagic wrote:
I don't see a particularly good reason for that. Blocks are temporary because they're not punative and stop someone from making any edits at all rather than the problematic ones. Protections and other anti-vandalism measures (whatever those are) are temporary because of collateral damage. None of that is an issue with filters.
FT2.wiki wrote:
These tools all fall in the category of "measures available to forcibly reduce and prevent disruption and problem editing".
Communally, blocks are not used "punitively", and at this time filters are still being rolled out and used mainly for well known long term issues. But this doesn't mean that we could not, in future, use filtering on a "limited period of time" basis -- to detect, warn, and prevent types of abuse that may be transient or topical, and which may not need permanent filtering for years to come.
Added a timestamp variable in r49107. When this is deployed, you can use "timestamp < someunixtimevalue" as a condition to add expiries for filters.
Reopening. The timestamp way is only a temporary solution, not a user-friendly one. Also, it might be hard to notice at a first glance.