Last modified: 2013-02-20 14:27:10 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 14325 - Admin functions for (autoconfirmed) users
Admin functions for (autoconfirmed) users
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
unspecified
All All
: Lowest enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 17309 31645 45181 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-29 04:26 UTC by Milos Rancic
Modified: 2013-02-20 14:27 UTC (History)
7 users (show)

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


Attachments

Description Milos Rancic 2008-05-29 04:26:07 UTC
I think that a couple of enhancements are needed for contributors at least at Wikimedia projects. Usually, I was asking for admin rights on various projects only because of some of those possibilities:

* Delete if I am the only author of the article.
** If user is the only author of the article, they should be able to delete that article. If misused, admins may recover them, which should be automatically treated as an article to which contribution is given by more than this user.
* Delete if the page is under my namespace.
** This is, also, useful. If someone else needs this article, admin may recover it and put under someone's else user space or under project or any other name space.
* Undelete if I deleted it.
** This is especially needed for anti-vandal fighters, usually for Small wiki monitoring team: If someone made a mistake by deleting some article, they should be able to undelete it, too.
* Protect/unprotect if the page is under my namespace.
** If someone wants to keep some information out of a possibility to others to change it, it may be useful, too. Edit such article is not important because user would be able to unprotect, edit and protect it again.

Thanks!
Comment 1 Max Semenik 2008-05-29 14:14:20 UTC
> * Delete if the page is under my namespace.
> ** This is, also, useful. If someone else needs this article, admin may recover
> it and put under someone's else user space or under project or any other name
> space.

Simple exploit: move a page to your own userspace and delete.

> * Undelete if I deleted it.
> ** This is especially needed for anti-vandal fighters, usually for Small wiki
> monitoring team: If someone made a mistake by deleting some article, they
> should be able to undelete it, too.
> * Protect/unprotect if the page is under my namespace.
> ** If someone wants to keep some information out of a possibility to others to
> change it, it may be useful, too. Edit such article is not important because
> user would be able to unprotect, edit and protect it again.

In addition to exploits as above, there are problems with ownership: even your userspace is not yours exclusively, or as most wikis' policies say.
Comment 2 Milos Rancic 2008-05-30 06:04:40 UTC
(In reply to comment #1)
> > * Delete if the page is under my namespace.
> > ** This is, also, useful. If someone else needs this article, admin may recover
> > it and put under someone's else user space or under project or any other name
> > space.
> 
> Simple exploit: move a page to your own userspace and delete.
> 
> > * Undelete if I deleted it.
> > ** This is especially needed for anti-vandal fighters, usually for Small wiki
> > monitoring team: If someone made a mistake by deleting some article, they
> > should be able to undelete it, too.
> > * Protect/unprotect if the page is under my namespace.
> > ** If someone wants to keep some information out of a possibility to others to
> > change it, it may be useful, too. Edit such article is not important because
> > user would be able to unprotect, edit and protect it again.
> 
> In addition to exploits as above, there are problems with ownership: even your
> userspace is not yours exclusively, or as most wikis' policies say.
> 

OK, so, it seems that delete/undelete/protect/unprotect for user under their user namespace is not so clever addition. However, other two permissions are still useful ("delete if i am the only contributor" and "undelete if I deleted" [with possibility to see deleted versions]).
Comment 3 Andrew Garrett 2008-08-08 10:35:23 UTC
Some of this functionality will be in the forthcoming DeleteQueue extension.
Comment 4 od_mishehu 2008-09-24 05:50:36 UTC
(In reply to comment #1)
> > * Delete if the page is under my namespace.
> > ** This is, also, useful. If someone else needs this article, admin may recover
> > it and put under someone's else user space or under project or any other name
> > space.
> 
> Simple exploit: move a page to your own userspace and delete.
> 

Solution to the exploit: Only allow this for pages which had never been moved. 
Comment 5 Andrew Garrett 2008-09-24 06:21:18 UTC
(In reply to comment #4)
> (In reply to comment #1)
> > 
> > Simple exploit: move a page to your own userspace and delete.
> > 
> 
> Solution to the exploit: Only allow this for pages which had never been moved. 
> 

Sounds like a hacky way of dealing with one particular manifestation of a more general problem.

The general problem is that userspace is not "owned" by the user in any meaningful sense, except that it tends to be used by that particular user (by convention).

It does not do to grant users extra permissions or control over their userspace, even if these permissions/controls are already granted to the user in a ''de facto'' sense by community convention.
Comment 6 Mike.lifeguard 2008-11-25 03:49:00 UTC
This seems like a really restricted use case. I don't see much if any utility to /any/ of this. Recommend WONTFIX.
Comment 7 Splarka 2009-04-08 20:05:41 UTC
*** Bug 17309 has been marked as a duplicate of this bug. ***
Comment 8 Steve Sanbeg 2009-04-15 20:27:19 UTC
It seems like the goal of this is to encourage a sense of ownership of pages; but MediaWiki tries to discourage that, so I don't see how that's compatible.  I think the main utility of it is to allow users to wall off their own space, and to take back their contributions if they get mad.  I'll second WONTFIX
Comment 9 tisane2718 2010-03-24 05:04:02 UTC
I favor implementation of the first part, allowing users to delete pages that they are the sole author of. There should be a configuration setting allowing this ability to activated or deactivated by the site owner. I suppose there are a few different ways this could be implemented. A table of pages having only one author could be created. Or another column could be added to the page table that would initially contain the user_id of the sole author, and later would become blank after another author makes an edit.

Either way, a query to retrieve this data would be executed whenever a page is viewed, so as to determine whether the "Delete" tab should appear. There would also probably need to be a hook, perhaps on ArticleSaveComplete, to update the field when a second author edits a page that previously had only one author.

We might also consider another configuration setting to allow/disallow non-sysops to undelete pages that were deleted by non-sysops. Actually, this whole issue may be mooted by pure wiki deletion (Bug 3843), because that would provide essentially the same functionality as what is proposed here. So maybe we should see how things work out with PWD before reopening this bug.
Comment 10 Chad H. 2011-10-12 13:50:39 UTC
*** Bug 31645 has been marked as a duplicate of this bug. ***
Comment 11 Kunal Mehta (Legoktm) 2013-02-20 14:27:10 UTC
*** Bug 45181 has been marked as a duplicate of this bug. ***

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


Navigation
Links