• 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.

millosh wrote:

(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.

mike.lifeguard+bugs wrote:

This seems like a really restricted use case. I don't see much if any utility to /any/ of this. Recommend WONTFIX.

herd wrote:

*** Bug 17309 has been marked as a duplicate of this bug. ***

ssanbeg wrote:

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

tisane2718 wrote:

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. ***

I have added project MediaWiki-Core-Team for reason this task is also to do with core of mediawiki.

@Paladox: Does not make sense as this task is closed for good as declined. Please do not add random projects to tasks (you have been told so before).

But I have explaned why I added this time I wont add random projects again but that wasent random project either.

Could this be reopended since a lot has changed since 2009.

No reopening without convincing *arguments* *what* *exactly* has changed since 2009 and why that matters. Time itself is not a factor otherwise we could reopen every bug that once was closed as declined after a few years.
Plus you are free to work on a patch for your private instance and share it...

I have put forward an argument for this feature at https://test.wikipedia.org/wiki/Wikipedia_talk:Requests/Permissions , but do appreciate it is of limited utility. On test wikis, it is useful for people to use admin functions on 'own' pages (no other editor, irrespective of namespace), without having access to all admin-deleted pages which could have content that should be (but hasnt been) suppressed.