Support optional client-side Bugzilla authentication to allow displaying non-public bugs?

[mozfreddyb]

I don't know much info the API gives out, but if a non-public bug is known to be awaiting my action, it would be nice if the bug number would at least be shown. Even if other data is missing.

I think this might go in all the bugs.forEach() calls (in user.js) but wasn't sure where this makes most sense for you, so I didn't take a stab at it.

[edmorley]

I don't think this information is available without authenticating.

[mozfreddyb]

Yeah...but well it doesn't request details for all hidden bug IDs but only those that are somehow linked to me ;)
I couldn't find it in the code, but maybe there's at least something we can get out of it... :|

[edmorley]

It doesn't matter for whom the bugs are, non open bugs still require authentication to view, so there is no way we can do this unless we switch to logging in via bugzilla-todos.

[mozfreddyb]

But bugzilla-todo does know these bugs contain actionable items for the current user (just not in which category they should do.)
Right now we just hide them from the user, which means it kinda lies when it says it lists all TODO items ;)

[edmorley]

But bugzilla-todo does know these bugs contain actionable items for the current user

Proof/example? :-)

[edmorley]

(Watch the webconsole when loading Bugzilla-todos for the BzAPI calls that are made - none of those should return hidden bugs, since they are unauthenticated. Note they are all bug searches - there isn't a generic "show me my requests" API endpoint)

[mozfreddyb]

Watch the webconsole when loading Bugzilla-todos for the BzAPI calls that are made - none of those should return hidden bugs

But they do :D
I found it hard to track down with the debugger, though, so here's a screenshot (sorry)

[edmorley]

I just tried bugzilla-todos for your bugzilla username - and I do see that. However those bug numbers are only queried as part of the "is bug foo blocked by bug bar, in which case should we hide it from the to-fix list" feature.

ie, the bzapi query:
https://api-dev.bugzilla.mozilla.org/latest//bug?email1=fbraun%40mozilla.com&email1_type=equals&email1_assigned_to=1&field0-1-0=whiteboard&type0-1-0=not_contains&value0-1-0=fixed&order=changeddate%20DESC&status=NEW&status=UNCONFIRMED&status=REOPENED&status=ASSIGNED&include_fields=id%2Csummary%2Cstatus%2Cresolution%2Clast_change_time%2Cattachments%2Cdepends_on
...returns all bugs to which you are assigned and their depends_on field. Bugzilla-todos then follows this with calls to https://api-dev.bugzilla.mozilla.org/latest/bug/N for each bug referenced.

So all Bugzilla-todos would be able to tell you is that "for public bug X to which you are assigned, bug Y on which it depends is non-public (but we don't know its summary, status/resolution, or what flags are set inside it)", rather than "show me all bugs that require my action, even if they are non-public" (which is what I understand by comment 0 in this issue - do say if you're asking for something else).

Any other behaviour would be a breach of the Bugzilla security model, and as such something that should be filed and fixed. As such, if we wish to make Bugzilla-todos support non-public bugs, it needs to support authentication - not necessarily a bad thing (we could enforce that Bugzilla-todos was accessed via https and do this client side, but we'd presumably want security review etc first).

[edmorley]

That said, we should catch the HTTP 400 on the "check dependant bugs" call, rather than throw. I'd imagine it makes most sense to ignore non-public bugs in the determination as to whether a bug is ready to be fixed or not (I'd rather false negatives than false positives for exclusion).

[mozfreddyb]

Thanks for the clarification!
I agree that using authentication in bugzilla-todo might be a non-goal. (If it isn't, I'm willing to help on security reviews)

[edmorley]

Given that #55 will prevent the thrown exception - seems like it's now best to morph the summary of this issue to something like "Support optional client-side Bugzilla authentication to allow displaying non-public bugs" - does that sound about right to you?

[mozfreddyb]

sure

[edmorley]

@harthur - could you modify the summary of this issue to that two comments up, since we don't have permissions? Thanks :-)

[mozfreddyb]

I can too :D

[mozfreddyb]

Issue "HTTP 400 for non-public bugs" renamed to "Support optional client-side Bugzilla authentication to allow displaying non-public bugs?"