Summary

Add formal support for service accounts.

Review Request #15105 — Created June 7, 2026 and updated June 25, 2026, 1:15 a.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.	adaf6c43101922556356b290e1c5f5fa47d76fce

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.

adaf6c43101922556356b290e1c5f5fa47d76fce

Issues

Description	From	Last Updated
local variable 'user' is assigned to but never used Column: 13 Error code: F841	reviewbot	June 7, 2026, 4:12 a.m.
'datetime.timedelta' imported but unused Column: 1 Error code: F401	reviewbot	June 7, 2026, 4:13 a.m.
'django.utils.timezone' imported but unused Column: 1 Error code: F401	reviewbot	June 7, 2026, 4:13 a.m.
line too long (88 > 79 characters) Column: 80 Error code: E501	reviewbot	June 7, 2026, 4:13 a.m.
redefinition of unused 'Iterator' from line 11 Column: 5 Error code: F811	reviewbot	June 7, 2026, 4: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 10, 2026, 11:53 p.m.
Typo: thaat -> that	david	June 10, 2026, 11:54 p.m.
If two services want the same username ("bot" for example), this will stomp over an existing one. We should check …	david	June 25, 2026, 12:40 a.m.
Typo: Pleaase -> Please	david	June 10, 2026, 11:55 p.m.
I don't see how profile could be falsy at this point.	david	June 10, 2026, 11:55 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 10, 2026, 11:56 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 10, 2026, 11:58 p.m.
minimum subclass -> minimum init	david	June 10, 2026, 11:58 p.m.
should mention subclass here (right now this has the same docstring as test_init_with_override_all)	david	June 10, 2026, 11:58 p.m.
Should be ServiceAccountRegistry	david	June 10, 2026, 11:58 p.m.
We can probably remove this since we're logging this error path in get_user() already.	maubin	June 24, 2026, 9:29 p.m.
This should be ServiceAccountUserError now.	maubin	June 25, 2026, 1:15 a.m.
This docs page isn't included in the change.	maubin	June 24, 2026, 9:34 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.

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

The issue has been resolved. 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.

chipx86

June 11, 2026, 12:04 a.m.
```
Leftover code. Removing.
```

reviewboard/accounts/service_accounts.py (Diff revision 2)
The issue has been resolved. Show all issues
```
Typo: thaat -> that
```

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

The issue has been resolved. 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.

chipx86

June 11, 2026, 12:04 a.m.

I'm trying to figure out the resolution to this.

Claiming is there for the situation where a username has been verified to be owned by that service already. So, if two service accounts claim the same username, there's a problem. We probably should not skip and try again. I'm thinking it should be a fatal error.

reviewboard/accounts/service_accounts.py (Diff revision 2)
The issue has been resolved. Show all issues
```
Typo: Pleaase -> Please
```
1. chipx86
  
  June 11, 2026, 12:04 a.m.
  Removes the begging
reviewboard/accounts/service_accounts.py (Diff revision 2)
The issue has been resolved. Show all issues
```
I don't see how profile could be falsy at this point.
```
1. chipx86
  
  June 11, 2026, 12:04 a.m.
  Leftover from older code.

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

The issue has been resolved. 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.

chipx86

June 11, 2026, 12:04 a.m.
```
Good catch. Leftover from older code.
```

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

The issue has been resolved. 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)
The issue has been resolved. Show all issues
```
minimum subclass -> minimum init
```
reviewboard/accounts/tests/test_service_account.py (Diff revision 2)
The issue has been resolved. 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)
The issue has been resolved. Show all issues
```
Should be ServiceAccountRegistry
```

Change Summary:


An attempt to claim an already-claimed user will no longer stomp over the claim state.
A default is now set for email if it's provided but empty.
Removed unused and duplicate code from an earlier implementation.
Fixed typos and docstrings.

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
	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.	4fbe059acef989b77f8bb499ed5e01ccd89edc8e

Diff:

Revision 3 (+4486 -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.

Ok nice this makes sense to me and looks like a good approach.

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

The issue has been resolved. Show all issues

We can probably remove this since we're logging this error path in get_user() already.

chipx86

June 24, 2026, 9:30 p.m.
```
Leftover from some debugging. Removed.
```

reviewboard/extensions/hooks/users.py (Diff revision 3)
The issue has been dropped. Show all issues
```
This docs page isn't included in the change.
```
1. chipx86
  
  June 24, 2026, 9:30 p.m.
  Haven't written it yet. It's more of a placeholder.

Ship it!

```
Ship It!
```

Change Summary:


Added an immediate failure if a claimed username is already claimed by another ServiceAccount.
Switched the error type to ServiceAccountUserError.
Removed leftover debug code.

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.	4fbe059acef989b77f8bb499ed5e01ccd89edc8e
	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.	adaf6c43101922556356b290e1c5f5fa47d76fce

Diff:

Revision 4 (+4608 -4)

Show changes

	docs/manual/extending/coderef/index.rst
	reviewboard/accounts/errors.py
	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 revisions 3 - 4)
An issue was opened. Show all issues
```
This should be ServiceAccountUserError now.
```