Last modified: 2006-12-23 13:25:40 UTC
When using patrolled edits and only letting admins do the patrolling, it would be substantially easier if we could let certain users mark their own edits as approved automatically (and only automatically). I would suggest a new group called "autopatrol" which allows the user to use the patrol-function for his own edits, but it should at the same time *not* allow the user to patrol other edits. The "autopatrol"-group should allow the user to set the tog-autopatrol setting in the user-preferences. When submitting a edit, the RecentChange::markPatrolled( $rcid ); should be called for these users as well as for the "normal" cases.
That doesn't quite make sense to me. If we trust a user's edits, then surely we trust their judgement as far as patrolling is concerned?
That may very well be a correct assumption, and it would probably make the implementation a very small fix? So if we remove the "but it should at the same time *not* allow the user to patrol other edits." bit, what about it then?
Then we could alter the behaviour of the option altogether, taking away the preference, and making it the standard behaviour. Thus, the existing rights framework would handle it. That's what bug 5411 comment 2 refers to. On the other hand, this doesn't solve the problem as raised, which would now be modified to be a means of marking certain users as trusted, and assigning them patrol rights. Giving out rights on an individual basis like this is the focus of bug 3317.
Is there anything further that needs to be done for this to work if an appropriate group is added on a wiki maintained by the OP? Or is this actually a request to create such a group on some of Wikimedia's own wikis, which would require some additional ways to maintain group membership at the bureaucrat (non-steward) level for those particular wikis?
This was actually a request to modify some code specifically in Article.php to allow selfpatrolling when member of a certain group (not sysop). The arguments by Rob has changed this in a way to be a request for the same features as he said should be implemented in bug 3317. That is a more detailed "User rights" scheme, which maybe should be based on group-memberships (my comment). Until this is made a priority there will be even more requests like this for specific hacks. The user rights should be a natural part, or followup, of the SUL-feature.
Actually, the user rights have nothing to do with any single login feature.
If I'm re-reading this right now, then I implemented this in r18496.
