Summary

Add registered action attachment points with rendering control.

Review Request #14667 — Created Nov. 3, 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 change builds upon that concept by introducing a formal
registration of attachment points. These provide a level of control for
the rendering and state of any actions placed within them, allowing, for
example, one attachment point to render actions as a list of links and
another to render those same actions as a list of buttons.

Each attachment point has a default renderer that's used if the action
being rendered doesn't specify its own default. The intended approach
going forward is to have actions only specify a renderer if they have a
strong need for certain rendering behavior, but to otherwise leave that
up to the parent action group, attachment point, or to the (coming soon)
placement configuration.

Attachment points may also specify a list of actions to directly
include, in the order included. These may be actions registered to this
attachment point, or they may not be. This allows an attachment point to
easily include a set of actions rendered under the attachment point's
control for special extension use cases.

Testing Done

Unit tests pass.

Tested all current actions in the UI. They all appear and behave as
expected.

Tested with in-progress changes that move Quick Access actions to this
new system, and verified they rendered as expected.

Commits

Summary	ID
Add registered action attachment points with rendering control. When actions were first introduced, an action could specify an attachment point that they wanted to render into. These were strings that corresponded to a template tag call, rendering all actions attached to that point at that location. This change builds upon that concept by introducing a formal registration of attachment points. These provide a level of control for the rendering and state of any actions placed within them, allowing, for example, one attachment point to render actions as a list of links and another to render those same actions as a list of buttons. Each attachment point has a default renderer that's used if the action being rendered doesn't specify its own default. The intended approach going forward is to have actions only specify a renderer if they have a strong need for certain rendering behavior, but to otherwise leave that up to the parent action group, attachment point, or to the (coming soon) placement configuration. Attachment points may also specify a list of actions to directly include, in the order included. These may be actions registered to this attachment point, or they may not be. This allows an attachment point to easily include a set of actions rendered under the attachment point's control for special extension use cases.	5de9b8a455d3bff272815ac9a52b0280cbc30486

Summary

Add registered action attachment points with rendering control.

When actions were first introduced, an action could specify an attachment point that they wanted to render into. These were strings that corresponded to a template tag call, rendering all actions attached to that point at that location. This change builds upon that concept by introducing a formal registration of attachment points. These provide a level of control for the rendering and state of any actions placed within them, allowing, for example, one attachment point to render actions as a list of links and another to render those same actions as a list of buttons. Each attachment point has a default renderer that's used if the action being rendered doesn't specify its own default. The intended approach going forward is to have actions only specify a renderer if they have a strong need for certain rendering behavior, but to otherwise leave that up to the parent action group, attachment point, or to the (coming soon) placement configuration. Attachment points may also specify a list of actions to directly include, in the order included. These may be actions registered to this attachment point, or they may not be. This allows an attachment point to easily include a set of actions rendered under the attachment point's control for special extension use cases.

5de9b8a455d3bff272815ac9a52b0280cbc30486

Issues

Description	From	Last Updated
line too long (85 > 79 characters) Column: 80 Error code: E501	reviewbot	Nov. 3, 2025, 2:52 p.m.
Should we enforce that the attachment_point_id can only be one of the values in AttachmentPoint, for security purposes? This is …	maubin	Nov. 10, 2025, 3:21 a.m.

flake8 failed.

JSHint passed.

flake8

reviewboard/actions/tests/test_base_action.py (Diff revision 1)
The issue has been resolved. Show all issues
```
line too long (85 > 79 characters)

Column: 80
Error code: E501
```

Change Summary:

Fixed a line length issue.

Commits:

	Summary	ID
	Add registered action attachment points with rendering control. When actions were first introduced, an action could specify an attachment point that they wanted to render into. These were strings that corresponded to a template tag call, rendering all actions attached to that point at that location. This change builds upon that concept by introducing a formal registration of attachment points. These provide a level of control for the rendering and state of any actions placed within them, allowing, for example, one attachment point to render actions as a list of links and another to render those same actions as a list of buttons. Each attachment point has a default renderer that's used if the action being rendered doesn't specify its own default. The intended approach going forward is to have actions only specify a renderer if they have a strong need for certain rendering behavior, but to otherwise leave that up to the parent action group, attachment point, or to the (coming soon) placement configuration. Attachment points may also specify a list of actions to directly include, in the order included. These may be actions registered to this attachment point, or they may not be. This allows an attachment point to easily include a set of actions rendered under the attachment point's control for special extension use cases.	6e1f150b44753d75d5c24bf01abb9964f07f041d
	Add registered action attachment points with rendering control. When actions were first introduced, an action could specify an attachment point that they wanted to render into. These were strings that corresponded to a template tag call, rendering all actions attached to that point at that location. This change builds upon that concept by introducing a formal registration of attachment points. These provide a level of control for the rendering and state of any actions placed within them, allowing, for example, one attachment point to render actions as a list of links and another to render those same actions as a list of buttons. Each attachment point has a default renderer that's used if the action being rendered doesn't specify its own default. The intended approach going forward is to have actions only specify a renderer if they have a strong need for certain rendering behavior, but to otherwise leave that up to the parent action group, attachment point, or to the (coming soon) placement configuration. Attachment points may also specify a list of actions to directly include, in the order included. These may be actions registered to this attachment point, or they may not be. This allows an attachment point to easily include a set of actions rendered under the attachment point's control for special extension use cases.	fabb28da5483021491c6da757504b8007109a7b6

Diff:

Revision 2 (+1612 -82)

Show changes

	reviewboard/actions/__init__.py
	reviewboard/actions/base.py
	reviewboard/actions/registry.py
	reviewboard/actions/templatetags/actions.py
	reviewboard/actions/tests/base.py
	reviewboard/actions/tests/test_action_attachment_point.py
	reviewboard/actions/tests/test_base_action.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

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

The issue has been dropped. Show all issues

Should we enforce that the attachment_point_id can only be one of the values in AttachmentPoint, for security purposes? This is related to my comment on /r/14663, what if an action author wants to set the ID to something malicious.
I guess we do have the check in the actions_html tag where we return an empty string for actions that aren't registered, maybe that's enough safe guarding? I also can't really tell where we register all the aciton attachment points though, do we only register the default values?

chipx86 Nov. 10, 2025, 1:51 a.m.

Attachment points aren't restricted to prebuilt locations. Part of this is to allow an extension to define their own attachment point and add actions to it, so they can utilize the same machinery.

If people have unvetted malicious extensions running on their server, they're already in major trouble.

There's a new registry that registers the attachment points. We register the defaults but new ones can be registered.

chipx86 Nov. 10, 2025, 1:53 a.m.

registry.py, ActionAttachmentPointsRegistry.get_defaults() returns an instance for each default one.

Ship it!

```
Ship It!
```

Change Summary:

Updated unit tests based on changes to parent commits.

Commits:

	Summary	ID
	Add registered action attachment points with rendering control. When actions were first introduced, an action could specify an attachment point that they wanted to render into. These were strings that corresponded to a template tag call, rendering all actions attached to that point at that location. This change builds upon that concept by introducing a formal registration of attachment points. These provide a level of control for the rendering and state of any actions placed within them, allowing, for example, one attachment point to render actions as a list of links and another to render those same actions as a list of buttons. Each attachment point has a default renderer that's used if the action being rendered doesn't specify its own default. The intended approach going forward is to have actions only specify a renderer if they have a strong need for certain rendering behavior, but to otherwise leave that up to the parent action group, attachment point, or to the (coming soon) placement configuration. Attachment points may also specify a list of actions to directly include, in the order included. These may be actions registered to this attachment point, or they may not be. This allows an attachment point to easily include a set of actions rendered under the attachment point's control for special extension use cases.	fabb28da5483021491c6da757504b8007109a7b6
	Add registered action attachment points with rendering control. When actions were first introduced, an action could specify an attachment point that they wanted to render into. These were strings that corresponded to a template tag call, rendering all actions attached to that point at that location. This change builds upon that concept by introducing a formal registration of attachment points. These provide a level of control for the rendering and state of any actions placed within them, allowing, for example, one attachment point to render actions as a list of links and another to render those same actions as a list of buttons. Each attachment point has a default renderer that's used if the action being rendered doesn't specify its own default. The intended approach going forward is to have actions only specify a renderer if they have a strong need for certain rendering behavior, but to otherwise leave that up to the parent action group, attachment point, or to the (coming soon) placement configuration. Attachment points may also specify a list of actions to directly include, in the order included. These may be actions registered to this attachment point, or they may not be. This allows an attachment point to easily include a set of actions rendered under the attachment point's control for special extension use cases.	5de9b8a455d3bff272815ac9a52b0280cbc30486

Diff:

Revision 3 (+1612 -82)

Show changes

	reviewboard/actions/__init__.py
	reviewboard/actions/base.py
	reviewboard/actions/registry.py
	reviewboard/actions/templatetags/actions.py
	reviewboard/actions/tests/base.py
	reviewboard/actions/tests/test_action_attachment_point.py
	reviewboard/actions/tests/test_base_action.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to release-7.1.x (2b2587b)