Last modified: 2008-09-11 07:20:17 UTC
Now that protection changes show up in the history (which makes sort-of sense), could the deletion and undeletion of a page with such history entries have the desired effect on the page's protection status? For example, when undeleting a page with some entries one of which makes it move-protected selected, the newly-undeleted page should also be move-protected. Not sure if deletion/undeletion makes absolute sense, but it's the logical extension of having the protection settings' settings shown in the history (at least, I just /tried/ to do it, expecting that behaviour).
Protection status isn't stored with deleted content. If bug 4145 were implemented, we could store it there, although we might face issues where recreated pages were protected. One workaround might be to wipe the protection status when the page is being created (during EditPage::attemptSave()) and ignore restrictions on pages which don't exist. This would, however stop us implementing nice unwiki features such as preventing a page from being created, at least based around the protection tool.
*** Bug 6202 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Protection status isn't stored with deleted content. If bug 4145 were > implemented, we could store it there, although we might face issues where > recreated pages were protected. > > One workaround might be to wipe the protection status when the page is being > created (during EditPage::attemptSave()) and ignore restrictions on pages which > don't exist. This would, however stop us implementing nice unwiki features such > as preventing a page from being created, at least based around the protection tool. By the way, something similar to this: when a page is moved, the protection history doesn't move with it. Thus, when someone clicks protect and finds that it is already protected, s/he will see nothing in the log displayed if the article was first protected under the former title. It would make sense to change this, since the protection is of the current page, regardless of the title.
*** This bug has been marked as a duplicate of bug 12343 ***
