Created attachment 3767
Makes prop=info list protections

I attached a patch that implements this. The following example illustrates how the protections are returned:

(Main Page is not protected, User:Catrope is protected "edit=sysop; move=sysop" expiring 12:57, 15 June 2007 and User:Catrope2 is protected the same with expiry infinite.)

api.php?action=query&prop=info&titles=User:Catrope|User:Catrope2|Main%20Page

<?xml version="1.0" encoding="utf-8"?>
<api>

<query>
  <pages>
    <page pageid="1" ns="0" title="Main Page" touched="2007-06-13T17:49:38Z" lastrevid="1" counter="5" length="444">
      <protection />
    </page>
    <page pageid="2" ns="2" title="User:Catrope2" touched="2007-06-14T16:55:38Z" lastrevid="9" counter="13" length="135">
      <protection>
        <pr type="edit" level="sysop" expiry="infinity" />
        <pr type="move" level="sysop" expiry="infinity" />
      </protection>
    </page>
    <page pageid="3" ns="2" title="User:Catrope" touched="2007-06-14T19:29:38Z" lastrevid="10" counter="3" length="27" redirect="" new="">
      <protection>
        <pr type="edit" level="sysop" expiry="20070615125700" />
        <pr type="move" level="sysop" expiry="20070615125700" />
      </protection>
    </page>
  </pages>
</query>

</api>

Note that the expiry date can be a date in the past, in which case the protection is no longer valid. It's up to you to check this. Expiry dates are formatted yyyymmddhhmmss.

The format is not exactly what you asked for, but this makes more sense given the way protections are stored in the database.

Hope this helps,

Roan Kattouw

attachment prop-info-protection.patch ignored as obsolete

Created attachment 3790
Cleaner version of first patch

I've attached a patch that implements this slightly cleaner than the previous one.

attachment prop-info-protection-2.patch ignored as obsolete

This looks good, but it should not be done all the time (expensive on DB). Roan, could you add an optional parameter "prop" (prefix "in"), null by default, with the only valid value of "protection". Thanks!

btw, this line should be changed to add the prefix 'in':
parent :: __construct($query, $moduleName);

(In reply to comment #3)

This looks good, but it should not be done all the time (expensive on DB).
Roan, could you add an optional parameter "prop" (prefix "in"), null by
default, with the only valid value of "protection". Thanks!

btw, this line should be changed to add the prefix 'in':
parent :: __construct($query, $moduleName);

Will do, expect third version of patch early next week (Monday or Tuesday).

Created attachment 3796
Implements listing page protection status through prop=info&inprop=protections

Done earlier that I thought. The attached patch was made using the svn diff command, and should be applied with patch -p0 in the phase3 directory.

Attached:

Applied in r23052 -- The patch had to be significantly altered for various reasons. Please review.

Doesn't look major to me. Just the coding style (opening braces) and the $fld_protection var. Looks like it should still work the same way.

By major i meant execution optimization: the patch was doing a complex query and then ignored the result when the property was not specified. Its all about performance, otherwise I will have domas chasing me with a wet towel.

(In reply to comment #8)

By major i meant execution optimization: the patch was doing a complex query
and then ignored the result when the property was not specified. Its all about
performance, otherwise I will have domas chasing me with a wet towel.

Hell, you're right, can't believe I could be so stupid. A good thing _you_ are paying attention, then.