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.