Closed Bug 602485 Opened 14 years ago Closed 14 years ago

install bugzilla reports mediawiki extension on wiki.mozilla.org

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: beltzner, Assigned: fox2mike)

References

Details

I cannot express to you how badly we need this.

http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports

Product drivers, team leaders, and individual contributors have been clamoring for some better way to integrate live bug status into wiki pages. Need, want, need, please, high priority, other words, oh my.
Assignee: server-ops → shyam
Dave, Chris : The extension in question needs access to bugzilla's DB. Not sure if we'd want to review the extension code first before going ahead with this.

Also, I'm not sure what level of access we'd have to give it (read only will probably be fine) but by level of access I mean this user can possible read the whole bug database...which means access restricted bugs etc? What's the potential for abuse etc?

Mike, might take us a while to get this online :) I was as enthusiastic as you when I saw the bug (which is why I grabbed it thinking it was a 10 min job) but we'd have to look at this before we go ahead. Thanks for your patience!
(In reply to comment #1)
> Also, I'm not sure what level of access we'd have to give it (read only will
> probably be fine) but by level of access I mean this user can possible read the
> whole bug database...which means access restricted bugs etc? What's the
> potential for abuse etc?

I'd give it the same access that any new user has; no restricted or corporate level bugs.
(In reply to comment #2)
 
> I'd give it the same access that any new user has; no restricted or corporate
> level bugs.

That's easy to do via Bugzilla's ACL, I'm not sure how easy it is directly on the Database level, hence the question to Dave. I'm clueless over there. As far as I can see, r/o access to bugzilla's DB directly = access to everything there..including bugs that shouldn't be otherwise accessed.

Like select * from bugs_fulltext where bug_id=602445; throws me the output at the DB level and will do the same for you (at the DB level) but wouldn't respond over Bugzilla since you're not in the infra group. People *may* be able to abuse the plugin to read bugs they're not supposed to, which is why I'm pulling in Chris and Dave.
Yeah, I found that MediaWiki extension about a year ago for faaborg's request in bug 523521, but the same concerns were rightly brought up then, so the request stalled. There's just too much confidential data in Bugzilla's DB to just trust some random extension that doesn't understand that some bugs are confidential. Plus, in order for this to work, the generic webapp cluster that hosts wikimo would have to be given access to Bugzilla's DB, and that's just immensely dangerous, as it could easily lead to a bad compromise of data.
An acceptable workaround would be to fetch (out of bugzilla's DB) the public bugs and their content and shove them into a "shadow DB" which can be hosted on one of the other DB clusters and then have this plugin read that DB (vs direct access to Bugzilla's DB). There might be a time delay b/w the two. Also, I'm not sure how intensive or time consuming such a process would be or if it's feasible. Over to Dave again for that :D
Summary: install bugzilla reports medawiki extension on wiki.mozilla.org → install bugzilla reports mediawiki extension on wiki.mozilla.org
Is there any way that we can modify the extension to be more our-bugzilla-aware? I'm willing to pay cash money, here.
Sure, if it can hook into bugzilla vs bugzilla's DB, all this will go away. Might be a fair bit of work though, since bugzilla's interface isn't SQL.

I've cc'ed morgamic to see if this is something webdev can look into.

I think my plan in comment #5 is far more quicker to implement and safer, without having to modify plugin code.
Is it possible to do the queries based on BzAPI instead of direct database queries? That would preserve security...
Yes, this should be recast on top of the API for a number of reasons.
OK, so the plan here is to base a MW extension off of this existing one, but recasting the direct SQL as BzAPI queries. Groovy.

I think Bob Moss' team is on-lining some capacity here, but as I mentioned, I'm also happy to apply budget to contractors if there are individuals known as experts in MediaWiki scripting.
Yeah, should probably take prioritization of features to another venue.
Any idea where this bug should move since it's being handed off to bmoss's team? I don't know of any general tools component (though, I'm happy to create one if that's needed)...
WONTFIX for this one, should figure out the plan for developing a version based on BzAPI (and probably Pulse) in a thread or wiki page, then file to get it deployed once it's ready.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Resolution: FIXED → WONTFIX
(In reply to comment #13)
> WONTFIX for this one, should figure out the plan for developing a version based
> on BzAPI (and probably Pulse) in a thread or wiki page, then file to get it
> deployed once it's ready.

OK, moving discussion to here for now: https://wiki.mozilla.org/Auto-tools/Projects/WikiZilla

I'll put together a quick specification there.
Bah, sorry that took so long. I put a description of the goals and non-goals there. Decided not to do a full design spec at this time, would be happy to talk that through with someone, though.
I had some time to look at this tonight and hacked an ugly bugzilla REST api backend into the buzilla reports extension.

I think we should write our own for the following reasons:

1. It makes wiki page load horribly slow for most queries. The page is blank with no feedback (other than the throbber) while it is waiting on the API to return. With 3 queries on the page (one just pulling out a specific bug) it takes about 30 seconds on my local install

2. The extension, while useful, is written in less-than-awesome PHP with tons of weird abstractions

3. All output in the extension is currently echoed out via PHP...there's no templating at all (though there are interesting css classes applied)

4. The terms the extension sometimes uses are interesting/don't really match bugzilla. For example, "from" is actually bugzilla's "created_by", but the extension also references "raisedBy", etc

5. All times are dealt with how they are used in the DB, so the rest api backend would have to translate all that logic or values to what the extension expects

6. There's a fair amount of DB-sepecific logic, so we'd never really be sure that the API support we grafted on worked right in every case

I can add this to the wiki page as well.
(In reply to comment #16)
> I think we should write our own for the following reasons:
[...]
> I can add this to the wiki page as well.

Please do!
Bugzilla and mediawiki integration is being worked in bug 691829.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.