robchur wrote:

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?

stigmj wrote:

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?

robchur wrote:

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?

stigmj wrote:

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.

robchur wrote:

Actually, the user rights have nothing to do with any single login feature.

robchur wrote:

If I'm re-reading this right now, then I implemented this in r18496.