Bug 1889512 - Add external private GitHub link gives an error and no longer produce a linkage
Summary: Add external private GitHub link gives an error and no longer produce a linkage
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Bugzilla
Classification: Community
Component: Extensions
Version: 5.0
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
Assignee: Jeff Fearn 🐞
QA Contact: Utkarsh
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-19 20:02 UTC by Mike Ng
Modified: 2020-10-20 21:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-20 21:49:29 UTC


Attachments (Terms of Use)

Description Mike Ng 2020-10-19 20:02:05 UTC
Description of problem:

I used to be able to add a private Github link to a bugzilla item using the ExternalBugs.add_external_bug. It used to give an error but it managed to add a link even with the error which is good enough for me. 

But now it doesn't work anymore. The error is:

There was an error reported for the RPC call to Jira: There was an error reported for a GitHub REST call. URL: https://api.github.com/repos/open-cluster-management/backlog/issues/6222 Error: 404 Not Found at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 111. at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 111. eval {...} called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 98 Bugzilla::Extension::ExternalBugs::Type::GitHub::_do_rest_call('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x55915d...', 'https://api.github.com/repos/open-cluster-management/backlog/...', 'GET') called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 62 Bugzilla::Extension::ExternalBugs::Type::GitHub::get_data('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x55915d...', 'Bugzilla::Extension::ExternalBugs::Bug=HASH(0x55915c4027d0)') called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Bug.pm line 302 eval {...} called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Bug.pm line 302 Bugzilla::Extension::ExternalBugs::Bug::update_ext_info('Bugzilla::Extension::ExternalBugs::Bug=HASH(0x55915c4027d0)', 1) called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Bug.pm line 125 Bugzilla::Extension::ExternalBugs::Bug::create('Bugzilla::Extension::ExternalBugs::Bug', 'HASH(0x55915bf71358)') called at /var/www/html/bugzilla/extensions/ExternalBugs/Extension.pm line 940 Bugzilla::Extension::ExternalBugs::bug_start_of_update('Bugzilla::Extension::ExternalBugs=HASH(0x55915c732118)', 'HASH(0x55915c5ad818)') called at /var/www/html/bugzilla/Bugzilla/Hook.pm line 21 Bugzilla::Hook::process('bug_start_of_update', 'HASH(0x55915c5ad818)') called at /var/www/html/bugzilla/Bugzilla/Bug.pm line 1173 Bugzilla::Bug::update('Bugzilla::Bug=HASH(0x55915d603ee8)') called at /var/www/html/bugzilla/process_bug.cgi line 558 ModPerl::ROOT::Bugzilla::ModPerl::ResponseHandler::var_www_html_bugzilla_process_bug_2ecgi::handler('Apache2::RequestRec=SCALAR(0x55915c0b9cb0)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 207 eval {...} called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 207 ModPerl::RegistryCooker::run('Bugzilla::ModPerl::ResponseHandler=HASH(0x55915b9c5810)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 173 ModPerl::RegistryCooker::default_handler('Bugzilla::ModPerl::ResponseHandler=HASH(0x55915b9c5810)') called at /usr/lib64/perl5/vendor_perl/ModPerl/Registry.pm line 32 ModPerl::Registry::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x55915c0b9cb0)') called at /var/www/html/bugzilla/mod_perl.pl line 139 Bugzilla::ModPerl::ResponseHandler::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x55915c0b9cb0)') called at -e line 0 eval {...} called at -e line 0 at /var/www/html/bugzilla/Bugzilla/Error.pm line 130. Bugzilla::Error::_throw_error('global/user-error.html.tmpl', 'ext_bz_rest_error', 'HASH(0x55915d611fa8)') called at /var/www/html/bugzilla/Bugzilla/Error.pm line 193 Bugzilla::Error::ThrowUserError('ext_bz_rest_error', 'HASH(0x55915d611fa8)') called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 120 Bugzilla::Extension::ExternalBugs::Type::GitHub::_do_rest_call('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x55915d...', 'https://api.github.com/repos/open-cluster-management/backlog/...', 'GET') called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Type/GitHub.pm line 62 Bugzilla::Extension::ExternalBugs::Type::GitHub::get_data('Bugzilla::Extension::ExternalBugs::Type::GitHub=HASH(0x55915d...', 'Bugzilla::Extension::ExternalBugs::Bug=HASH(0x55915c4027d0)') called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Bug.pm line 302 eval {...} called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Bug.pm line 302 Bugzilla::Extension::ExternalBugs::Bug::update_ext_info('Bugzilla::Extension::ExternalBugs::Bug=HASH(0x55915c4027d0)', 1) called at /loader/0x55915673f5d0/Bugzilla/Extension/ExternalBugs/Bug.pm line 125 Bugzilla::Extension::ExternalBugs::Bug::create('Bugzilla::Extension::ExternalBugs::Bug', 'HASH(0x55915bf71358)') called at /var/www/html/bugzilla/extensions/ExternalBugs/Extension.pm line 940 Bugzilla::Extension::ExternalBugs::bug_start_of_update('Bugzilla::Extension::ExternalBugs=HASH(0x55915c732118)', 'HASH(0x55915c5ad818)') called at /var/www/html/bugzilla/Bugzilla/Hook.pm line 21 Bugzilla::Hook::process('bug_start_of_update', 'HASH(0x55915c5ad818)') called at /var/www/html/bugzilla/Bugzilla/Bug.pm line 1173 Bugzilla::Bug::update('Bugzilla::Bug=HASH(0x55915d603ee8)') called at /var/www/html/bugzilla/process_bug.cgi line 558 ModPerl::ROOT::Bugzilla::ModPerl::ResponseHandler::var_www_html_bugzilla_process_bug_2ecgi::handler('Apache2::RequestRec=SCALAR(0x55915c0b9cb0)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 207 eval {...} called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 207 ModPerl::RegistryCooker::run('Bugzilla::ModPerl::ResponseHandler=HASH(0x55915b9c5810)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 173 ModPerl::RegistryCooker::default_handler('Bugzilla::ModPerl::ResponseHandler=HASH(0x55915b9c5810)') called at /usr/lib64/perl5/vendor_perl/ModPerl/Registry.pm line 32 ModPerl::Registry::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x55915c0b9cb0)') called at /var/www/html/bugzilla/mod_perl.pl line 139 Bugzilla::ModPerl::ResponseHandler::handler('Bugzilla::ModPerl::ResponseHandler', 'Apache2::RequestRec=SCALAR(0x55915c0b9cb0)') called at -e line 0 eval {...} called at -e line 0 


Version-Release number of selected component (if applicable):
The current Bugzilla version.

How reproducible:


Steps to Reproduce:
1. go to https://bugzilla.redhat.com/show_bug.cgi?id=1888267
2. try to add an external link https://github.com/open-cluster-management/backlog/issues/6222
3. when I click save, it errors.

Actual results:


Expected results:


Additional info:

Comment 4 Alasdair Kergon 2020-10-20 13:36:20 UTC
Are all the issues private?  Or is there a mixture?

Comment 5 Mike Ng 2020-10-20 13:51:14 UTC
Hi Alasdair, 

I've tested with a public github link in https://bugzilla.redhat.com/show_bug.cgi?id=1888267 and it seems to be ok.
So far I think only adding private issue link is not working.

Well technically speaking, it was never fully working before, it always returned some errors but the link was able to be added.

Comment 6 Alasdair Kergon 2020-10-20 13:57:37 UTC
I'm trying to understand if there's a genuine mix of public and private links here, or if they are grouped - is everything "backlog" private and everything "multicloud-operators-subscription-release" public - or if individual issues flip between public and private.

Or in other words, do private issues need to have public links in bugzilla?

Comment 7 Mike Ng 2020-10-20 14:01:34 UTC
"do private issues need to have public links in bugzilla?"

I will say yes, to assist the developers who will be solving the bugzilla item. It might not be useful to the person who created the bugzilla item because he/she might not have access but it might help the people who are working on bug.

Comment 8 Alasdair Kergon 2020-10-20 14:03:41 UTC
What we've done for JIRA is have TWO types of links in bugzilla - public ones and private ones - so when you're linking you choose the right one.  (Though only one can process a pasted URL.)

3 options)
  1) Change the code to not treat it as an error if the URL is inaccessible - possibly displaying the link as inaccessible
  2) Have a second external tracker for private issues that doesn't check the URL (current solution on offer)
  3) Have some new logic that spots the 404 and makes the link private - so each link has access restrictions beyond the existing one (various options here but complicated)

Comment 9 Alasdair Kergon 2020-10-20 14:06:28 UTC
(In reply to Mike Ng from comment #7)
> "do private issues need to have public links in bugzilla?"
> 
> I will say yes, to assist the developers who will be solving the bugzilla
> item. It might not be useful to the person who created the bugzilla item
> because he/she might not have access but it might help the people who are
> working on bug.

So what use will the public make of the public link?  You're saying that the public, who can't access the link, do have a need to see the URL?  And a solution where only (say) Red Hat employees could see what the URL was, would not work for you?

Comment 10 Alasdair Kergon 2020-10-20 14:08:37 UTC
So that means option 2 would be for a 'GitHub (restricted access)' external tracker which was public, where bugzilla does not validate the URL.

Comment 11 Mike Ng 2020-10-20 14:14:51 UTC
Ginny do you want to chime in on which option you prefer? 

I like option "2) Have a second external tracker for private issues that doesn't check the URL (current solution on offer)"

Comment 12 Jeff Fearn 🐞 2020-10-20 21:49:29 UTC
Hi, if a tracker that can sync cannot verify the issue exists then BZ is expected to reject the issue. So this is now working correctly.


Note You need to log in before you can comment on or make changes to this bug.