Summary

Add formal support for service accounts.

Review Request #15105 — Created June 7, 2026 and updated June 8, 2026, 5:35 p.m.

Information

Owner

chipx86

Repository

Review Board

Branch

release-8.x

Bugs

Depends On

Blocks

15107

Reviewers

Groups

reviewboard

People

Description

These won't be our last such accounts, and we currently don't have a way
of distinguishing between these and normal users, which means they get
added to subscription licenses when they shouldn't.

This change formalizes all of this with a new ServiceAccount object.
These can be subclassed or instantiated with information on the account
(a stable but unique service account registration ID, a name, e-mail
address, avatars, preferred username (if available), API token policy,
and more). They can then be registered in a central registry.

Upon registration, a user account will be fetched or created for the
account and made available for later use. The logic for figuring out the
user account is probably the largest part of this change. It does the
following:

If the registration claims a user (which should only be done if
there's state saying it once created that user for this purpose), it
will be fetched and populated with state to identify it as a service
account user.
If not claiming a user, it will fetch the preferred username and see
if it's marked with identifying state. If so, it returns it. Else, it
adds a number to the end and tries again.
If a username is scanned and not found, it will be chosen as the
user.

Any user that's picked for the service account will have a
service_account_id in Profile.extra_data, which will aid in finding
the user in the future. Extensions are advised to store the resulting
username and claim it for future use, to speed up the loading process.

Due to the way that user creation works, it's now possible to listen for
post_save signal for a user and check if it corresponds to a
ServiceAccount. This means we can avoid auto-adding new service
accounts to licenses.

Once a ServiceAccount is registered, both the user and an API token
can be accessed for use. This will use a client API token, identifying
the token as being owned by this ServiceAccount, and with a minimum
validity window of 5 hours (meaning if an existing token is found that
has less time than this, a new token will be created to help avoid
integration issues).

If profile or API token state needs to be forcefully updated, the
extension can bump one of the two version fields (one for profile, one
for token information), which will force an update.

A User Details Provider now exists to badge service accounts with
"Service Account", so that they can be easily distinguished whenever
they might be shown.

Testing Done

Tested registering a ServiceAccount for a test user and verified
the user account was claimed and the user badged.

Tested registering without a user claim and verified it scanned and
created a suitable user.

Unit tests pass.

Commits

Summary	ID
Add formal support for service accounts. Review Bot and now the Doc Converter both create users designed for automated communication with the Review Board API. Currently, both need to create the users manually, and they both do this differently, with different resulting states. These won't be our last such accounts, and we currently don't have a way of distinguishing between these and normal users, which means they get added to subscription licenses when they shouldn't. This change formalizes all of this with a new `ServiceAccount` object. These can be subclassed or instantiated with information on the account (a stable but unique service account registration ID, a name, e-mail address, avatars, preferred username (if available), API token policy, and more). They can then be registered in a central registry. Upon registration, a user account will be fetched or created for the account and made available for later use. The logic for figuring out the user account is probably the largest part of this change. It does the following: 1. If the registration claims a user (which should only be done if there's state saying it once created that user for this purpose), it will be fetched and populated with state to identify it as a service account user. 2. If not claiming a user, it will fetch the preferred username and see if it's marked with identifying state. If so, it returns it. Else, it adds a number to the end and tries again. 3. If a username is scanned and not found, it will be chosen as the user. Any user that's picked for the service account will have a `service_account_id` in `Profile.extra_data`, which will aid in finding the user in the future. Extensions are advised to store the resulting username and claim it for future use, to speed up the loading process. Due to the way that user creation works, it's now possible to listen for `post_save` signal for a user and check if it corresponds to a `ServiceAccount`. This means we can avoid auto-adding new service accounts to licenses. Once a `ServiceAccount` is registered, both the user and an API token can be accessed for use. This will use a client API token, identifying the token as being owned by this `ServiceAccount`, and with a minimum validity window of 5 hours (meaning if an existing token is found that has less time than this, a new token will be created to help avoid integration issues). If profile or API token state needs to be forcefully updated, the extension can bump one of the two version fields (one for profile, one for token information), which will force an update. A User Details Provider now exists to badge service accounts with "Service Account", so that they can be easily distinguished whenever they might be shown.	0cf5bb955484cac5c4945dc632169feefb23427c

Summary

Add formal support for service accounts.

Review Bot and now the Doc Converter both create users designed for automated communication with the Review Board API. Currently, both need to create the users manually, and they both do this differently, with different resulting states. These won't be our last such accounts, and we currently don't have a way of distinguishing between these and normal users, which means they get added to subscription licenses when they shouldn't. This change formalizes all of this with a new `ServiceAccount` object. These can be subclassed or instantiated with information on the account (a stable but unique service account registration ID, a name, e-mail address, avatars, preferred username (if available), API token policy, and more). They can then be registered in a central registry. Upon registration, a user account will be fetched or created for the account and made available for later use. The logic for figuring out the user account is probably the largest part of this change. It does the following: 1. If the registration claims a user (which should only be done if there's state saying it once created that user for this purpose), it will be fetched and populated with state to identify it as a service account user. 2. If not claiming a user, it will fetch the preferred username and see if it's marked with identifying state. If so, it returns it. Else, it adds a number to the end and tries again. 3. If a username is scanned and not found, it will be chosen as the user. Any user that's picked for the service account will have a `service_account_id` in `Profile.extra_data`, which will aid in finding the user in the future. Extensions are advised to store the resulting username and claim it for future use, to speed up the loading process. Due to the way that user creation works, it's now possible to listen for `post_save` signal for a user and check if it corresponds to a `ServiceAccount`. This means we can avoid auto-adding new service accounts to licenses. Once a `ServiceAccount` is registered, both the user and an API token can be accessed for use. This will use a client API token, identifying the token as being owned by this `ServiceAccount`, and with a minimum validity window of 5 hours (meaning if an existing token is found that has less time than this, a new token will be created to help avoid integration issues). If profile or API token state needs to be forcefully updated, the extension can bump one of the two version fields (one for profile, one for token information), which will force an update. A User Details Provider now exists to badge service accounts with "Service Account", so that they can be easily distinguished whenever they might be shown.

0cf5bb955484cac5c4945dc632169feefb23427c

Issues

Description	From	Last Updated
local variable 'user' is assigned to but never used Column: 13 Error code: F841	reviewbot	June 7, 2026, 11:12 a.m.
'datetime.timedelta' imported but unused Column: 1 Error code: F401	reviewbot	June 7, 2026, 11:13 a.m.
'django.utils.timezone' imported but unused Column: 1 Error code: F401	reviewbot	June 7, 2026, 11:13 a.m.
line too long (88 > 79 characters) Column: 80 Error code: E501	reviewbot	June 7, 2026, 11:13 a.m.
redefinition of unused 'Iterator' from line 11 Column: 5 Error code: F811	reviewbot	June 7, 2026, 11:13 a.m.
This is assigned None but never read. Were you intending on using this as a cache in get_api_token()? If you …	david	June 8, 2026, 5:35 p.m.
Typo: thaat -> that	david	June 8, 2026, 5:35 p.m.
If two services want the same username ("bot" for example), this will stomp over an existing one. We should check …	david	June 8, 2026, 5:35 p.m.
Typo: Pleaase -> Please	david	June 8, 2026, 5:35 p.m.
I don't see how profile could be falsy at this point.	david	June 8, 2026, 5:35 p.m.
__init__ already defauts self.email to be mail_default_from, so the contents of this block are an unreachable duplicate of what we …	david	June 8, 2026, 5:35 p.m.
last_name is a CharField(blank=True, null=False). Having None here works okay for sqlite but will fail on MySQL and Postgres.	david	June 8, 2026, 5:35 p.m.
minimum subclass -> minimum init	david	June 8, 2026, 5:35 p.m.
should mention subclass here (right now this has the same docstring as test_init_with_override_all)	david	June 8, 2026, 5:35 p.m.
Should be ServiceAccountRegistry	david	June 8, 2026, 5:35 p.m.

flake8 failed.

JSHint passed.

flake8

reviewboard/accounts/service_accounts.py (Diff revision 1)
The issue has been resolved. Show all issues
```
local variable 'user' is assigned to but never used

Column: 13
Error code: F841
```
reviewboard/accounts/tests/test_service_account_registry.py (Diff revision 1)
The issue has been resolved. Show all issues
```
'datetime.timedelta' imported but unused

Column: 1
Error code: F401
```
reviewboard/accounts/tests/test_service_account_registry.py (Diff revision 1)
The issue has been resolved. Show all issues
```
'django.utils.timezone' imported but unused

Column: 1
Error code: F401
```
reviewboard/accounts/tests/test_service_account_registry.py (Diff revision 1)
The issue has been resolved. Show all issues
```
line too long (88 > 79 characters)

Column: 80
Error code: E501
```
reviewboard/accounts/user_details.py (Diff revision 1)
The issue has been resolved. Show all issues
```
redefinition of unused 'Iterator' from line 11

Column: 5
Error code: F811
```

Change Summary:

Removed unused variables and imports.

Commits:

	Summary	ID
	Add formal support for service accounts. Review Bot and now the Doc Converter both create users designed for automated communication with the Review Board API. Currently, both need to create the users manually, and they both do this differently, with different resulting states. These won't be our last such accounts, and we currently don't have a way of distinguishing between these and normal users, which means they get added to subscription licenses when they shouldn't. This change formalizes all of this with a new `ServiceAccount` object. These can be subclassed or instantiated with information on the account (a stable but unique service account registration ID, a name, e-mail address, avatars, preferred username (if available), API token policy, and more). They can then be registered in a central registry. Upon registration, a user account will be fetched or created for the account and made available for later use. The logic for figuring out the user account is probably the largest part of this change. It does the following: 1. If the registration claims a user (which should only be done if there's state saying it once created that user for this purpose), it will be fetched and populated with state to identify it as a service account user. 2. If not claiming a user, it will fetch the preferred username and see if it's marked with identifying state. If so, it returns it. Else, it adds a number to the end and tries again. 3. If a username is scanned and not found, it will be chosen as the user. Any user that's picked for the service account will have a `service_account_id` in `Profile.extra_data`, which will aid in finding the user in the future. Extensions are advised to store the resulting username and claim it for future use, to speed up the loading process. Due to the way that user creation works, it's now possible to listen for `post_save` signal for a user and check if it corresponds to a `ServiceAccount`. This means we can avoid auto-adding new service accounts to licenses. Once a `ServiceAccount` is registered, both the user and an API token can be accessed for use. This will use a client API token, identifying the token as being owned by this `ServiceAccount`, and with a minimum validity window of 5 hours (meaning if an existing token is found that has less time than this, a new token will be created to help avoid integration issues). If profile or API token state needs to be forcefully updated, the extension can bump one of the two version fields (one for profile, one for token information), which will force an update. A User Details Provider now exists to badge service accounts with "Service Account", so that they can be easily distinguished whenever they might be shown.	819d46e96258ff2da4d1e5d3e9c6fadcb8987537
	Add formal support for service accounts. Review Bot and now the Doc Converter both create users designed for automated communication with the Review Board API. Currently, both need to create the users manually, and they both do this differently, with different resulting states. These won't be our last such accounts, and we currently don't have a way of distinguishing between these and normal users, which means they get added to subscription licenses when they shouldn't. This change formalizes all of this with a new `ServiceAccount` object. These can be subclassed or instantiated with information on the account (a stable but unique service account registration ID, a name, e-mail address, avatars, preferred username (if available), API token policy, and more). They can then be registered in a central registry. Upon registration, a user account will be fetched or created for the account and made available for later use. The logic for figuring out the user account is probably the largest part of this change. It does the following: 1. If the registration claims a user (which should only be done if there's state saying it once created that user for this purpose), it will be fetched and populated with state to identify it as a service account user. 2. If not claiming a user, it will fetch the preferred username and see if it's marked with identifying state. If so, it returns it. Else, it adds a number to the end and tries again. 3. If a username is scanned and not found, it will be chosen as the user. Any user that's picked for the service account will have a `service_account_id` in `Profile.extra_data`, which will aid in finding the user in the future. Extensions are advised to store the resulting username and claim it for future use, to speed up the loading process. Due to the way that user creation works, it's now possible to listen for `post_save` signal for a user and check if it corresponds to a `ServiceAccount`. This means we can avoid auto-adding new service accounts to licenses. Once a `ServiceAccount` is registered, both the user and an API token can be accessed for use. This will use a client API token, identifying the token as being owned by this `ServiceAccount`, and with a minimum validity window of 5 hours (meaning if an existing token is found that has less time than this, a new token will be created to help avoid integration issues). If profile or API token state needs to be forcefully updated, the extension can bump one of the two version fields (one for profile, one for token information), which will force an update. A User Details Provider now exists to badge service accounts with "Service Account", so that they can be easily distinguished whenever they might be shown.	0cf5bb955484cac5c4945dc632169feefb23427c

Diff:

Revision 2 (+4392 -4)

Show changes

	docs/manual/extending/coderef/index.rst
	reviewboard/accounts/service_accounts.py
	reviewboard/accounts/user_details.py
	reviewboard/accounts/tests/test_service_account.py
	reviewboard/accounts/tests/test_service_account_registry.py
	reviewboard/extensions/hooks/__init__.py
	reviewboard/extensions/hooks/users.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Fix it!

reviewboard/accounts/service_accounts.py (Diff revision 2)

An issue was opened. Show all issues

This is assigned None but never read. Were you intending on using this as a cache in get_api_token()?

If you keep it, it should be listed in # Instance variables too.

reviewboard/accounts/service_accounts.py (Diff revision 2)
An issue was opened. Show all issues
```
Typo: thaat -> that
```

reviewboard/accounts/service_accounts.py (Diff revision 2)

An issue was opened. Show all issues

If two services want the same username ("bot" for example), this will stomp over an existing one.

We should check if claim_map.get(username) is not either None or self, and skip if so.

This situation should get a unit test two.

reviewboard/accounts/service_accounts.py (Diff revision 2)
An issue was opened. Show all issues
```
Typo: Pleaase -> Please
```
reviewboard/accounts/service_accounts.py (Diff revision 2)
An issue was opened. Show all issues
```
I don't see how profile could be falsy at this point.
```

reviewboard/accounts/service_accounts.py (Diff revision 2)

An issue was opened. Show all issues

__init__ already defauts self.email to be mail_default_from, so the contents of this block are an unreachable duplicate of what we already have done.

reviewboard/accounts/service_accounts.py (Diff revision 2)

An issue was opened. Show all issues

last_name is a CharField(blank=True, null=False). Having None here works okay for sqlite but will fail on MySQL and Postgres.

reviewboard/accounts/tests/test_service_account.py (Diff revision 2)
An issue was opened. Show all issues
```
minimum subclass -> minimum init
```

reviewboard/accounts/tests/test_service_account.py (Diff revision 2)

An issue was opened. Show all issues

should mention subclass here (right now this has the same docstring as test_init_with_override_all)

reviewboard/accounts/tests/test_service_account_registry.py (Diff revision 2)
An issue was opened. Show all issues
```
Should be ServiceAccountRegistry
```