mozilla-bteam / bz.js Goto Github PK

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

I wanted to try out the most recent version of bz.js in my browser, but there is no documentation of how the browser-based versions are created, and the downloads have not been updated.

In jdm/bugsahoy#12, we've noticed that bz.js triggers a security violation in Opera 11.51 when trying to perform a search. I have no idea whether this is affects other versions or not, but it's something to be aware of. I'm presuming at this point that it's not the fault of bz.js, considering the success rate in other browsers.

The real rest backend is not backwards compatible so we need to bump to v1x and pre 1.x can support the old bzapi (for backwards compat).

I'd like to update bugzilla-todos with a newer version of bz.js - @harthur would you mind incrementing the version & uploading one (I'd rather use an official versioned release than upload my local build to just bugzilla-todos). Thanks! :-)

Need to use the URL described in https://bugzilla.mozilla.org/show_bug.cgi?id=924405#c11 until DKL adds an equivalent.

Trying to use bz in my browserified bundle and browserify spits back this message

I'm working on a project to make a yeoman generator to file bug reports in bugzilla, and I need to get product information from bugzilla so I can auto fill fields like product, component and version. I've implemented the code in my own project to query and process the /rest/product API. Would you consider a PR which adds methods to the BugzillaClient class to get this product information?

var bz = require("bz");
var bugzilla = bz.createClient();
bugzilla.searchBugs({"flag.requestee": "[email protected]"}, function(bugs) {
  console.log(bugs);
});

Output is undefined, but if I edit bz.js, I can see that there are results returned.

https://api-dev.bugzilla.mozilla.org/latest/bug/767101 returns:

code: 102
error: 1
message: Access Denied

However bz.js' getBug() doesn't attempt to parse the response, since the response status is 400:

    else if(response.status >= 300 || response.status < 200)
      error = "HTTP status " + response.status;
    else {
      try {
        json = JSON.parse(response.responseText);
      } catch(e) {
        error = "Response wasn't valid json: '" + response.responseText + "'";         
      }
    }

So we lose the "Access Denied" message, and instead return an err value of "HTTP status 400", which presumably can occur for other malformed request cases too.

This means that in the case of https://github.com/harthur/bugzilla-todos/issues/55 we have to treat HTTP 400s as all being access denied, when it would be useful to surface the other cases differently.

Hi,

This bug has been filed because a code search has revealed that code in this repository is using "BzAPI", the Bugzilla API proxy server at https://api-dev.bugzilla.mozilla.org/.

This service is due to be decommissioned. Fortunately, Bugzilla has a new native REST API which works somewhat similarly that you could use instead:
https://wiki.mozilla.org/Bugzilla:REST_API

Moving to that new API would require some porting work. If that seems like too much effort, fear not, because there is also a BzAPI compatibility layer built on top of the new API. Because it's compatible, using that should simply require a change of API endpoint.

Change:
https://api-dev.bugzilla.mozilla.org/latest/
(or https://api-dev.bugzilla.mozilla.org/1.3/)
to
https://bugzilla.mozilla.org/bzapi/

You should not expect the api-dev server to continue to work after Friday 14th November. So please test and migrate your production instance(s) over before then, either to the BzAPI compatibility endpoint or to the new native REST API.

Thanks for using BzAPI. It's been a great ride :-)

Gerv

Right now in 0.4.3, calls to /configuration are hardcoded to the production bzapi. It'd be nice if this could accept a different api root, if provided (so we can test against https://bugzilla-dev.allizom.org/bzapi/configuration for instance).

I'd also suggest switching the production /configuration call to use https://bugzilla.mozilla.org/bzapi/configuration instead of https://api-dev.bugzilla.mozilla.org/latest/configuration but that's neither here nor there...

( silence === assent, so if you aren't interested in this project just ignore, sorry for the spam )

I'd like feedback on this issue, so I'm tagging the current set of contributors to see if people have opinions:

• @harthur
• @Pike
• @graememcc
• @KevinGrandon
• @jdm
• @lightsofapollo
• @blakmatrix

I've done a bit of work to move this project over to es6 and the babel transpiler in the babel branch.

There are two key use cases for this library - writing scripts in node, and for use in web pages. There is a third smaller use case - for use in Firefox extensions. Moving to es6 is more of a 'new things are nice' move, but it was pretty straightforward. Shimming node / jetpack is nice, and the big change was bringing over Jame's work to change the client to use the rest endpoint instead of bzapi.

By moving to babel and a gulp-based build system I've implemented a very simple attempt at this:

• get and post requests are abstracted in the xhr module which proxies either the SDK's request module or node's request module.
• browserify produces a browser-compatible and bundled js file for browsers.

The current state is that basic things work but I haven't tested all functionality. I intend to port Heather's testing code and make it easier for people to contribute to this going forward, and fix any remaining bugs ( in particular auth issues that may crop up ).

This is tricky - looks like I need to check in credentials for landfill in order to test everything.