Last modified: 2006-12-23 13:25:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7994 - Add a group for autopatrol-users and allow selfpatrolling for these.
Add a group for autopatrol-users and allow selfpatrolling for these.
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-11-20 15:47 UTC by Stig Meireles Johansen
Modified: 2006-12-23 13:25 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Stig Meireles Johansen 2006-11-20 15:47:47 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.
Comment 1 Rob Church 2006-11-20 17:17:18 UTC
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?
Comment 2 Stig Meireles Johansen 2006-11-20 18:02:49 UTC
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? 
Comment 3 Rob Church 2006-11-20 18:23:22 UTC
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.
Comment 4 Brion Vibber 2006-11-29 21:50:01 UTC
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?
Comment 5 Stig Meireles Johansen 2006-11-29 22:42:32 UTC
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.
Comment 6 Rob Church 2006-11-29 22:45:53 UTC
Actually, the user rights have nothing to do with any single login feature.
Comment 7 Rob Church 2006-12-23 13:25:40 UTC
If I'm re-reading this right now, then I implemented this in r18496.

Note You need to log in before you can comment on or make changes to this bug.