From MozillaWiki
Jump to: navigation, search

This is a project to add a user profile page into Bugzilla. It would show a few stats summing up particular actions or contributions by the user, and would be visible to all logged in users.

In this version of the profile, the user does not have to upload or fill in any fields, as the entire profile is generated from data within Bugzilla (except for the Mozillians username field).

Bug filed at: bug 859550 [ateamtrack: p=bugzilla q=2 m=1]

How a simple user profile might look

  • Name: lizzard
  • Email:
  • profile: [link ]

  • Last activity: 2013-03-26
  • Bugs filed: 13
  • Comments made: 46
  • Assigned to: 1
  • Commented on: 53
  • Confirmed: 10
  • QA-contact: 0
  • Patches submitted: 0
  • Patches reviewed: 0
  • Bugs poked: 155


Statuses changed: RESOLVED (20), INVALID (3), FIXED (5), VERIFIED (5)

By Product: Core(2), Firefox(5), FirefoxOS(0), Firefox for Android(1), Firefox for Metro(0), Toolkit(1), Marketplace(1), Thunderbird(1), SeaMonkey(1), Mozilla Localizations(3), Mozilla Services(1), Other Products(10)

What do these fields mean?

Explanation of these stats

  • Each stat has a number associated with it, a description, and a more info link.
  • Stats that don't have any activity should still show on the page with a zero for the #.
  • The number should link to a bugzilla query.
  • The field names should each have a tooltip short description. Each field name could also either be links themselves, or could have a "more info" long description which might be either an explanation or a link to an external page. (In this case probably a WMO page.)
  • The Mozillians link is simply a link to the user-provided Mozillians profile page. There will be no API level integration with at this stage.


  • Should we include private bugs, comments, and attachments?
    • Having different counts depending on what the viewing user can see is not viable
    • Will assume public-only data unless told otherwise
  • Should patches submitted be all the ones submitted? obsolete ones too?
  • Should we give a different stat for patches reviewed + accepted?
  • Bugs assigned would be all of them ever for this user, not just open ones. Would only the current assignee "count"? If the assignee changes, do they both increment?)


(bug 862441 and bug 859550)

The user profiles will have a link "What do these fields mean?" that leads to User profile fields rather than the original idea of descriptions in tooltips for each field.

Clicking on the field names in the profile would take the user to that term (anchor text) on a page with descriptions of all the user profile field names.

user profile field descriptions

Last activity

The date and time a user last reported, changed or commented on a bug in bugzilla. Link to user activity report for the last 30 days.

Bugs filed

The total number of bugs reported by the user. More info: <a href="">How to File a Bug</a>

Commented on

The total number of bugs that the user has commented on. More info: <a href="">Bugzilla etiquette</a>

Comments made

The total number of comments that the user has added. More info: <a href="">Bugzilla etiquette</a>


The number of bugs the user has changed from UNCONFIRMED to NEW. More info: <a href="">Confirming unconfirmed bugs</a>


QA-contacts work as part of the QA team to help developers with regression testing, steps to reproduce bugs, and bug verification. More info: <a href="">How can I help test?</a>

Patches submitted

The number of patches a user has submitted to help fix a bug. More info: <a href="">Contributing to the Mozilla Codebase</a>, <a href="">How to Submit a Patch</a>, and <a href="">Bugzilla:Review</a>.

Patches reviewed

Shows how many patches a user has reviewed. More info: <a href="">Code Review FAQ</a> including how to become a reviewer.

Assigned to Bugs assigned to a user.

Bugs poked Total number of bugs a user has interacted with: filed, commented on, changed status, added whiteboard or keyword tags, changed product or component; anything done to the bug that results in saving changes.

RESOLVED Bugs a user has changed from NEW, UNCONFIRMED, or REOPENED to RESOLVED. More info: <a href="">Resolving bugs</a>.

DUPLICATE Bugs a user has resolved as a duplicate of an existing bug More info: <a href=" ">Screening DUPLICATE bugs</a>.

INVALID Bugs a user has resolved as INVALID; these may be issues that aren't Mozilla bugs, or are features rather than unexpected behavior. More info: <a href="">Resolving bugs as INVALID</a>.

WORKSFORME Bugs a user was unable to reproduce on the reported hardware and OS. More info: <a href="">Resolving bugs</a>.

FIXED Bugs a user has resolved as FIXED. Only verify FIXED if the bug's resolution can be tied to a specific code checkin in a Mozilla repository. More info: <a href="">Resolving bugs as FIXED</a>.

VERIFIED Resolved bugs that a user has made sure have been resolved correctly. More info: <a href="">Verifying bugs</a>.

For the products listed on the user page, use the same strings as are in .

  • Core
  • Firefox
  • FirefoxOS
  • Firefox for Android
  • Firefox for Metro
  • Toolkit
  • Marketplace
  • Thunderbird
  • SeaMonkey
  • Mozilla Localizations
  • Mozilla Services
  • Other Products

Implementation Notes

Add a field to the profiles table which is used to track if a user's statistics need to be updated (triggered when the user file/updates/comments on a bug). Schedule a cron job to run at an off-peak time which updates the statistics for users. Expose those statistics via a package which monkey patches a getter into the User package.

Administrative actions, such as editing a user, group, product, etc, should also trigger the statistics to be updated.

note This "dirty-only" approach may not be viable, as changing a bug's visibility will changes bug counts for everyone who has interacted with the patch (assuming only public bug data is displayed).



  • id identity
  • user_id fk profile.userid
  • name varchar30
  • count int


  • id identity
  • user_id fk profile.userid
  • status varchar64
  • count int


  • id identity
  • user_id fk profile.userid
  • product_id fk (when 0, refers to 'other' products)
  • count int

new fields:

  • profiles.mozillians_id varchar30 ( username)
  • profiles.last_activity_ts datetime timestamp of most recent update, comment, etc
  • profiles.last_statistics_ts datetime timestamp of last time the statistics were generated for this user

Data Points

  • last_activity : from profiles.last_activity_ts
  • bugs_filed : simple count from bugs table (public bugs only)
  • comments : simple count from longdescs table (public comments only on public bugs)
  • commented_on : simple count from longdescs table (public comments only on public bugs)
  • confirmed : bugs_activity where field=status and removed='UNCONFIRMED' (public bugs only)
  • qa_contact : simple count from bugs table (public bugs only)
  • patches : simple count from attachments table (public bugs and attachments only)
  • reviews : review+ flags count (public bugs and attachments only)
  • assigned : simple count from bugs table (public bugs only)
  • touched : simple count from bugs_activity + longdescs table (public bugs, comments and attachments only)
  • by-status activity counters : simple count from bugs_activity table (public bugs only)
  • by-product activity counters : simple count from bugs_activity + longdescs table (public bugs, comments and attachments only)