Last modified: 2014-03-31 18:39:39 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 T36187, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34187 - Missing data of protected pages
Missing data of protected pages
Status: NEW
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.18.x
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 34497
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-03 13:13 UTC by wikiposta
Modified: 2014-03-31 18:39 UTC (History)
6 users (show)

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


Attachments

Description wikiposta 2012-02-03 13:13:32 UTC
When querying blocks, I can use bkprop=timestamp|expiry|by.
For querying pages protected against creation there is ptprop=timestamp|expiry|user.
(Althogh "user" has a different meaning here as for blocks.)

What about other protections? A similar approp=blahblah is unfortunately missing fram allpages, or at least it is heavily undocumented on http://www.mediawiki.org/wiki/API:Allpages.

I was suggested to get expiration from query as 
action=query&titles=title|title1&prop=info&inprop=protection

and mine the protection log for timestamp of beginning (and for the admin who protected, I suppose).
I can do that if necessary, but is complicated for me, slow for the bot and results in a greater server load.
Would be nice to handle blocks, protections and create-protections in similar way.
Comment 1 db [inactive,noenotif] 2012-02-18 18:15:30 UTC
That is not possible at the moment, because the "page restrictions" table does not store that information.

The "ipblocks" table and the "protected titles" table store information about the performer of that action and than you can query this information.
Comment 2 wikiposta 2012-02-18 18:20:28 UTC
OK, then the category should be changed: this is no more an API bug, rather a database bug. :-) It should store for practical reasons written above.
Comment 3 db [inactive,noenotif] 2012-02-18 18:37:15 UTC
I have create a new bug to track that, because without an own bug for category API the api part maybe is not implemented, after the database is changed.
Comment 4 wikiposta 2012-02-18 18:38:30 UTC
Oh, I didn't think of that. Thank you!
Comment 5 db [inactive,noenotif] 2014-03-31 18:39:39 UTC
Needs to use the log_search, see Gerrit change #105443

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


Navigation
Links