Summary

Add new dedicated classes for handling action rendering.

Review Request #14659 — Created Oct. 29, 2025 and submitted Nov. 14, 2025, 5:08 p.m.

Information

Owner

chipx86

Repository

Review Board

Branch

release-7.1.x

Bugs

Depends On

Reviewers

Groups

reviewboard

People

Description

We only had basic forms of menu and menu item actions at that time, but
as we adopt actions for more parts of the UI (including page navigation
soon) that can show up in multiple places, we've needed a more flexible
approach.

Now, actions provide the metadata and, client-side, activation logic
(implemented in a former change), and rendering is handled by a separate
set of renderer classes. These are responsible for taking a registered
action and turning it into a UI representation server-side. These may be
buttons, menus, menu items, sidebar items, or something specialized for
any part of the UI.

Renderers don't need to be registered anywhere. They can be created and
then set as either the default for an action, or passed explicitly
during action rendering, which will yield new HTML/JavaScript for that
action's view.

Compatibility with existing action-driven rendering is still provided,
but deprecated and will be removed in Review Board 9. As of this change,
such actions are still using the legacy behavior, in part to aid in
testing this compatibility. These will be updated in another change.

This is a precursor to change that will provide defaults for different
areas on a page, which will make it even easier to reuse actions across
a page.

Testing Done

Unit tests passed.

Tested all actions used in the UI, making sure they rendered and
activated correctly.

Commits

Summary	ID
Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	e48a6ac154ef9ea95b016d774eb921d8b0f87df0

Summary

Add new dedicated classes for handling action rendering.

When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.

e48a6ac154ef9ea95b016d774eb921d8b0f87df0

Files

Issues

Description	From	Last Updated
Typo: renderes	maubin	Nov. 7, 2025, 12:48 a.m.
Typo: renderes -> renderers	david	Nov. 7, 2025, 2:34 p.m.
I wrote a similar message using the class name recently, but I used self.__class__.__name__. Is one better than the other?	maubin	Nov. 7, 2025, 2:31 p.m.
Just to be a little more defensive, can we do if not issubclass(renderer_cls, BaseActionRenderer)?	david	Nov. 7, 2025, 2:44 p.m.
Same here.	david	Nov. 7, 2025, 2:44 p.m.
Can you add a raises section in the docstring for this.	maubin	Nov. 7, 2025, 2:33 p.m.
Can we alphabetize these.	maubin	Nov. 7, 2025, 2:34 p.m.
Should we annotate these as ClassVar[]?	david	Nov. 7, 2025, 2:45 p.m.
Shouldn't this be :py:meth instead of :js:meth?	maubin	Nov. 7, 2025, 2:34 p.m.
We shouldn't need to repeat the typing on this.	david	Nov. 7, 2025, 2:45 p.m.
We shouldn't need to repeat the typing on this.	david	Nov. 7, 2025, 2:45 p.m.
TypeError is probably more appropriate. This is a developer-facing error that doesn't need localization.	david	Nov. 7, 2025, 2:46 p.m.
'django.utils.translation.gettext as _' imported but unused Column: 1 Error code: F401	reviewbot	Nov. 7, 2025, 6:11 p.m.

flake8 passed.

JSHint passed.

Change Summary:


Fixed the push/pop state when updating template contexts.
Fixed unit test issues found due to the above fix. Actions are now registered before render in tests.
Fixed some test suite names.

Testing Done:

	+	Unit tests passed.
	+
	+	Tested all actions used in the UI, making sure they rendered and
	+	activated correctly.

Commits:

	Summary	ID
	Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	eddf5de125e22d0fe625e142825869894b71315e
	Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	a51d8886715bb04a681c3290fd8387eb3f398dde

Diff:

Revision 2 (+4002 -148)

Show changes

	docs/manual/extending/coderef/index.rst
	reviewboard/actions/base.py
	reviewboard/actions/renderers.py
	reviewboard/actions/templatetags/actions.py
	reviewboard/actions/tests/base.py
	reviewboard/actions/tests/test_base_action.py
	reviewboard/actions/tests/test_base_action_renderer.py
	reviewboard/actions/tests/test_button_action_renderer.py
	10 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:


Fixed the compatibility shims for old-style actions.
Pre-populated the registry for the action hooks tests so that the temporary renderer warnings won't affect warning assertions.

Commits:

	Summary	ID
	Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	a51d8886715bb04a681c3290fd8387eb3f398dde
	Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	be7b9ebac56f069961667eaa280152339068b25a

Diff:

Revision 3 (+4026 -156)

Show changes

	docs/manual/extending/coderef/index.rst
	reviewboard/actions/base.py
	reviewboard/actions/renderers.py
	reviewboard/actions/templatetags/actions.py
	reviewboard/actions/tests/base.py
	reviewboard/actions/tests/test_base_action.py
	reviewboard/actions/tests/test_base_action_renderer.py
	reviewboard/actions/tests/test_button_action_renderer.py
	12 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

```
Looks solid!
```
reviewboard/actions/base.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Typo: renderes
```

reviewboard/actions/base.py (Diff revision 3)

The issue has been dropped. Show all issues

I wrote a similar message using the class name recently, but I used self.__class__.__name__. Is one better than the other?

chipx86 Nov. 7, 2025, 2:27 p.m.

In this particular case, no. It used to matter more in Python 2. That said, type() is probably usually the more correct answer (but in practice either is generally fine).
type() reaches into the Python type system rather than doing an attribute lookup. You can actually override __class__, since it goes through the standard attribute lookup path. But even if you do, type() will give the right answer. For example:

>>> class A:
...   __class__ = 'Foo'
...
>>> a = A()
>>> a.__class__
'Foo'
>>> type(a)
<class '__main__.A'>

reviewboard/actions/base.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Can you add a raises section in the docstring for this.
```

reviewboard/actions/base.py (Diff revision 3)

The issue has been dropped. Show all issues

Can we alphabetize these.

chipx86 Nov. 7, 2025, 6:11 p.m.

Don't worry about this for now. This whole class is going away. This change here is just temporary.

reviewboard/actions/renderers.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Shouldn't this be :py:meth instead of :js:meth?
```

reviewboard/actions/base.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Typo: renderes -> renderers
```

reviewboard/actions/base.py (Diff revision 3)

The issue has been resolved. Show all issues

Just to be a little more defensive, can we do if not issubclass(renderer_cls, BaseActionRenderer)?

reviewboard/actions/base.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Same here.
```

reviewboard/actions/renderers.py (Diff revision 3)

The issue has been resolved. Show all issues

Should we annotate these as ClassVar[]?

reviewboard/actions/renderers.py (Diff revision 3)

The issue has been dropped. Show all issues

We shouldn't need to repeat the typing on this.

chipx86 Nov. 7, 2025, 6:11 p.m.

We do. If we don't, subclasses are restricted to MenuItemActionRenderer or a subclass of it. I hit this with the Quick Access implementation initially (we had to redefine the types) and hit this again with this change.

reviewboard/actions/renderers.py (Diff revision 3)
The issue has been dropped. Show all issues
```
We shouldn't need to repeat the typing on this.
```

reviewboard/actions/templatetags/actions.py (Diff revision 3)

The issue has been resolved. Show all issues

TypeError is probably more appropriate.

This is a developer-facing error that doesn't need localization.

Change Summary:


Fixed some doc issues.
Introduced a new MissingActionRendererError class and made use of it.
Made class attributes ClassVars.
Added issubclass checks to ensure a proper renderer is set.

Commits:

	Summary	ID
	Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	be7b9ebac56f069961667eaa280152339068b25a
	Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	5782c87f553f6664f3e7597cb008dae1e3b2d916

Diff:

Revision 4 (+4088 -162)

Show changes

	docs/manual/extending/coderef/index.rst
	reviewboard/actions/base.py
	reviewboard/actions/errors.py
	reviewboard/actions/renderers.py
	reviewboard/actions/templatetags/actions.py
	reviewboard/actions/tests/base.py
	reviewboard/actions/tests/test_base_action.py
	reviewboard/actions/tests/test_base_action_renderer.py
	13 more

Checks run (1 failed, 1 succeeded)

flake8 failed.

JSHint passed.

flake8

reviewboard/actions/templatetags/actions.py (Diff revision 4)
The issue has been resolved. Show all issues
```
'django.utils.translation.gettext as _' imported but unused

Column: 1
Error code: F401
```

Ship it!

```
Ship It!
```

Ship it!

```
Ship It!
```

Change Summary:

Updated unit tests affected by updates to prior changes.

Commits:

	Summary	ID
	Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	5782c87f553f6664f3e7597cb008dae1e3b2d916
	Add new dedicated classes for handling action rendering. When actions were first built, we had a one-to-one mapping of action class to UI representation. This changed with the introduction of the Quick Access actions, which required duplicating and specializing actions. We only had basic forms of menu and menu item actions at that time, but as we adopt actions for more parts of the UI (including page navigation soon) that can show up in multiple places, we've needed a more flexible approach. Now, actions provide the metadata and, client-side, activation logic (implemented in a former change), and rendering is handled by a separate set of renderer classes. These are responsible for taking a registered action and turning it into a UI representation server-side. These may be buttons, menus, menu items, sidebar items, or something specialized for any part of the UI. Renderers don't need to be registered anywhere. They can be created and then set as either the default for an action, or passed explicitly during action rendering, which will yield new HTML/JavaScript for that action's view. Compatibility with existing action-driven rendering is still provided, but deprecated and will be removed in Review Board 9. As of this change, such actions are still using the legacy behavior, in part to aid in testing this compatibility. These will be updated in another change. This is a precursor to change that will provide defaults for different areas on a page, which will make it even easier to reuse actions across a page.	e48a6ac154ef9ea95b016d774eb921d8b0f87df0

Diff:

Revision 5 (+4114 -162)

Show changes

	docs/manual/extending/coderef/index.rst
	reviewboard/actions/base.py
	reviewboard/actions/errors.py
	reviewboard/actions/renderers.py
	reviewboard/actions/templatetags/actions.py
	reviewboard/actions/tests/base.py
	reviewboard/actions/tests/test_base_action.py
	reviewboard/actions/tests/test_base_action_renderer.py
	13 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to release-7.1.x (15243f0)