Last modified: 2011-03-13 18:06:18 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 T29881, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27881 - the 'emailable' property (from API) should be true or false (currently empty string or undefined)
the 'emailable' property (from API) should be true or false (currently empty ...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Lowest minor (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-05 22:51 UTC by Ryan Kaldari
Modified: 2011-03-13 18:06 UTC (History)
6 users (show)

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


Attachments

Description Ryan Kaldari 2011-03-05 22:51:59 UTC
When using the API to find out if someone is emailable, the emailable property is set to empty string for true or undefined for false. Instead, it should be set to 'true' or 'false'.

True example:
http://en.wikipedia.org/w/api.php?&action=query&list=users&ususers=Kaldari&usprop=emailable&format=json

False example:
http://en.wikipedia.org/w/api.php?&action=query&list=users&ususers=Jorm&usprop=emailable&format=json
Comment 2 Sam Reed (reedy) 2011-03-05 22:54:08 UTC
This is a slightly strange one. We tend to use (in xml) blah="" for defined, and nothing for undefined..
Comment 3 Ryan Kaldari 2011-03-05 22:58:41 UTC
For gender, for example, we return 'male', 'female', or 'unknown'. Wouldn't it make more sense for emailable to be 'true' or 'false'? It would certainly make things more intuitive for API users, in my opinion.
Comment 4 Ryan Kaldari 2011-03-05 23:32:37 UTC
It looks like we do the same thing for the 'readable' property of pages. I don't think that using empty strings to indicate truth is a good idea (especially since empty strings are interpreted as false in both PHP and Javascript). I understand why it was built this way, since all the properties are universally set up as XML attributes (when in some cases they might make more sense as attribute values or full nodes). Unfortunately, this leaves our users with rather unintuitive data that requires more verbose code.

If the resolution is WONTFIX, the return behavior of the property should at least be documented so that people know they have to test for whether or not the attribute is defined rather than testing for truth.
Comment 5 Sam Reed (reedy) 2011-03-05 23:55:56 UTC
I've asked Roan to chime in...
Comment 6 Bryan Tong Minh 2011-03-06 09:49:40 UTC
This behavior is present on all boolean values.

Changing this would be a breaking change, for esthetic purposes only, so I recommend WONTFIX.
Comment 7 Sam Reed (reedy) 2011-03-06 20:17:50 UTC
Indeed.

It's how HTML elements do stuff - disable="" means true, else it's false.

I think it's just a cause for documentation change, and WONTFIX...

Ryan, what sort of documentation are you suggesting? For all boolean types (probably makes sense).. Though, for properties, we don't store this level of granduality..

"Tags if the user can and wants to receive e-mail through [[Special:Emailuser]]"

Might be a manual process.

Per Bryan, changing emailable="true" or whatever would be a breaking change from the api... And the only time we try to make them is when security is involved...
Comment 8 Sam Reed (reedy) 2011-03-06 20:41:13 UTC
Indeed.

It's how HTML elements do stuff - disable="" means true, else it's false.

I think it's just a cause for documentation change, and WONTFIX...

Ryan, what sort of documentation are you suggesting? For all boolean types (probably makes sense).. Though, for properties, we don't store this level of granduality..

"Tags if the user can and wants to receive e-mail through [[Special:Emailuser]]"

Might be a manual process.

Per Bryan, changing emailable="true" or whatever would be a breaking change from the api... And the only time we try to make them is when security is involved...
Comment 9 Roan Kattouw 2011-03-06 20:45:20 UTC
As Reedy and Bryan have said, this is just the way boolean attributes work in the API. This is a convention that I don't particularly like either, but it was introduced before my time and we've stuck with it ever since. Old properties aren't gonna be moved to a true/false format because that would be a breaking change (and we never make those for aesthetic reasons only, like Bryan said), and introducing new properties with a true/false format while keeping old properties with the present/absent format around would lead a weird, inconsistent state where no one remembers which property uses which format any more. So we're kinda stuck in the status quo.
Comment 10 Ryan Kaldari 2011-03-07 02:21:42 UTC
That's fine. I've added a new section to the API:E-mail documentation on checking the emailable property:
http://www.mediawiki.org/wiki/API:E-mail#Checking_emailable_status

It includes some sample code, so hopefully that will help people figure it out without too much trouble.

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


Navigation
Links