Last modified: 2008-09-13 05:35:22 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 12650 - It should be possible to enter expiry dates for edit and move protection separately
It should be possible to enter expiry dates for edit and move protection sepa...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Alex Z.
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-16 04:50 UTC by Gurch
Modified: 2008-09-13 05:35 UTC (History)
5 users (show)

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


Attachments
Patch (15.43 KB, patch)
2008-08-23 19:03 UTC, Alex Z.
Details
cleanup/docs (15.65 KB, patch)
2008-08-23 20:35 UTC, Alex Z.
Details

Description Gurch 2008-01-16 04:50:04 UTC
To prevent screw-ups such as this one: http://en.wikipedia.org/w/index.php?title=Special:Log&page=Christianity
Comment 1 Roan Kattouw 2008-01-16 13:50:44 UTC
This is possible database-wise, the UI should just have two Expiry input boxes.
Comment 2 Luna Santin 2008-01-18 01:08:54 UTC
Not quite duplicates, but I think Bug 10079 might handle this problem more completely. Aside from protection expiry removing old move-protection, it can also remove old semi-protection (suppose a contentious page has long been under semi, to deal with vandalism, and is temporarily given fullprot, to stop an edit war; should the vandals be let back in, when protection expires?).
Comment 3 flyguy649 2008-04-25 15:57:48 UTC
This would also be useful for pages that are permanently move protected, like WP:ANI, that require short-term semi-protection because of IP vandalism.
Comment 4 Random832 2008-04-25 18:13:03 UTC
Is it possible to fully protect with an expiration and have it expire to semi-protection?
Comment 5 Brion Vibber 2008-04-29 20:15:57 UTC
(re: expiring from one level to a lower level of protection) Not at this time, though that might indeed be handy.
Comment 6 Alex Z. 2008-08-23 19:03:24 UTC
Created attachment 5210 [details]
Patch

Adds an expiry input for each protection type, as noted, the database already supports this. $mRestrictionsExpiry in Title.php and $mExpiry in ProtectionForm are now arrays with the action as keys. If any extension uses these it could potentially break it.

The only outstanding problem is cascading protection. If one protection expires before the other, the page will be left with partial cascading protection (move-only cascading protection). I can think of a few possible solutions for this, not sure which is most desirable:

1. Leave as is.

2. Require all the expiration times to be the same when using cascading protection.

3. Add a pr_cascade_expiry field to the page_restrictions table set to the shortest single expiry time, to have cascading protection expire when the first protection level expires.

4. Only apply the cascading protection to the database row where pr_type = 'edit', and have the cascading protection functions loop over $wgRestrictionTypes when applying restrictions.
Comment 7 Alex Z. 2008-08-23 20:35:46 UTC
Created attachment 5211 [details]
cleanup/docs

Same as previous patch, some code cleanup and docs in protect.js. Everything in previous comment still applies.
Comment 8 Aaron Schulz 2008-09-07 05:30:42 UTC
If you made only the 'edit' restriction level row have pr_cascade = 1, I would still cascade to pages that use it without any new iterations.
Comment 9 Aaron Schulz 2008-09-07 23:32:41 UTC
Should be fixed in r40601 if auto-reviewing is on. Use of rev_timestamp can more so should deal with any other issues.
Comment 10 Aaron Schulz 2008-09-07 23:33:13 UTC
(In reply to comment #9)
> Should be fixed in r40601 if auto-reviewing is on. Use of rev_timestamp can
> more so should deal with any other issues.
> 

Bah, wrong bug :)
Comment 11 Alex Z. 2008-09-13 05:35:22 UTC
Done in r40770.

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


Navigation
Links