prop=info&inprop=protection sometimes shows protection multiple times
Closed, DeclinedPublic
Actions

Assigned To

None

Authored By

	duplicatebug
	Apr 29 2011, 9:23 PM

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

	Subject	Repo	Branch	Lines +/-
	[DNM] Remove usages of legacy page.page_restrictions field	mediawiki/core	master	+30 -137

Customize query in gerrit

Related Objects
Search...

Status	Assigned	Task
Declined	None	T30751 prop=info&inprop=protection sometimes shows protection multiple times
Resolved	Ladsgroup	T35334 Remove database column page.page_restrictions from MediaWiki core
Resolved	Ladsgroup	T218446 Remove use of legacy page.page_restrictions field
Resolved	Reedy	T166184 Run updateRestrictions.php on WMF wikis
Resolved	Marostegui	T248333 Schema change: Make page.page_restrictions column NULL

Event Timeline

• bzimport raised the priority of this task from to Lowest.Nov 21 2014, 11:29 PM

• bzimport added a project: MediaWiki-Action-API.

• bzimport set Reference to bz28751.

• bzimport added a subscriber: Unknown Object (MLST).

duplicatebug created this task.Apr 29 2011, 9:23 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.

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.

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

duplicatebug unsubscribed.Dec 13 2014, 4:32 PM

Anomie added a subtask: T35334: Remove database column page.page_restrictions from MediaWiki core.Feb 20 2015, 6:41 PM

Anomie moved this task from Unsorted to Non-Code on the MediaWiki-Action-API board.

Krinkle changed the status of subtask T35334: Remove database column page.page_restrictions from MediaWiki core from Open to Stalled.Jul 18 2019, 9:40 PM

Krinkle mentioned this in T218446: Remove use of legacy page.page_restrictions field.Jul 18 2019, 9:46 PM

Change 541601 had a related patch set uploaded (by TK-999; owner: TK-999):
[mediawiki/core@master] [DNM] Remove usages of legacy page.page_restrictions field

https://gerrit.wikimedia.org/r/541601

Restricted Application added a project: Platform Engineering. · View Herald TranscriptOct 8 2019, 7:01 PM

gerritbot added a project: Patch-For-Review.Oct 8 2019, 7:01 PM

Anomie edited projects, added Platform Team Workboards (Clinic Duty Team); removed Platform Engineering.Oct 8 2019, 9:06 PM

Anomie moved this task from Inbox to External Code Review In Progress on the Platform Team Workboards (Clinic Duty Team) board.

RobinHood70 unsubscribed.Oct 9 2019, 11:09 PM

Umherirrender merged a task: T241670: Api returns duplicate protection info.Jan 1 2020, 5:33 PM

Umherirrender added subscribers: DannyS712, Aklapper.

Krenair subscribed.Jan 1 2020, 6:32 PM

• WDoranWMF moved this task from External Code Review In Progress to External Code Review Completed on the Platform Team Workboards (Clinic Duty Team) board.Mar 3 2020, 8:31 PM