Last modified: 2007-06-29 15:21:42 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 10395 - prop=info&inprop=protection doesn't detect pre-1.10 protections
prop=info&inprop=protection doesn't detect pre-1.10 protections
Status: RESOLVED DUPLICATE of bug 9386
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Roan Kattouw
: patch, patch-need-review
Depends on:
  Show dependency treegraph
Reported: 2007-06-28 14:25 UTC by Stefan Bauer
Modified: 2007-06-29 15:21 UTC (History)
2 users (show)

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

Lists pre-1.10 protections in inprop=protections (1.46 KB, patch)
2007-06-28 17:28 UTC, Roan Kattouw

Description Stefan Bauer 2007-06-28 14:25:24 UTC
For some pages a wrong protection status is delivered by prop=info&inprop=protection.

Example: is semi protected since 2006-10-02 (see ) but prop=info&inprop=protection&titles=Schule returns an empty protection value.

same behaviour for - protected since 2006-09-02

Is there a problem with old protections?
Comment 1 Roan Kattouw 2007-06-28 14:56:04 UTC
The API implementation uses the protections table which was introduced in MediaWiki 1.9. I'll find out how pre-1.9 versions did their protections and check for them too. Can you confirm that this bug only occurs with pages that were protected prior to upgrading to 1.9? If you're not sure, ask an admin to unprotect and reprotect [[de:Schule]], and see if the API returns the correct value after that.
Comment 2 Roan Kattouw 2007-06-28 16:04:10 UTC
Rectification: it's actually called the page restrictions table, and it was added in 1.10. 1.9 has it in the page_restrictions field in the page table, and I'm writing a patch right now that checks both.
Comment 3 Roan Kattouw 2007-06-28 17:28:15 UTC
Created attachment 3838 [details]
Lists pre-1.10 protections in inprop=protections

The attached patch fixes this.
Comment 4 Stefan Bauer 2007-06-28 18:27:41 UTC
Only old protections seem to be affected - after unprotecting and reprotecting [[de:Schule]] the API result is correct.
Comment 5 Rob Church 2007-06-29 05:00:54 UTC
The ideal fix would be to run a script which migrates the restrictions in batches. We appear to have one, in the form of maintenance/updateRestrictions.php.
Comment 6 Rob Church 2007-06-29 06:12:07 UTC

*** This bug has been marked as a duplicate of bug 9386 ***
Comment 7 Roan Kattouw 2007-06-29 15:11:53 UTC
(In reply to comment #6)
> *** This bug has been marked as a duplicate of bug 9386 ***
This is not a dupe: bug 9386 is about Special:Protectedpages, this is about the API. Special:Protectedpages could be patched a la the patch I've submitted.
Comment 8 Rob Church 2007-06-29 15:21:42 UTC
No, bug 9386 is about dealing with the problem that's also causing this bug, and the original report there. The "correct" solution for this bug is to migrate the old data, not to keep poking backwards-compatible checking into the code where it's not needed.

*** This bug has been marked as a duplicate of bug 9386 ***

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