Summary

Add new properties to BaseBugTracker and subclasses.

Review Request #15258 — Created Aug. 31, 2026 and submitted Sept. 5, 2026, 10:31 a.m.

Information

Owner

david

Repository

Review Board

Branch

release-9.x

Bugs

Depends On

Reviewers

Groups

reviewboard

People

Description

This change adds several new properties to the bug-tracker service
implementations:

bug_tracker_label is used as the default field label for trackers on that
service (e.g. a GitHub repo will show "GitHub Issues:" instead of
"Bugs:")
supports_bug_info is a flag that will allow us to more efficiently
check if a hosting service includes the get_bug_info() method.
supports_bug_search is a new flag to indicate whether a bug tracker
backend supports interactive searching for bugs.
bugs_in_repo is a flag to indicate that a service's tracker is bound
to its repository (e.g. GitHub Issues). For services where this is the
case, the tracker is added individually for each repo instead of
having a central config that can link to multiple repositories.

Testing Done

Ran unit tests.

Commits

Summary	ID
Add new properties to BaseBugTracker and subclasses. This change adds several new properties to the bug-tracker service implementations: - bug_tracker_label` is used as the default field label for trackers on that service (e.g. a GitHub repo will show "GitHub Issues:" instead of "Bugs:") - `supports_bug_info` is a flag that will allow us to more efficiently check if a hosting service includes the `get_bug_info()` method. - `supports_bug_search` is a new flag to indicate whether a bug tracker backend supports interactive searching for bugs. - `bugs_in_repo` is a flag to indicate that a service's tracker is bound to its repository (e.g. GitHub Issues). For services where this is the case, the tracker is added individually for each repo instead of having a central config that can link to multiple repositories. Testing Done: Ran unit tests.	psxzukwyzltknkyvtllssyuyxzpmyrxn

Summary

Add new properties to BaseBugTracker and subclasses.

This change adds several new properties to the bug-tracker service implementations: - bug_tracker_label` is used as the default field label for trackers on that service (e.g. a GitHub repo will show "GitHub Issues:" instead of "Bugs:") - `supports_bug_info` is a flag that will allow us to more efficiently check if a hosting service includes the `get_bug_info()` method. - `supports_bug_search` is a new flag to indicate whether a bug tracker backend supports interactive searching for bugs. - `bugs_in_repo` is a flag to indicate that a service's tracker is bound to its repository (e.g. GitHub Issues). For services where this is the case, the tracker is added individually for each repo instead of having a central config that can link to multiple repositories. Testing Done: Ran unit tests.

psxzukwyzltknkyvtllssyuyxzpmyrxn

Issues

Description	From	Last Updated
Typo in bugs_in_repo section in the description: "a service's tracker in bound ..." -> is.	maubin	Sept. 2, 2026, 9:04 a.m.
We don't actually replace the isinstance(bug_tracker, BaseBugTracker) check in BugInfoboxView.get() with supports_bug_info in this change, we should do that.	maubin	Sept. 2, 2026, 9:12 a.m.
Looks like this attribute was supposed to be added to BaseHostingService instead of here? In this change you set it …	maubin	Sept. 2, 2026, 9:19 a.m.
Looks like this attribute was supposed to be added to BaseHostingService, since we're using it to check whether a hosting …	maubin	Sept. 2, 2026, 9:14 a.m.
I don't see a search_bugs method here or in any of the other Bug Tracker changes you have up.	maubin	Sept. 1, 2026, 4:19 p.m.

flake8 passed.

JSHint passed.

Description:: This change adds several new properties to the bug-tracker service
implementations:

~
bug_tracker_label` is used as the default field label for trackers on that
service (e.g. a GitHub repo will show "GitHub Issues:" instead of
"Bugs:")
~
bug_tracker_label is used as the default field label for trackers on that
service (e.g. a GitHub repo will show "GitHub Issues:" instead of
"Bugs:")

supports_bug_info is a flag that will allow us to more efficiently
check if a hosting service includes the get_bug_info() method.

supports_bug_search is a new flag to indicate whether a bug tracker
backend supports interactive searching for bugs.

bugs_in_repo is a flag to indicate that a service's tracker in bound
to its repository (e.g. GitHub Issues). For services where this is the
case, the tracker is added individually for each repo instead of
having a central config that can link to multiple repositories.

The issue has been resolved. Show all issues

Typo in bugs_in_repo section in the description: "a service's tracker in bound ..." -> is.

The issue has been resolved. Show all issues

We don't actually replace the isinstance(bug_tracker, BaseBugTracker) check in BugInfoboxView.get() with supports_bug_info in this change, we should do that.

reviewboard/hostingsvcs/base/bug_tracker.py (Diff revision 1)

The issue has been resolved. Show all issues

Looks like this attribute was supposed to be added to BaseHostingService instead of here? In this change you set it on all of the hosting services that aren't subclasses of BaseBugTracker.

david

Sept. 2, 2026, 9:25 a.m.

This one I'm going to keep where it is. For now I'll add it commented-out to services that don't implement that, with a TODO (and just undo the change for dead services like fedorahosted and google code).

reviewboard/hostingsvcs/base/bug_tracker.py (Diff revision 1)

The issue has been resolved. Show all issues

Looks like this attribute was supposed to be added to BaseHostingService, since we're using it to check whether a hosting service is also a bug tracker. Otherwise it doesn't really make sense to have this attribute, we'd still need to be doing a hasattr(service, 'supports_bug_info') sort of check.

reviewboard/hostingsvcs/base/bug_tracker.py (Diff revision 1)

The issue has been dropped. Show all issues

I don't see a search_bugs method here or in any of the other Bug Tracker changes you have up.

david

Sept. 2, 2026, 9:25 a.m.
```
This is coming in a later change.
```

Description:

		This change adds several new properties to the bug-tracker service
		implementations:

		`bug_tracker_label` is used as the default field label for trackers on that service (e.g. a GitHub repo will show "GitHub Issues:" instead of "Bugs:")
		`supports_bug_info` is a flag that will allow us to more efficiently check if a hosting service includes the `get_bug_info()` method.
		`supports_bug_search` is a new flag to indicate whether a bug tracker backend supports interactive searching for bugs.
~		`bugs_in_repo` is a flag to indicate that a service's tracker in bound to its repository (e.g. GitHub Issues). For services where this is the case, the tracker is added individually for each repo instead of having a central config that can link to multiple repositories.
	~	`bugs_in_repo` is a flag to indicate that a service's tracker is bound to its repository (e.g. GitHub Issues). For services where this is the case, the tracker is added individually for each repo instead of having a central config that can link to multiple repositories.

Commits:

	Summary	ID
	Add new properties to BaseBugTracker and subclasses. This change adds several new properties to the bug-tracker service implementations: - bug_tracker_label` is used as the default field label for trackers on that service (e.g. a GitHub repo will show "GitHub Issues:" instead of "Bugs:") - `supports_bug_info` is a flag that will allow us to more efficiently check if a hosting service includes the `get_bug_info()` method. - `supports_bug_search` is a new flag to indicate whether a bug tracker backend supports interactive searching for bugs. - `bugs_in_repo` is a flag to indicate that a service's tracker in bound to its repository (e.g. GitHub Issues). For services where this is the case, the tracker is added individually for each repo instead of having a central config that can link to multiple repositories. Testing Done: Ran unit tests.	psxzukwyzltknkyvtllssyuyxzpmyrxn
	Add new properties to BaseBugTracker and subclasses. This change adds several new properties to the bug-tracker service implementations: - bug_tracker_label` is used as the default field label for trackers on that service (e.g. a GitHub repo will show "GitHub Issues:" instead of "Bugs:") - `supports_bug_info` is a flag that will allow us to more efficiently check if a hosting service includes the `get_bug_info()` method. - `supports_bug_search` is a new flag to indicate whether a bug tracker backend supports interactive searching for bugs. - `bugs_in_repo` is a flag to indicate that a service's tracker is bound to its repository (e.g. GitHub Issues). For services where this is the case, the tracker is added individually for each repo instead of having a central config that can link to multiple repositories. Testing Done: Ran unit tests.	psxzukwyzltknkyvtllssyuyxzpmyrxn

Diff:

Revision 2 (+154 -4)

Show changes

	reviewboard/hostingsvcs/assembla.py
	reviewboard/hostingsvcs/bitbucket.py
	reviewboard/hostingsvcs/bugzilla.py
	reviewboard/hostingsvcs/codebasehq.py
	reviewboard/hostingsvcs/gitlab.py
	reviewboard/hostingsvcs/jira.py
	reviewboard/hostingsvcs/sourceforge.py
	reviewboard/hostingsvcs/splat.py
	6 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to release-9.x (67fabf1)

		This change adds several new properties to the bug-tracker service
		implementations:

~		bug_tracker_label` is used as the default field label for trackers on that service (e.g. a GitHub repo will show "GitHub Issues:" instead of "Bugs:")
	~	`bug_tracker_label` is used as the default field label for trackers on that service (e.g. a GitHub repo will show "GitHub Issues:" instead of "Bugs:")
		`supports_bug_info` is a flag that will allow us to more efficiently check if a hosting service includes the `get_bug_info()` method.
		`supports_bug_search` is a new flag to indicate whether a bug tracker backend supports interactive searching for bugs.
		`bugs_in_repo` is a flag to indicate that a service's tracker in bound to its repository (e.g. GitHub Issues). For services where this is the case, the tracker is added individually for each repo instead of having a central config that can link to multiple repositories.