prop=info&inprop=protection sometimes shows protection multiple times
Open, LowestPublic

Description

The url shows:

<protection>
  <pr type="edit" level="sysop" expiry="infinity" />
  <pr type="edit" level="sysop" expiry="infinity" />
  <pr type="move" level="sysop" expiry="infinity" />
  <pr type="move" level="sysop" expiry="infinity" />
  <pr type="edit" level="sysop" expiry="infinity" />
  <pr type="move" level="sysop" expiry="infinity" />
</protection>

Why get each type added three times to the output?

It is not better to get it unique?

Thanks.


Version: 1.18.x
Severity: trivial
URL: http://en.wikipedia.org/w/api.php?action=query&titles=%s&prop=info&inprop=protection

Details

Reference
bz28751
bzimport raised the priority of this task from to Lowest.
bzimport set Reference to bz28751.
bzimport added a subscriber: Unknown Object (MLST).
Reedy added a comment.Apr 29 2011, 9:39 PM

I'm not sure why it'd be "better" to get them unique.

http://en.wikipedia.org/wiki/%s say's it's a bad request

Using the page id... A direct SQL query only gives me 2 results, being one after the other protections, both edit=sysop:move=sysop

3 edit and 3 move is weird

http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=&page=%25s&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_review_log=1

(show/hide) 22:45, 12 November 2006 Ral315 (Talk | contribs | block) protected "%s" ‎ (No real article can be written here, and it's used by Firefox users to search. No need to edit further. [edit=sysop:move=sysop])

It seems to be a weird edge case. I dunno, seems something we shouldn't really care about/bother filtering (ie WONTFIX)

Looking at the database it's got restrictions both in the page.page_restrictions field (old style) and in the page_restrictions table (new style). Where the third pair comes from I don't know.

Reedy added a comment.Apr 29 2011, 9:44 PM

Unless it's creating something for the rows with both, making the third row with double restrictions?

The problem is, that updateRestriction.php only copy the page_restriction and does not remove it from page table. That sounds like space waste.

When a wiki has never run updateRestriction.php the api shows no protection with prop=info&siprop=protection. That is because old restrictions are only check for pages with new protection, useless when updateRestriction.php was run.

But the problem for this bug is, that the table page_restrictions contains two rows for one page, one for edit and one for move, for each of that both old protection are added

type="edit" -> new style, from table page_restrictions
type="edit" -> old style, from page.page_restrictions
type="move" -> old style, from page.page_restrictions
type="move" -> new style, from table page_restrictions
type="edit" -> old style, from page.page_restrictions
type="move" -> old style, from page.page_restrictions

(In reply to comment #4)

The problem is, that updateRestriction.php only copy the page_restriction and
does not remove it from page table. That sounds like space waste.
When a wiki has never run updateRestriction.php the api shows no protection
with prop=info&siprop=protection. That is because old restrictions are only
check for pages with new protection, useless when updateRestriction.php was
run.
But the problem for this bug is, that the table page_restrictions contains two
rows for one page, one for edit and one for move, for each of that both old
protection are added
type="edit" -> new style, from table page_restrictions
type="edit" -> old style, from page.page_restrictions
type="move" -> old style, from page.page_restrictions
type="move" -> new style, from table page_restrictions
type="edit" -> old style, from page.page_restrictions
type="move" -> old style, from page.page_restrictions

That is better after I52111f30, because the values from page.page_restrictions not repeated a second time, but dupes still exist.

Anomie added a comment.Mar 5 2014, 5:03 PM
  • Bug 62247 has been marked as a duplicate of this bug. ***