BugReferencesCheck relies on limited permissions to determine status of bug
Categories
(Conduit :: Lando, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: zeid, Unassigned)
References
Details
get_status_code_for_bug (which BugReferencesCheck relies on) assumes that the Lando user can not access security bugs. If that is ever changed (e.g., to add support for bug 2055604) this check will stop working as expected. There should be an additional check, even if a bug is fetched successfully, that returns the exact value of the flag.
|
||
Comment 1•4 days ago
|
||
It can be improved if desired but so long as it continues to pass (via the default arg) use_api_key=False it should continue to work as expected. In fact, I believe right now Lando has release-track bug access so while at time-of-landing most bugs are not tagged as such, a minority could be.
|
Reporter | |
Comment 2•3 days ago
|
||
(In reply to Tom Ritter [:tjr] from comment #1)
It can be improved if desired but so long as it continues to pass (via the default arg)
use_api_key=Falseit should continue to work as expected. In fact, I believe right now Lando has release-track bug access so while at time-of-landing most bugs are not tagged as such, a minority could be.
True, this is not a blocker in this case. I think the improvement would be good though to prevent regressions, if we ever switch to using API keys.
|
||
Comment 3•5 hours ago
|
||
(In reply to Tom Ritter [:tjr] from comment #1)
In fact, I believe right now Lando has release-track bug access
It doesn't as far as I can tell from the group membership report, neither directly nor inherited. Instead it looks like it gets "blessed" with those permissions for the length of the API call: https://github.com/mozilla-bteam/bmo/blob/ec62c69cfed9ddc6ee30e8051b88aa4664649f56/extensions/PhabBugz/lib/API/V1/PhabBugz.pm#L59-L61 (same pattern in the other APIs used by Phab).
Description
•