Last modified: 2013-04-08 11:01:54 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 T30634, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28634 - document possible API caveat caused by accounts without the registration time field
document possible API caveat caused by accounts without the registration time...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Brion Vibber
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-21 07:42 UTC by Amir E. Aharoni
Modified: 2013-04-08 11:01 UTC (History)
12 users (show)

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


Attachments

Description Amir E. Aharoni 2011-04-21 07:42:36 UTC
In IRC i reported a problem with a link in the Editor Survey not working. Kaldari found that it was caused by the fact that for some reason my account, as well as a quite a lot of others, didn't have registration time associated with them. Indeed, i cannot see the "Registration time" field in the preferences of my regular account, but i can see it in the preferences of another account. I never noticed it.

I couldn't find it reported anywhere, so i am reporting it here, because apparently it does cause some problems.
Comment 1 Raimond Spekking 2011-04-21 07:48:47 UTC
Really old accounts do not have this information. The registration timestamp was introduced somewhere in 2004.

I.e. my account [[de:User:Raymond]] is from 2003.
Comment 2 Roan Kattouw 2011-04-21 08:02:16 UTC
This is the editor survey's fault then. It's been known for a long time that the registration field is not set for every user (there are a few other fields in other tables that behave this way, such as revision length), so things like the editor survey have to account for the possibility that it may not be available.

It's also possible that this is a bug in an API module used by the editor survey, but I'm not at all familiar with it so I can't tell.
Comment 3 p858snake 2011-04-21 08:04:38 UTC
WONTFIX these accounts are from before it was stored in the db and there is no
decent way to automatically fill these in.

This is most likley a dup but I can't be bothered looking atm.
Comment 4 Niklas Laxström 2011-04-21 11:00:33 UTC
Should be INVALID then, not WONTFIX. Is there bug open for survey module or can we re-categorize this one?
Comment 5 Amir E. Aharoni 2011-04-21 11:03:11 UTC
For the survey it's supposed to be already fixed. If the devs don't want to fix the accounts themselves, it may be fine, but this issue should be documented so that API users won't fall for this in the future.
Comment 6 Niklas Laxström 2011-04-21 11:04:57 UTC
Devs can't "fix" this, the information just isn't there. System administrators could throw some arbitrary values in the fields.
Comment 7 Amir E. Aharoni 2011-04-21 11:06:44 UTC
(In reply to comment #6)
> Devs can't "fix" this, the information just isn't there. System administrators
> could throw some arbitrary values in the fields.

Time of first edit minus 5 minutes should be good enough :)
Comment 8 p858snake 2011-04-21 11:08:22 UTC
(In reply to comment #4)
> Should be INVALID then, not WONTFIX. Is there bug open for survey module or can
> we re-categorize this one?
There was discussions with filling it with other data, such as their first edit but I believe it was decided not to because that wouldn't be "real" information.
Comment 9 Danny B. 2011-04-21 11:36:19 UTC
This bug can be *partially* fixed.

(data taken from cswiki db, so it won't be accurate to second wikimedia-wide, but at least the date should be enough descriptive)

select min( user_registration ) from user
 = 20051222111612

select min( log_timestamp ) from logging where log_type = "newusers"
 = 20050907222547

So at least that 3,5 months gap could be fixed by some maintenance script.
Comment 10 Ryan Kaldari 2011-04-21 19:33:30 UTC
The bug was in the API called by CentralNotice. It returned a string for most users and the integer 0 for users like Amir, which caused a Javascript error. I fixed this by casting the result in the banner code and Nimish has fixed it in the API so that it returns a string in both cases.

Not sure if there is a good solution to the broader problem though.
Comment 11 Mark A. Hershberger 2011-04-21 20:47:22 UTC
Retitled bug and changed component to match the actual problem that
needed resolving.  If Nimish has the revision number for the fix, it'd
be nice if he could add it.
Comment 12 Amir E. Aharoni 2011-04-21 21:36:44 UTC
This bug is not about the survey issue, which is already fixed. It's about preventing such issues in the future.
Comment 13 Mark A. Hershberger 2011-04-21 22:57:22 UTC
(In reply to comment #12)
> This bug is not about the survey issue, which is already fixed. It's about
> preventing such issues in the future.

Which issue do you think has not been properly addressed and is likely to reoccur?  Do you have an idea of what a solution to this would look like?
Comment 14 Amir E. Aharoni 2011-04-22 09:10:03 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > This bug is not about the survey issue, which is already fixed. It's about
> > preventing such issues in the future.
> 
> Which issue do you think has not been properly addressed and is likely to
> reoccur?  Do you have an idea of what a solution to this would look like?

This caveat should be documented somewhere, that would probably be enough.
Comment 15 Brion Vibber 2011-05-13 15:05:27 UTC
Done on trunk in r87981:

- ' registration  - Adds the timestamp of when the user registered',
+ ' registration  - Adds the timestamp of when the user registered if available (may be blank)',

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


Navigation
Links