Closed Bug 691829 Opened 13 years ago Closed 13 years ago

Finish implementation of Legnitto's Mediawiki-Bugzilla extension

Categories

(Websites :: wiki.mozilla.org, defect)

Product:
Websites
Component:
wiki.mozilla.org
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: deb, Assigned: brandon)

References

Details

Original blog post about this mediawiki extension is here, including links to github: http://christian.legnitto.com/blog/2011/07/29/announcing-mediawiki-bugzilla-a-mediawiki-extension-embed-bug-data/ Cc'ing Christian here because we don't have a spec, so we're missing specifics about what still needs to be done to finish the add-on.
Assignee: nobody → bsavage
I'm in a holding pattern pending a spec on what needs to be done.
How formal of a spec do you want? I can take time to write up one but here's some very top-level stuff stuff that needs to be done: 1. Support charting when querying for "/count". There is support stubbed out for this * No need to support charting over time right now, a simple chart of the query results will do) 2. Decide if the caching method I am using (just dumping the query data into the db) is good enough. If not, maintain a cache of bugs as table rows so data is shared across queries 3. Improve the user experience for when the page loads while there is no data 4. Make sure multiple requests aren't sent for the same query while it is in the job queue 5. Perhaps move to an api so we can have JS buttons after page reload refresh data 6. Make sure all the lists/tables have links to the query in bugzilla, the last time the query was refreshed, the next time the query will be refreshed, and a comment saying restricted bugs are not included 7. Move away from google charts to something local/client side 8. Support specifying fields ("include_fields") in the query and carry them through to the templates/views (so, for example, I can query on some edge-case field and have it reflected in the output). "_default" (default fields) should probably always be included. Also, feel free to completely rewrite it if you think that would be better...I'm not wedded to the code or the general approach. I'll work on a more formal spec if desired, let me know.
Poke. Is that enough to start with or do you need something more formal?
This should do just fine. Thanks!
Christian, what kind of a setup were you using for testing as you built this?
How are things progressing on this? I'm trying to sketch out a schedule for the next few weeks and some things on my list involve this being ready. Is there an updated ETA?
Looks like Brandon is actively working on this in Christian's git repo. Brendon - Any ETA on when this will be ready to make an appearance on wiki.mozilla.org?
FWIW, it looks like we have a functioning staging server for wiki.mo now: https://wiki.allizom.org/Main_Page It's password protected tho, so will have to ping IT for access I think. We'll have to file a bug to get the add-on installed there first, and will likely want to play with the add-on there first for testing and etc.
CC'ing infrasec who will want to look at this on stage, once it's installed there. CC'ing the DBAs because the stage install will probably need access to Bugzilla's stage DBs.
This work is to implement a bugzilla integration for mediawiki based on the bugzilla REST API. Why do you think this implementation will need access to the Bugzilla stage DBs?
(In reply to Shyam Mani [:fox2mike] from comment #9) > CC'ing infrasec who will want to look at this on stage, once it's installed > there. > > CC'ing the DBAs because the stage install will probably need access to > Bugzilla's stage DBs. Please file a separate security review request bug for this: https://wiki.mozilla.org/WebAppSec/Security_Review_Request Make that bug a blocker of this one.
We won't need DB access for this. REST API is fine.
There are github pull requests for the remaining issues here, which will close this bug.
Great! Do we have/need a separate bug to get this deployed on wiki.mozilla.org?
(In reply to Lawrence Mandel [:lmandel] from comment #14) > Great! Do we have/need a separate bug to get this deployed on > wiki.mozilla.org? You still need a security review, and I already see a few problems (mixed-content HTTP/HTTPS, for one).
Right. I can schedule the review with infrasec once the initial version in done. Can you list the problems that you've already seen so that there is the option to address them before the security review?
(In reply to Lawrence Mandel [:lmandel] from comment #16) > Right. I can schedule the review with infrasec once the initial version in > done. Can you list the problems that you've already seen so that there is > the option to address them before the security review? You can request a review at the following link: https://wiki.mozilla.org/WebAppSec/Security_Review_Request Also, take a look at the secure coding guidelines. Many of the items we find are covered here: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines
Brandon - Is this ready for a security review?
Brandon - It seems that Christian is pretty busy. If you want the project to live in his github repo long terms that's fine. To make progress, do you have the changes in your own github repo (or can you set this up) so that we can push forward with the secreview with an eye to getting this change deployed in 4Q?
I thought I already integrated everything?
Whoops, I see one outstanding
And I'm perfectly fine with having it live in Brandon's...let's get me out of the critical path here and use his repo.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Brandon, you resolved this bug but we haven't yet had a sec review and I don't think that this change has landed on wiki.mozilla.org. Am I missing something?
There is a bug filed for sec review (bug 706936), reopening this one until it's finalized.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Let's get this landed on wikimo.
Brandon - Can you get this landed this week?
This is on wikimo stage; the deployment is in IT's hands.
(In reply to Brandon Savage [:brandon] from comment #27) > This is on wikimo stage; the deployment is in IT's hands. Thanks, Brandon. Do you know who owns it in IT? Can we get an ETA for roll out?
The roll out is being tracked in bug 721366.
mediawiki-bugzilla has been deployed. This bug can be now be resolved.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.