Last modified: 2014-04-17 10:06:35 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 T29001, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27001 - MW Bugzilla integration extension
MW Bugzilla integration extension
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 46908
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-28 00:32 UTC by Mark A. Hershberger
Modified: 2014-04-17 10:06 UTC (History)
10 users (show)

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


Attachments

Description Mark A. Hershberger 2011-01-28 00:32:02 UTC
It would be great to have a place withing WP that we can point users to for filing bugs instead of just dumping them in bugzilla.

Since it might be relevant, attaching their recent click-trail (or similar) should be an option.

Also useful, a way to see the status of bugs and perhaps comment on them.
Comment 1 Sam Reed (reedy) 2011-01-28 00:33:35 UTC
There is http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports

Though, unreviewed etc..
Comment 2 Brion Vibber 2011-01-28 00:36:14 UTC
Mark, are you suggesting an alternative or simplified "new bug" form? Or an entirely parallel bug tracking system? (I would recommend against the latter, as this would splinter reporting & issue tracking further unless it's something really qualitatively different like the Firefox beta feedback system.)
Comment 3 p858snake 2011-01-28 01:03:55 UTC
(In reply to comment #2)
I think he means wrapping it in a custom wiki page to make it easier.
Comment 4 Mark A. Hershberger 2011-01-28 01:05:15 UTC
not a new bug tracking system, just a way to make sure users of Wikipedia have
an easy way to file bug reports using Bugzilla, but without having to deal with
the "shock" of learning Yet Another Web app.
Comment 5 Brion Vibber 2011-01-28 01:10:53 UTC
Integrating BZ into CentralAuth so people don't have to register another account, and making sure the new bug form isn't too horrid, would probably do the job pretty well.

Main impediment to CentralAuth integration is probably that BZ's model of email privacy in inverse to ours: users' email addresses are exposed to all other users...

Perhaps a one-click 'create your bugzilla account' though, that warns that your email address will be visible to other people on the bug tracker, might be a smaller hurdle to pass.
Comment 6 Brion Vibber 2011-01-28 01:12:34 UTC
[Or -- complete madness perhaps -- a mapping of wiki usernames to fake email 'addresses' and a plugin to BZ to send mails indirectly. MWAHAHAHAHHA]
Comment 7 Krinkle 2011-01-28 13:45:58 UTC
Switching Wkimedia's BugZilla to a "Vector" skin and the interwiki link to [[bugzilla:]] did a lot of good already to bridge the gap.

A CentralAuth integration would make it even better.

(In reply to comment #5)
> Main impediment to CentralAuth integration is probably that BZ's model of email
> privacy in inverse to ours: users' email addresses are exposed to all other
> users...

Is there a preference to hide the e-mailadres from public in BugZilla ?
If not perhaps a mini plug-in could be created for this which would be set as default for accounts via CentralAuth.
Comment 8 Chad H. 2011-01-28 14:03:57 UTC
(In reply to comment #7)
> Is there a preference to hide the e-mailadres from public in BugZilla ?
> If not perhaps a mini plug-in could be created for this which would be set as
> default for accounts via CentralAuth.
>

Not in BZ 3.x. Maybe in 4?

(In reply to comment #2)
> Mark, are you suggesting an alternative or simplified "new bug" form? Or an
> entirely parallel bug tracking system? (I would recommend against the latter,
> as this would splinter reporting & issue tracking further unless it's something
> really qualitatively different like the Firefox beta feedback system.)

How about a SpecialPage, called Special:FeatureIdea or Special:BugRequest. We could have them be posted to BZ's API.

I'd certainly like to have either UNCONFIRMED, or a keyword, or something to differentiate these outside bugs. Makes querying, duping, etc easier.
Comment 9 p858snake 2011-01-28 23:24:46 UTC
(In reply to comment #7)
> Is there a preference to hide the e-mailadres from public in BugZilla ?
> If not perhaps a mini plug-in could be created for this which would be set as
> default for accounts via CentralAuth.
That would make Bz unusable to anyone that wanted to do a simple search (eg: all bugs filed by X) or if they wanted to CC someone onto a bug. You need email addresses to be visible for Bz to be usable.
Comment 10 Mark A. Hershberger 2011-01-28 23:49:12 UTC
(In reply to comment #9)
> That would make Bz unusable to anyone that wanted to do a simple search (eg:
> all bugs filed by X)

Why does it follow that this would be the inevitable result of hiding email addresses?  If I only had "p858snake" I could search for all the bugs you filed: 

https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&emailreporter1=1&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&email1=p858snake&resolution=---&resolution=WONTFIX&resolution=LATER&emailtype1=substring
Comment 11 p858snake 2011-01-29 00:04:19 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > That would make Bz unusable to anyone that wanted to do a simple search (eg:
> > all bugs filed by X)
> 
> Why does it follow that this would be the inevitable result of hiding email
> addresses?  If I only had "p858snake" I could search for all the bugs you
> filed: 
That is assuming that the persons real name field (if they had it set) would match anywhere near their email.
Comment 12 Mark A. Hershberger 2011-01-29 00:51:12 UTC
In this particular case, yes, but AFAIK there is no reason to think that a similar search could not be added whenever CentralAuth was added.
Comment 13 Mark A. Hershberger 2011-03-10 04:40:06 UTC
*** Bug 27852 has been marked as a duplicate of this bug. ***
Comment 14 Mark A. Hershberger 2011-03-11 00:33:48 UTC
More discussion on the "vision thing" for this at Bug #27852

*** This bug has been marked as a duplicate of bug 27852 ***
Comment 15 Olivier Finlay Beaton 2011-11-30 14:37:33 UTC
Bug #27852 doesn't seem like the correct place to discuss centralauth for BZ but rather a much bigger integration. Wouldn't using a view (sorry I haven't actually looked at the db) allow you to map the users from centralauth in the short term pending some kind of huge proper integration?
Comment 16 Chad H. 2011-11-30 15:15:46 UTC
Un-duping. Tying Bugzilla into a central-auth type thing would be useful to lots of people (I don't say CentralAuth necessarily, we might look at something like OpenID for this).

Comment #15 is correct, bug 27852 is about a wider issue than just improving BZ auth.
Comment 17 Andre Klapper 2012-10-15 22:39:12 UTC
(In reply to comment #2)
> Mark, are you suggesting an alternative or simplified "new bug" form?

There IS a guided form, however it needs lots of love first (see bug 36762).

(In reply to comment #7)
> Is there a preference to hide the e-mailadres from public in BugZilla ?

No: https://bugzilla.mozilla.org/show_bug.cgi?id=218917
Comment 19 Andre Klapper 2013-03-18 10:19:57 UTC
As a few things have been mentioned here:
* Central Auth / SUL bug:
  https://bugzilla.wikimedia.org/show_bug.cgi?id=14487
* Public email address in Bugzilla:
  https://bugzilla.wikimedia.org/show_bug.cgi?id=148
Comment 20 Quim Gil 2013-03-25 03:38:39 UTC
This enhancement request is really messy, which is surprising considering that we have all the Bugzilla experts here.  ;)

We are talking about different things:

1. Publishing Bugzilla data in MediaWiki pages.

Indeed a useful feature for any project using Bugzilla and MediaWiki e.g. us.

At least Andre and me used http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports years ago in another project. That was with MW 1.15 or so. 

Mozilla developed https://github.com/LegNeato/mediawiki-bugzilla#mediawiki-extension-for-bugzilla and is using it in MW 1.19.4 although it says it has open bugs.

I think it's worth to complete and if one or two of you would volunteer as mentors I will push it to https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas to see if a qualified student is interested.


2. Reporting a bug to Bugzilla from a MediaWiki page.

The argument is that Bugzilla scares users. If that is true we should try first a nice Bugzilla guided UI for filing bugs ---> Bug 36762 

Andre says it takes work, but I guess less work than developing an extension that anyway should guide MediaWiki users to help them understand what are they doing. Otherwise be prepared to DUPE / Article Feedback / Twitter / Facebook style messages flooding Bugzilla.


3. Commenting on existing bug reports from a MediaWiki page.

For this you need 1 and 2 in the first place. 

However, once the user is at this point, I wonder how less scary is to see this page here with 20 comments or the equivalent exported to a Wiki page. And how less scary would be to find a textarea with a "Save changes" vs "Comment" button at the end. If this is a concern then we can simply work on a good custom CSS/skin for our Bugzilla, instead of creating a new MW extension. 


4. Unified login between MediaWiki and Bugzilla.

Discussion should go ---> Bug 14487

5. Hiding email addresses.

Discussion should go ---> Bug 148
Comment 21 Quim Gil 2013-03-27 22:11:38 UTC
I have contacted Brandon Savage from Mozilla to see what needs to be done to consider their MediaWiki - Bugzilla extesion ready for production.

https://twitter.com/quimgil/status/315526551762505728 + email with more details.

I also found this, which is probably the last update from the main developer at the time:
http://christian.legnitto.com/blog/2012/04/18/new-mediawiki-bugzilla-feature/
Comment 22 Quim Gil 2013-03-28 00:24:29 UTC
Can someone please install https://github.com/mozilla/mediawiki-bugzilla somewhere to test how that works with a plain, up-to-date MediaWiki and our Bugzilla?

I'm happy starting to test in order to find potential bugs and feature requests.

See also the wiki.moz component at bugzilla.mozilla.org:
http://tinyurl.com/d2wsy47 

Mozilla considers the linked code repository and bug reporting site 'upstream' for this project, which is good. They are committed to maintain it but they have many other things in their plate. They are happy to collaborate in a co-mentored GSOC/OPW project. They are defining what would be the appropriate project scope.

Anybody volunteering to co-mentor with a Bugzilla/Mozilla co-mentor, to cover the MediaWiki specific side? With two mentors for one project I wouldn't expect much work for each, and especially the MW side looks rather uncomplicated (?).

In a way or another we should keep pushing this forward!
Comment 23 Alex Monk 2013-03-29 01:50:55 UTC
(In reply to comment #22)
> Can someone please install https://github.com/mozilla/mediawiki-bugzilla
> somewhere to test how that works with a plain, up-to-date MediaWiki and our
> Bugzilla?

It can probably be put in labs somewhere?
Comment 24 Sam Reed (reedy) 2013-03-29 02:26:34 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > Can someone please install https://github.com/mozilla/mediawiki-bugzilla
> > somewhere to test how that works with a plain, up-to-date MediaWiki and our
> > Bugzilla?
> 
> It can probably be put in labs somewhere?

Isn't there already a bugzilla project in labs?

Having said that, it would seem as this is all MW/client side, anyone should be able to install it on their own wiki without too much of an issue.

https://wiki.mozilla.org/Special:Version - 1.19.4. I'm guessing that means we can drop anicent MW compatibility.

JS needs overhauling (manual inclusion of own resources etc)


Do we know if there is any sort of Semantic extension dependancy/usage?

I do note it hasn't been touched in 4 months.

Certainly a first pass to normalise their own style usage and fixing up a few icky things (?> among others) would be nice.

File storage of generated charts needs FileBackend/swift-ifying

(In reply to comment #22)
> See also the wiki.moz component at bugzilla.mozilla.org:
> http://tinyurl.com/d2wsy47 
> 

As well as https://github.com/mozilla/mediawiki-bugzilla/issues

And open pull requests at https://github.com/mozilla/mediawiki-bugzilla/pulls 2 of which are Hexmode



I'll probably set it up on my dev wiki tomorrow and see how well it plays ball
Comment 25 Andre Klapper 2013-03-29 12:20:15 UTC
(In reply to comment #24)
> > It can probably be put in labs somewhere?
> Isn't there already a bugzilla project in labs?

I am aware of the unfinished https://labsconsole.wikimedia.org/wiki/Nova_Resource:Bugtracker and http://kubo.wmflabs.org//bugzilla/
Comment 26 Quim Gil 2013-03-29 15:29:16 UTC
(In reply to comment #24)
> Having said that, it would seem as this is all MW/client side, anyone should
> be able to install it on their own wiki without too much of an issue.

As a super-amateru sysadmin I was deterred by these requirements that I don't understand and I was too busy / lazy to find out this week with all the GSOC stuff:


> Requires HTTP_Request2 from PEAR
> For charting, requires gd

https://github.com/mozilla/mediawiki-bugzilla
Comment 27 Sam Reed (reedy) 2013-03-29 16:46:54 UTC
(In reply to comment #26)
> (In reply to comment #24)
> > Having said that, it would seem as this is all MW/client side, anyone should
> > be able to install it on their own wiki without too much of an issue.
> 
> As a super-amateru sysadmin I was deterred by these requirements that I don't
> understand and I was too busy / lazy to find out this week with all the GSOC
> stuff:
> 
> 
> > Requires HTTP_Request2 from PEAR
> > For charting, requires gd
> 
> https://github.com/mozilla/mediawiki-bugzilla

For the first one:
pear install HTTP_Request2

And for the second (on Ubuntu at least)
apt-get install php5-gd
Comment 28 Sam Reed (reedy) 2013-03-29 16:52:05 UTC
And the HTTP_Request2 one can likely be replaced by the Http classes in MediaWiki itself..
Comment 29 Sam Reed (reedy) 2013-03-30 02:10:17 UTC
(In reply to comment #26)
> (In reply to comment #24)
> > Having said that, it would seem as this is all MW/client side, anyone should
> > be able to install it on their own wiki without too much of an issue.
> 
> As a super-amateru sysadmin I was deterred by these requirements that I don't
> understand and I was too busy / lazy to find out this week with all the GSOC
> stuff:
> 
> 
> > Requires HTTP_Request2 from PEAR
> > For charting, requires gd
> 
> https://github.com/mozilla/mediawiki-bugzilla



Yup, after installing those, with the default requires using:

<bugzilla>
    {
        "product": "Bugzilla",
        "priority":"P1"
    }
</bugzilla>

I get results working fine!

3 pull requests already https://github.com/mozilla/mediawiki-bugzilla/pull/19 and https://github.com/mozilla/mediawiki-bugzilla/pull/20 and https://github.com/mozilla/mediawiki-bugzilla/pull/21


For our usage:

require_once( "$IP/extensions/mediawiki-bugzilla/Bugzilla.php" );
$wgBugzillaRESTURL = "https://bugzilla.wikimedia.org/bzapi";
$wgBugzillaURL = "https://bugzilla.wikimedia.org";


then

<bugzilla>
    {
        "product": "MediaWiki",
        "status": "NEW"
    }
</bugzilla>

(well, I think it's working. It's taking a long time to save the page ;))

(note, its slow due to a lot of results!)
Comment 30 Sam Reed (reedy) 2013-03-30 02:35:44 UTC
require_once( "$IP/extensions/mediawiki-bugzilla/Bugzilla.php" );
$wgBugzillaRESTURL = "https://bugzilla.wikimedia.org/bzapi";
$wgBugzillaURL = "https://bugzilla.wikimedia.org";
$wgBugzillaMethod = 'xml-rpc';


Not actually sure where our rest api (needs confirming), but the xml-rpc one works fine
Comment 31 Quim Gil 2013-04-01 16:31:21 UTC
Thank you for testing and for the patches!

Question: is the extension supporting lists of bugs related to a specific  keyword? For instance, imagine that we want to show all the open reports marked as EASY.
Comment 32 Sam Reed (reedy) 2013-04-01 16:32:43 UTC
(In reply to comment #31)
> Thank you for testing and for the patches!
> 
> Question: is the extension supporting lists of bugs related to a specific 
> keyword? For instance, imagine that we want to show all the open reports
> marked
> as EASY.

Presumably something like the following should be enough:
<bugzilla>
    {
        "keyword": "easy"
    }
</bugzilla>
Comment 33 Quim Gil 2013-04-01 20:41:31 UTC
(In reply to comment #21)
> I have contacted Brandon Savage from Mozilla to see what needs to be done to
> consider their MediaWiki - Bugzilla extesion ready for production.

Mozilla is excited about co-mentoring with us this activity as a Google Summer of Code / Outreach Program for Women project. Brandon Savage (current maintainer) will be co-mentor. Anybody from our side willing to co-mentor to assist with MediaWiki knowledge? It shouldn't be much work.

Brandon also say that this week he will go through the open issues and pull requests in GitHub.
Comment 34 Sam Reed (reedy) 2013-04-01 21:57:15 UTC
(In reply to comment #33)
> (In reply to comment #21)
> > I have contacted Brandon Savage from Mozilla to see what needs to be done to
> > consider their MediaWiki - Bugzilla extesion ready for production.
> 
> Mozilla is excited about co-mentoring with us this activity as a Google
> Summer
> of Code / Outreach Program for Women project. Brandon Savage (current
> maintainer) will be co-mentor. Anybody from our side willing to co-mentor to
> assist with MediaWiki knowledge? It shouldn't be much work.
> 
> Brandon also say that this week he will go through the open issues and pull
> requests in GitHub.

Is there enough work to be potentially done to make it a decent GSoC/similar project?
Comment 35 Quim Gil 2013-04-02 01:33:33 UTC
Brandon from Mozilla said:

We have a short list of our open issues here: http://tinyurl.com/d2wsy47 Of course, this is by no means a complete or comprehensive list. Charting is nascent; we support limited charts for our users. There's also limited support for more complex queries of the Bugzilla API, and the JSON you're expected to compose for the API largely requires an already-working knowledge of the REST API for Bugzilla. Not to mention the fact that there's little to no documentation.

Here's my punch list of things I think would be great mentoring bugs and could keep a developer busy for a couple of months working on this project:

*Fully implement charting.
* Identify and implement a creative solution to the JSON-must-follow-Bugzilla's-API problem.
* Make mediawiki-bugzilla compatible with the latest versions of medawiki (right now I do not think that it is)
* Some kind of sane pagination (Bugzilla's API doesn't implement one so this is challenging)
* Making the plugin overall less fragile, and more robust. We could use some error handling for unavailability of the Bugzilla API, for example.
* Write unit tests or functional tests for this plugin (we have none)


Then Christian Legnitto, former main developer added:

As for the open issues, I believe there are patches in the tree that just need to be deployed for https://bugzilla.mozilla.org/show_bug.cgi?id=845471, as I added (and brandon fixed) support for that in https://bugzilla.mozilla.org/show_bug.cgi?id=743987. You can configure the defaults install-wide or do it by each query.

Why use the rest API format? No need to change some middleware mapping library whenever features are added to the bugzilla API, a lot comes "for free". I could see a decent UI being built on top to be a good project, though for Mozilla it isn't that useful as most people are technical or can dive into technical docs (or copy and paste + tweak something working).

One thing I wasn't happy about was moving pcharts into the repo...I think its license is GPL3 which I didn't want in there (was doing the default mozilla tri-license). But, I didn't see the need to protest much. Another decent project might be to just output in data labels and have client-side JS render the charts rather than creating images server-side.

And I added:

What about having a page documenting / advertising the extension under https://www.mediawiki.org/wiki/Extensions ?

We are meeting tomorrow at 9:30am Pacific over Skype. I also have sent an invitation to Sam just in case he can join and help with MediaWiki technical assessment. It would be very useful if you could make it! And to Andre, of course. If anybody else wants to join just send me an email.
Comment 36 Andre Klapper 2013-04-02 08:07:52 UTC
(In reply to comment #30 by Reedy)
> $wgBugzillaRESTURL = "https://bugzilla.wikimedia.org/bzapi";
> Not actually sure where our rest api (needs confirming), but the xml-rpc one
> works fine

There is no REST API by default. There is https://bugzilla.wikimedia.org/jsonrpc.cgi and https://bugzilla.wikimedia.org/xmlrpc.cgi
Comment 37 Sam Reed (reedy) 2013-04-02 15:32:43 UTC
(In reply to comment #36)
> (In reply to comment #30 by Reedy)
> > $wgBugzillaRESTURL = "https://bugzilla.wikimedia.org/bzapi";
> > Not actually sure where our rest api (needs confirming), but the xml-rpc one
> > works fine
> 
> There is no REST API by default. There is
> https://bugzilla.wikimedia.org/jsonrpc.cgi and
> https://bugzilla.wikimedia.org/xmlrpc.cgi

Isn't that great? gj on the documentation, Mozilla.

$wgBugzillaRESTURL     = 'https://api-dev.bugzilla.mozilla.org/latest'; // The URL for your Bugzilla API installation
$wgBugzillaURL         = 'https://bugzilla.mozilla.org'; // The URL for your Bugzilla installation 
$wgBugzillaTagName     = 'bugzilla'; // The tag name for your Bugzilla installation (default: 'bugzilla')
$wgBugzillaMethod      = 'REST'; // XML-RPC and JSON-RPC may be supported later


Considering they've got xml-rpc in the code already, and a instantiation of a json-rpc class that doesn't exist... Ugh.
Comment 38 Quim Gil 2013-04-02 23:17:18 UTC
Brandon Savage (Mozilla), Andre Klapper and me had a chat today and defined the scope for this project in a broad sense. Brandon and Reedy have volunteered co-mentoring this project, which has been now featured for Google Summer of Code and Outreach Program for Women:

http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Productize_the_Bugzilla-MediaWiki_extension

If a student / intern is interested we will develop the project upstream at https://github.com/mozilla/mediawiki-bugzilla

In the meantime, I wonder... couldn't we install this extension already in mediawiki.org or Wikitech? If it's good enough for Mozilla's Wiki it may be good enough for us, to get us started and have a better idea of bugs / missing features.
Comment 39 MZMcBride 2013-04-03 02:32:42 UTC
(In reply to comment #38)
> In the meantime, I wonder... couldn't we install this extension already in
> mediawiki.org or Wikitech? If it's good enough for Mozilla's Wiki it may be
> good enough for us, to get us started and have a better idea of bugs /
> missing features.

It'll need a full security review. I'm not sure if such a review would be the subject of this bug or a separate "Review and deploy extension blah to blargh" bug.
Comment 40 Quim Gil 2013-04-04 21:56:37 UTC
Bug 46908 - Please enable MediaWiki-Bugzilla extension in Wikitech
Comment 41 Quim Gil 2014-04-08 15:41:36 UTC
There is an ongoing revision of our project management tools, which includes Bugzilla.

https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review

Setting Lowest priority for now. This will change in a direction or another when we have a decision.
Comment 42 Andre Klapper 2014-04-17 10:06:35 UTC
(Also see [[mw:Extension:IssueTracker]] which is not about integration but about doing issue tracking itself in MediaWiki...)

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


Navigation
Links