Hi - is this still something you'd like to work on, or shall we move it to the abandoned-by-author section on the RfC archive page? Thanks!
Talk:Requests for comment/Itemise protection
Seems like a good idea -- I've seen issues from time to time where something got accidentally unprotected instead of downgraded from one protection level to another (especially if you just let the higher-level setting expire naturally).
Multiple interacting settings can be a bit confusing though, so it probably needs more attention to the user interface design -- that whole form needs a redo to begin with. :)
I'd like to also see some thought on the interface. But it should also be possible to make the backend changes without touching the existing UI much.
Definitely; the current UI interface is pretty cruddy. If we're now referencing protections as unique object, there should probably be some refactoring on the backend into a Protection class (or maybe "Restriction"??), and then frontend interfaces rather similar to Special:BlockList (for listing protections of a given type or as applied to a particular page) and Special:Unblock (for removing protections, although this would be nicer as a checkbox list of protections-to-remove, as suggested).
Agreed that the UI may need to be overhauled rather than merely added to in the long term.
I've implemented the proposal without recourse to a Protection/Restriction class, but it's certainly possible.
So in other words, I agree :) But do any of these suggestions block work, or is it better to make the change and then refactor? (That's an honest question: I've never worked on designing proper software before, so I don't know which turns out better in reality.)
[Addendum: Also Brion's suggestion of reforming protection logging, although presumably that would move logging into page_restrictions/protected_titles, which is a fairly major operation by my reckoning.]
I think if the page protection scheme is going to be redone, it should allow for customizable protection levels. The current none/autoconfirmed/sysop configuration is highly inflexible and often results in people being forced to choose the lesser of the evils.
It should be possible to specify that a certain page can't be edited or moved or created by people whose accounts are newer than X or who have fewer than Y edits. I'm not sure if this belongs in a separate proposal or should be incorporated into this one, I just think it's desperately needed and that any rewrite of the protection logic should include it.
It is just about possible to implement this logic, but I agree that it's horribly painful to do so. On the other hand, I think direct fine-grained logic like this is probably best implemented in the AbuseFilter; I'd say that protection should continue to be based on user groups.
There are no older topics