Last modified: 2013-02-20 14:27:10 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!
> * 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.
(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]).
Some of this functionality will be in the forthcoming DeleteQueue extension.
(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.
(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.
This seems like a really restricted use case. I don't see much if any utility to /any/ of this. Recommend WONTFIX.
*** Bug 17309 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 31645 has been marked as a duplicate of this bug. ***
*** Bug 45181 has been marked as a duplicate of this bug. ***
