chipx86 got a fish trophy!

Summary

Move action activation and state management into the action models.

Review Request #14641 — Created Oct. 18, 2025 and submitted Nov. 14, 2025, 5:06 p.m.

Information

Owner

chipx86

Repository

Review Board

Branch

release-7.1.x

Bugs

Depends On

Blocks

14642

Reviewers

Groups

reviewboard

People

Description

Actions didn't have a standard way to perform an activation of the
action. The menu item action views had an activate() method tied to a
click handler, and subclasses implemented that, but this wasn't a
capability of ActionView. Quick Access actions happened to get the
same activation support by inheriting the same view for menu items, even
though buttons were used for display (creating a potential future
issue by themselves).

As part of the work to centralize actions, Action now has an
activate() method, which performs the operation backed by the action.
Although these are models, this method is allowed to contain or call
UI/view code.

ActionView has been updated to have an official activate() method
for compatibility, which defaults to calling model.activate().
Subclasses can always override this to put in logic between the parent
class's call and the model's activation logic.

ActionView has also been updated to rely more on Action for
visibility management (newly added for Quick Access actions in 7.1),
so all views for an action will behave the same way.

The existing action views have largely been replaced with models, which
in upcoming changes will be better utilized for both standard and Quick
Access actions. The old views have been removed, and probably aren't
worth retaining for any kind of API compatibility.

Testing Done

Unit tests pass.

Tested every single action, making sure states were updated,
visibility was reflected, and actions were activated correctly.

Commits

Summary	ID
Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	1d6249e553fb942258a13d696db502316d9bb172

Summary

Move action activation and state management into the action models.

Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.

1d6249e553fb942258a13d696db502316d9bb172

Issues

Description	From	Last Updated
This is missing a docstring, and maybe its better to have the assert be something like "<classname> must implement getLabelForVisibility".	maubin	Oct. 21, 2025, 3:48 p.m.
This can be removed.	maubin	Oct. 21, 2025, 3:48 p.m.
This can be removed.	maubin	Oct. 21, 2025, 3:48 p.m.
Seems like leftover debug code.	maubin	Oct. 21, 2025, 3:48 p.m.
Shouldn't we be triggering closeError on the reviewRequestEditor instance instead of on the action? I know in the previous code …	maubin	Oct. 21, 2025, 7:52 p.m.
Do we want to explicitly list out the things exported here, in case we add additional things (i.e. attrs interfaces) …	david	Nov. 10, 2025, 3:56 p.m.
Can you add a file-level comment at the top?	david	Nov. 6, 2025, 3:08 a.m.
Given that this should never be called, can we make the method abstract?	david	Nov. 6, 2025, 3:08 a.m.
Typo here: getLabels -> getLabel	david	Nov. 6, 2025, 3:09 a.m.
This should be when there is an existing pending review.	david	Nov. 6, 2025, 3:10 a.m.
Copy/pasto: Action view -> Action	david	Nov. 6, 2025, 3:10 a.m.
Should be UpdateDiffActionView	david	Nov. 6, 2025, 3:11 a.m.
So I think the old implementation might have been wrong to start with, but nothing is listening to "closeError" on …	david	Nov. 6, 2025, 3:11 a.m.
Same here.	david	Nov. 6, 2025, 3:11 a.m.
We also don't have any error handling here in case the promise fails. We probably should show whatever error and …	david	Nov. 6, 2025, 3:11 a.m.
Some of our activate() methods are async, and some are not. I feel like we should standardize on all being …	david	Nov. 10, 2025, 3:37 a.m.
Since some model implementations are async, I feel like we should make this async as well and do await this.model.activate()	david	Nov. 10, 2025, 3:37 a.m.
Do we want a Version Changed here about this now being exported, and perhaps a note about how this is …	david	Nov. 10, 2025, 3:38 a.m.
Let's make this async and do await this.#pendingReview.save().	david	Nov. 10, 2025, 3:37 a.m.

flake8 passed.

JSHint passed.

Change Summary:

Removed debug output.

Commits:

	Summary	ID
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	4aa77ebc8b47d05b6e748e3574c5cad666aaf69b
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	aaaacc3ebd53cf6c93e658d1fac7d43fa898c04d

Diff:

Revision 2 (+1298 -1214)

Show changes

	reviewboard/reviews/actions.py
	reviewboard/static/rb/js/common/actions/models/actionModel.ts
	reviewboard/static/rb/js/common/actions/views/actionView.ts
	reviewboard/static/rb/js/common/actions/views/menuActionView.ts
	reviewboard/static/rb/js/common/models/userSessionModel.ts
	reviewboard/static/rb/js/reviews/index.ts
	reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts
	reviewboard/static/rb/js/reviews/views/reviewRequestActions.ts

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 2)

The issue has been resolved. Show all issues

This is missing a docstring, and maybe its better to have the assert be something like "<classname> must implement getLabelForVisibility".

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 2)

The issue has been resolved. Show all issues

This can be removed.

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 2)

The issue has been resolved. Show all issues

This can be removed.

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 2)

The issue has been resolved. Show all issues

Seems like leftover debug code.

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 2)

The issue has been dropped. Show all issues

Shouldn't we be triggering closeError on the reviewRequestEditor instance instead of on the action? I know in the previous code we were triggering this event on the action model, but I don't see how this gets bubbled up to ReviewRequestEditor which is the thing that actually listens to closeError events.

chipx86 Oct. 21, 2025, 3:50 p.m.

That is a very good point. Let me address that in its own change, since that's going to take some testing. I don't want to bury that in here.

maubin Oct. 21, 2025, 7:59 p.m.
```
Sounds good.
```

Change Summary:


Fixed the default label for the Archive/Mute actions.
Improved an assertion message.
Added a missing docstring.
Removed some old options doc strings.
Removed leftover debug code.

Commits:

	Summary	ID
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	aaaacc3ebd53cf6c93e658d1fac7d43fa898c04d
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	5efce448c830245f3ebd41bb3e97fdeb20b7deae

Diff:

Revision 3 (+1342 -1214)

Show changes

	reviewboard/reviews/actions.py
	reviewboard/static/rb/js/common/actions/models/actionModel.ts
	reviewboard/static/rb/js/common/actions/views/actionView.ts
	reviewboard/static/rb/js/common/actions/views/menuActionView.ts
	reviewboard/static/rb/js/common/models/userSessionModel.ts
	reviewboard/static/rb/js/reviews/index.ts
	reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts
	reviewboard/static/rb/js/reviews/views/reviewRequestActions.ts

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

reviewboard/static/rb/js/reviews/index.ts (Diff revision 3)

The issue has been resolved. Show all issues

Do we want to explicitly list out the things exported here, in case we add additional things (i.e. attrs interfaces) to this file later?

chipx86 Nov. 6, 2025, 3:15 a.m.

My two cents is that we should be avoiding consumers (extensions, etc.) having to know our file structure. We namespace our objects well, and I think anything worth exporting should be made available via the base packages. That's a large conversation though.

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)
The issue has been resolved. Show all issues
```
Can you add a file-level comment at the top?
```

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)

The issue has been resolved. Show all issues

Given that this should never be called, can we make the method abstract?

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)
The issue has been resolved. Show all issues
```
Typo here: getLabels -> getLabel
```
reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)
The issue has been resolved. Show all issues
```
This should be when there is an existing pending review.
```
reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)
The issue has been resolved. Show all issues
```
Copy/pasto: Action view -> Action
```
reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)
The issue has been resolved. Show all issues
```
Should be UpdateDiffActionView
```

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)

The issue has been dropped. Show all issues

So I think the old implementation might have been wrong to start with, but nothing is listening to "closeError" on this. I think we want to be doing reviewRequesEditor.trigger('closeError', err.message) here?

Or perhaps we want to think about more generic error handling across the board for actions?

chipx86 Nov. 6, 2025, 3:15 a.m.

This is all being redone in a separate change that makes all this much, much nicer. Michelle pointed out the same problem.

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)
The issue has been dropped. Show all issues
```
Same here.
```

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 3)

The issue has been dropped. Show all issues

We also don't have any error handling here in case the promise fails. We probably should show whatever error and set the button to non-busy.

chipx86 Nov. 6, 2025, 3:15 a.m.

A fix for this is included in the separate change.

Change Summary:


Fixed several doc issues.
Made BaseVisibilityAction and its getLabelForVisibility abstract.

Commits:

	Summary	ID
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	5efce448c830245f3ebd41bb3e97fdeb20b7deae
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	9f273d1e5282b7a5696a26bc2d723be0adb8823b

Diff:

Revision 4 (+1340 -1214)

Show changes

	reviewboard/reviews/actions.py
	reviewboard/static/rb/js/common/actions/models/actionModel.ts
	reviewboard/static/rb/js/common/actions/views/actionView.ts
	reviewboard/static/rb/js/common/actions/views/menuActionView.ts
	reviewboard/static/rb/js/common/models/userSessionModel.ts
	reviewboard/static/rb/js/reviews/index.ts
	reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts
	reviewboard/static/rb/js/reviews/views/reviewRequestActions.ts

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

reviewboard/static/rb/js/common/actions/models/actionModel.ts (Diff revision 4)

The issue has been dropped. Show all issues

Some of our activate() methods are async, and some are not. I feel like we should standardize on all being async, starting with the base class definition here.

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

I'm on board with this. Let me do it as a separate change, given how much code churn exists in follow-up changes at this point.

reviewboard/static/rb/js/common/actions/views/actionView.ts (Diff revision 4)

The issue has been dropped. Show all issues

Since some model implementations are async, I feel like we should make this async as well and do await this.model.activate()

reviewboard/static/rb/js/common/models/userSessionModel.ts (Diff revision 4)

The issue has been resolved. Show all issues

Do we want a Version Changed here about this now being exported, and perhaps a note about how this is exported from this file but does not get exported all the way to the global namespace?

reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts (Diff revision 4)

The issue has been dropped. Show all issues

Let's make this async and do await this.#pendingReview.save().

Change Summary:


Removed updates to MenuActionView that should have been in /r/14663/.
Added a Version Changed on StoredItems stating it's exported but stating the conditions.

Commits:

	Summary	ID
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	9f273d1e5282b7a5696a26bc2d723be0adb8823b
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	2ab02d97cca79c3ef2580543212794b062578492

Diff:

Revision 5 (+1346 -1212)

Show changes

	reviewboard/reviews/actions.py
	reviewboard/static/rb/js/common/actions/models/actionModel.ts
	reviewboard/static/rb/js/common/actions/views/actionView.ts
	reviewboard/static/rb/js/common/actions/views/menuActionView.ts
	reviewboard/static/rb/js/common/models/userSessionModel.ts
	reviewboard/static/rb/js/reviews/index.ts
	reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts
	reviewboard/static/rb/js/reviews/views/reviewRequestActions.ts

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Change Summary:

Updated index.ts to explicitly list the actions to export.

Commits:

	Summary	ID
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	2ab02d97cca79c3ef2580543212794b062578492
	Move action activation and state management into the action models. Actions didn't have a standard way to perform an activation of the action. The menu item action views had an `activate()` method tied to a click handler, and subclasses implemented that, but this wasn't a capability of `ActionView`. Quick Access actions happened to get the same activation support by inheriting the same view for menu items, even though buttons were used for display (creating a potential future issue by themselves). As part of the work to centralize actions, `Action` now has an `activate()` method, which performs the operation backed by the action. Although these are models, this method is allowed to contain or call UI/view code. `ActionView` has been updated to have an official `activate()` method for compatibility, which defaults to calling `model.activate()`. Subclasses can always override this to put in logic between the parent class's call and the model's activation logic. `ActionView` has also been updated to rely more on `Action` for visibility management (newly added for Quick Access actions in 7.1), so all views for an action will behave the same way. The existing action views have largely been replaced with models, which in upcoming changes will be better utilized for both standard and Quick Access actions. The old views have been removed, and probably aren't worth retaining for any kind of API compatibility.	1d6249e553fb942258a13d696db502316d9bb172

Diff:

Revision 6 (+1370 -1212)

Show changes

	reviewboard/reviews/actions.py
	reviewboard/static/rb/js/common/actions/models/actionModel.ts
	reviewboard/static/rb/js/common/actions/views/actionView.ts
	reviewboard/static/rb/js/common/actions/views/menuActionView.ts
	reviewboard/static/rb/js/common/models/userSessionModel.ts
	reviewboard/static/rb/js/reviews/index.ts
	reviewboard/static/rb/js/reviews/models/reviewRequestActionModels.ts
	reviewboard/static/rb/js/reviews/views/reviewRequestActions.ts

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to release-7.1.x (9fa122d)