Summary

Add flexible placement of actions in attachment points, with options.

Review Request #14675 — Created Nov. 6, 2025 and submitted Nov. 28, 2025, 9:47 p.m.

Information

Owner

chipx86

Repository

Review Board

Branch

release-7.1.x

Bugs

Depends On

Reviewers

Groups

reviewboard

People

Description

This is the last piece of the core actions rewrite to enable multiple
views for the same actions.

Instead of assigning a single attachment point and parent ID to an
action, zero or more placements can now be assigned. A placement is an
ActionPlacement instance that sets:

The attachment point to render into
An optional parent action ID
An optional default renderer
An optional DOM element ID

This enables an action to (for example) be parented to a menu or another
group in one attachment point, and then a button or some other render in
another group.

Actions no longer fail to register when a placement fails. That is, if
an action is too deeply nested in one placement, it will still register,
since it can still be used in another (even if registered later via a
future extension hook).

At this point, we have 4 core concepts comprising the action system:

Actions, which contains the core metadata and client-side
activation logic.
Action renderers, which render the HTML and JavaScript for an action
in a given attachment point.
Attachment Points, which are a location in which actions can be
placed, providing default renderers.
Placements, which define the Attachment Point configuration in which
an Action would be rendered, and options governing that rendering.

Testing Done

Unit tests pass.

Tested that all actions worked as expected, including with in-progress
changes to consolidate the actions used for Quick Access.

Commits

Summary	ID
Add flexible placement of actions in attachment points, with options. This is the last piece of the core actions rewrite to enable multiple views for the same actions. Instead of assigning a single attachment point and parent ID to an action, zero or more placements can now be assigned. A placement is an `ActionPlacement` instance that sets: 1. The attachment point to render into 2. An optional parent action ID 3. An optional default renderer 4. An optional DOM element ID This enables an action to (for example) be parented to a menu or another group in one attachment point, and then a button or some other render in another group. Actions no longer fail to register when a placement fails. That is, if an action is too deeply nested in one placement, it will still register, since it can still be used in another (even if registered later via a future extension hook). At this point, we have 4 core concepts comprising the action system: 1. Actions, which contains the core metadata and client-side activation logic. 2. Action renderers, which render the HTML and JavaScript for an action in a given attachment point. 3. Attachment Points, which are a location in which actions can be placed, providing default renderers. 4. Placements, which define the Attachment Point configuration in which an Action would be rendered, and options governing that rendering.	8e4203858cddfef3bde0c1a1a60691fe2de0fddd

Summary

Add flexible placement of actions in attachment points, with options.

This is the last piece of the core actions rewrite to enable multiple views for the same actions. Instead of assigning a single attachment point and parent ID to an action, zero or more placements can now be assigned. A placement is an `ActionPlacement` instance that sets: 1. The attachment point to render into 2. An optional parent action ID 3. An optional default renderer 4. An optional DOM element ID This enables an action to (for example) be parented to a menu or another group in one attachment point, and then a button or some other render in another group. Actions no longer fail to register when a placement fails. That is, if an action is too deeply nested in one placement, it will still register, since it can still be used in another (even if registered later via a future extension hook). At this point, we have 4 core concepts comprising the action system: 1. Actions, which contains the core metadata and client-side activation logic. 2. Action renderers, which render the HTML and JavaScript for an action in a given attachment point. 3. Attachment Points, which are a location in which actions can be placed, providing default renderers. 4. Placements, which define the Attachment Point configuration in which an Action would be rendered, and options governing that rendering.

8e4203858cddfef3bde0c1a1a60691fe2de0fddd

Issues

Description	From	Last Updated
These need to be added to "Args"	david	Nov. 10, 2025, 1:57 a.m.
This is a developer-facing error message that doesn't need localization.	david	Nov. 10, 2025, 1:58 a.m.
Can you mark the class as deprecated?	david	Nov. 10, 2025, 1:59 a.m.
Leftover debug output.	david	Nov. 10, 2025, 1:59 a.m.
'django.utils.translation.gettext as _' imported but unused Column: 1 Error code: F401	reviewbot	Nov. 10, 2025, 2:02 a.m.
local variable 'action_id' is assigned to but never used Column: 9 Error code: F841	reviewbot	Nov. 10, 2025, 2:02 a.m.

flake8 passed.

JSHint passed.

reviewboard/actions/base.py (Diff revision 1)
The issue has been resolved. Show all issues
```
These need to be added to "Args"
```

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

The issue has been resolved. Show all issues

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

reviewboard/actions/errors.py (Diff revision 1)
The issue has been resolved. Show all issues
```
Can you mark the class as deprecated?
```

reviewboard/actions/tests/test_action_attachment_point.py (Diff revision 1)

The issue has been resolved. Show all issues

Leftover debug output.

Change Summary:


Updated code affected by parent changes.
Removed leftover debug output.
Added missing docs.
Removed localization for developer-facing strings.
Marked DepthLimitExceededError as deprecated at runtime.

Commits:

	Summary	ID
	Add flexible placement of actions in attachment points, with options. This is the last piece of the core actions rewrite to enable multiple views for the same actions. Instead of assigning a single attachment point and parent ID to an action, zero or more placements can now be assigned. A placement is an `ActionPlacement` instance that sets: 1. The attachment point to render into 2. An optional parent action ID 3. An optional default renderer 4. An optional DOM element ID This enables an action to (for example) be parented to a menu or another group in one attachment point, and then a button or some other render in another group. Actions no longer fail to register when a placement fails. That is, if an action is too deeply nested in one placement, it will still register, since it can still be used in another (even if registered later via a future extension hook). At this point, we have 4 core concepts comprising the action system: 1. Actions, which contains the core metadata and client-side activation logic. 2. Action renderers, which render the HTML and JavaScript for an action in a given attachment point. 3. Attachment Points, which are a location in which actions can be placed, providing default renderers. 4. Placements, which define the Attachment Point configuration in which an Action would be rendered, and options governing that rendering.	1f90054969cc39e180cbdf2dbd6b7c7098bf1522
	Add flexible placement of actions in attachment points, with options. This is the last piece of the core actions rewrite to enable multiple views for the same actions. Instead of assigning a single attachment point and parent ID to an action, zero or more placements can now be assigned. A placement is an `ActionPlacement` instance that sets: 1. The attachment point to render into 2. An optional parent action ID 3. An optional default renderer 4. An optional DOM element ID This enables an action to (for example) be parented to a menu or another group in one attachment point, and then a button or some other render in another group. Actions no longer fail to register when a placement fails. That is, if an action is too deeply nested in one placement, it will still register, since it can still be used in another (even if registered later via a future extension hook). At this point, we have 4 core concepts comprising the action system: 1. Actions, which contains the core metadata and client-side activation logic. 2. Action renderers, which render the HTML and JavaScript for an action in a given attachment point. 3. Attachment Points, which are a location in which actions can be placed, providing default renderers. 4. Placements, which define the Attachment Point configuration in which an Action would be rendered, and options governing that rendering.	e28820232b046503a73a73b173f08f6d5992a66b

Diff:

Revision 2 (+1678 -470)

Show changes

	reviewboard/actions/__init__.py
	reviewboard/actions/base.py
	reviewboard/actions/errors.py
	reviewboard/actions/registry.py
	reviewboard/actions/renderers.py
	reviewboard/actions/templatetags/actions.py
	reviewboard/actions/tests/base.py
	reviewboard/actions/tests/test_action_attachment_point.py
	8 more

Checks run (1 failed, 1 succeeded)

flake8 failed.

JSHint passed.

flake8

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

The issue has been resolved. Show all issues

'django.utils.translation.gettext as _' imported but unused

Column: 1
Error code: F401

reviewboard/actions/registry.py (Diff revision 2)

The issue has been resolved. Show all issues

local variable 'action_id' is assigned to but never used

Column: 9
Error code: F841

Change Summary:


Removed an unused import.
Updated merged code to use an existing variable.

Commits:

	Summary	ID
	Add flexible placement of actions in attachment points, with options. This is the last piece of the core actions rewrite to enable multiple views for the same actions. Instead of assigning a single attachment point and parent ID to an action, zero or more placements can now be assigned. A placement is an `ActionPlacement` instance that sets: 1. The attachment point to render into 2. An optional parent action ID 3. An optional default renderer 4. An optional DOM element ID This enables an action to (for example) be parented to a menu or another group in one attachment point, and then a button or some other render in another group. Actions no longer fail to register when a placement fails. That is, if an action is too deeply nested in one placement, it will still register, since it can still be used in another (even if registered later via a future extension hook). At this point, we have 4 core concepts comprising the action system: 1. Actions, which contains the core metadata and client-side activation logic. 2. Action renderers, which render the HTML and JavaScript for an action in a given attachment point. 3. Attachment Points, which are a location in which actions can be placed, providing default renderers. 4. Placements, which define the Attachment Point configuration in which an Action would be rendered, and options governing that rendering.	e28820232b046503a73a73b173f08f6d5992a66b
	Add flexible placement of actions in attachment points, with options. This is the last piece of the core actions rewrite to enable multiple views for the same actions. Instead of assigning a single attachment point and parent ID to an action, zero or more placements can now be assigned. A placement is an `ActionPlacement` instance that sets: 1. The attachment point to render into 2. An optional parent action ID 3. An optional default renderer 4. An optional DOM element ID This enables an action to (for example) be parented to a menu or another group in one attachment point, and then a button or some other render in another group. Actions no longer fail to register when a placement fails. That is, if an action is too deeply nested in one placement, it will still register, since it can still be used in another (even if registered later via a future extension hook). At this point, we have 4 core concepts comprising the action system: 1. Actions, which contains the core metadata and client-side activation logic. 2. Action renderers, which render the HTML and JavaScript for an action in a given attachment point. 3. Attachment Points, which are a location in which actions can be placed, providing default renderers. 4. Placements, which define the Attachment Point configuration in which an Action would be rendered, and options governing that rendering.	8e4203858cddfef3bde0c1a1a60691fe2de0fddd

Diff:

Revision 3 (+1680 -474)

Show changes

	reviewboard/actions/__init__.py
	reviewboard/actions/base.py
	reviewboard/actions/errors.py
	reviewboard/actions/registry.py
	reviewboard/actions/renderers.py
	reviewboard/actions/templatetags/actions.py
	reviewboard/actions/tests/base.py
	reviewboard/actions/tests/test_action_attachment_point.py
	8 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to release-7.1.x (681765c)