Last modified: 2011-11-22 01:06:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T24293, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22293 - Show previous protection level in protection log and via API
Show previous protection level in protection log and via API
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-27 23:17 UTC by SoWhy
Modified: 2011-11-22 01:06 UTC (History)
3 users (show)

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


Attachments

Description SoWhy 2010-01-27 23:17:06 UTC
Currently the entry in the protection log for a changed protection reads like this: 

* 23:59, 31 December 2099 <Admin> (talk | contribs | block) protected <Article> [edit=autoconfirmed] (expires 23:59, 1 January 2100 (UTC)) [move=autoconfirmed] (expires 23:59, 1 January  (UTC)) ‎ (<Reason>)  (hist | change)

What it does not tell you is what protection level the page had before this. Would it be possible to modify the log (and also the values returned by the API) in a way to add this information? An entry should look something like this then:

* 23:59, 31 December 2099 <Admin> (talk | contribs | block) changed protection settings for <Article> [set edit=autoconfirmed from edit=all] (expires 23:59, 1 January 2100 (UTC)) [set move=autoconfirmed from move=all] (expires 23:59, 1 January  (UTC)) ‎ (<Reason>)  (hist | change)

Regards
SoWhy
Comment 1 Gurch 2010-01-28 08:03:42 UTC
(In reply to comment #0)
> * 23:59, 31 December 2099 <Admin> (talk | contribs | block) changed protection
> settings for <Article> [set edit=autoconfirmed from edit=all] (expires 23:59, 1
> January 2100 (UTC)) [set move=autoconfirmed from move=all] (expires 23:59, 1
> January  (UTC)) ‎ (<Reason>)  (hist | change)

This format is a little weird -- it's interleaving the old and new values. It makes the log entires hard to read. I think this might be a bit too much information for the average user. Might be useful in the API though.
Comment 2 p858snake 2010-01-28 08:28:46 UTC
(In reply to comment #0)
> What it does not tell you is what protection level the page had before this.
The log shows all appropriate entries, if there is nothing shown in the log, it means there has never been protection applied and it's using the defaults for that namespace (supplied by the package/localsettings file).
Comment 3 SoWhy 2010-01-28 12:35:11 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > * 23:59, 31 December 2099 <Admin> (talk | contribs | block) changed protection
> > settings for <Article> [set edit=autoconfirmed from edit=all] (expires 23:59, 1
> > January 2100 (UTC)) [set move=autoconfirmed from move=all] (expires 23:59, 1
> > January  (UTC)) ‎ (<Reason>)  (hist | change)
> 
> This format is a little weird -- it's interleaving the old and new values. It
> makes the log entires hard to read. I think this might be a bit too much
> information for the average user. Might be useful in the API though.

Well, it was only an example. It could also look like this: 

* 23:59, 31 December 2099 <Admin> (talk | contribs | block) changed protection settings for <Article> [edit=autoconfirmed] (expires 23:59, 1 January 2100 (UTC)) [move=autoconfirmed] (expires 23:59, 1 January  (UTC)) ‎ (<Reason>)  (hist | change) Previous settings: edit=all, move=all.

The point is, that with previous entries (and many such entries), you need to start calculating whether the protection was a change or a new protection. When blocking for example, the system instead uses "<Admin> blocked <User>" for a new block but "<Admin> changed block settings for <User>" if the new block just modifies the old one. 

Regards
SoWhy
Comment 4 Gurch 2010-02-03 11:04:21 UTC
(In reply to comment #3)

> start calculating whether the protection was a change or a new protection. When
> blocking for example, the system instead uses "<Admin> blocked <User>" for a
> new block but "<Admin> changed block settings for <User>" if the new block just
> modifies the old one. 

The protection log already does that -- it will say "protected" if the page was not protected before, or "changed protection settings" if it was.

What you're asking for is for the settings from the previous protection to be listed too -- the block log doesn't do anything like that.
Comment 5 SoWhy 2010-05-15 19:28:05 UTC
(In reply to comment #4)
> (In reply to comment #3)
> 
> > start calculating whether the protection was a change or a new protection. When
> > blocking for example, the system instead uses "<Admin> blocked <User>" for a
> > new block but "<Admin> changed block settings for <User>" if the new block just
> > modifies the old one. 
> 
> The protection log already does that -- it will say "protected" if the page was
> not protected before, or "changed protection settings" if it was.
> 
> What you're asking for is for the settings from the previous protection to be
> listed too -- the block log doesn't do anything like that.

But block settings can only be modified if someone is blocked, can't they? So if I read "changed block settings", I know that user X was blocked already.
On the other hand, the "changed protection settings" line alone (for example in the Watchlist) does not give us the same information since a change from move-protection to semi-protection uses exactly the same wording as a change from full- to semi-protection, as such the nature of the change is not apparent from the Watchlist and requires one to check the full log for the page.

Regards
SoWhy

PS: Sorry for the late reply, the email notification arrived a few minutes ago only.

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


Navigation
Links