Fixes #21357: Add API for registering custom model actions

[jnovinger]

Fixes: #21357

Adds register_model_actions() API allowing plugins and core to register custom permission actions that appear as checkboxes in ObjectPermissionForm.

Changes:

• Add model_actions registry store
• Add ModelAction dataclass and register_model_actions() function in utilities.permissions
• Add ObjectTypeSplitMultiSelectWidget with data attributes for JS targeting
• Add RegisteredActionsWidget for rendering grouped action checkboxes
• Update ObjectPermissionForm with consolidated Actions fieldset
• Add JavaScript to show/hide actions based on selected object types
• Register core actions: DataSource.sync, Device.render_config, VirtualMachine.render_config
• Add unit tests for ModelAction and register_model_actions

Plugin usage:

# In plugin's apps.py ready() method
from utilities.permissions import ModelAction, register_model_actions
from .models import MyModel

register_model_actions(MyModel, [
    ModelAction('custom_action', help_text='Description of the action'),
])

Testing instructions:

1. Navigate to Admin > Permissions > Object Permissions > Add
2. In the "Object types" field, select models that have registered actions:
   • Data Source (Core)
   • Device (DCIM)
   • Virtual Machine (Virtualization)
3. Observe the "Custom actions" section appears with checkboxes grouped by model
4. Remove all models with registered actions - the "Custom actions" field should hide completely
5. Select a mix of models with and without registered actions - only applicable action groups should show

[jnovinger]

One Remaining Minor Item

UX: action names display as raw identifiers

netbox/utilities/templates/widgets/registered_actions.html:15

The checkbox label renders action.name directly (e.g. render_config, sync). Compare to NetBox's standard CRUD checkboxes which use proper labels ("View", "Add", etc.).

{{ action.name }}   {# Renders as "render_config" #}

ModelAction already has a help_text field for supplementary description, but no verbose_name for a display-friendly primary label.

This feels like scope creep to me. Let's tie it off here and revisit with a followup issue if needed.

[jeremystretch]

The UI is a little scattered IMO: It's not made clear to the user the differences among actions, custom actions, and additional actions.

Instead of dynamically adding/removing custom actions based on the selected objects, what do you think about starting by showing checkboxes for all available actions (both built-in and custom), and merely enabling/disabling them based on the selected objects? This would simplify the UI considerably, and it looks like you have the bulk of the necessary scripting in place already.

We should also extend the help text of the "additional actions" field to clarify that it is needed only when dealing with plugins which don't yet register their actions.

[jeremystretch]

If we determine that it's feasible to declare permissions on each model directly, we can probably move this logic into register_models().

[jnovinger]

Just saw the merge conflicts, fixing those now.

[jnovinger]

This is ready for review now, as soon as CI finishes.

[jeremystretch]

To clarify my earlier suggestion, let's consolidate these into a single list. Users don't know or care that a particular action is "custom" so there's no need to separate them out.

It's also a little confusing to list duplicate actions, e.g. render_config. There's no significant different between them: So long as the render_config action is present for an ObjectPermission, it doesn't matter which model it came from.

[jnovinger]

Claude finished @jnovinger's task in 3m 53s —— View job

Review

...

Another round:

• Admin docs still referenced "Custom actions" and "grouped by model"; updated to reflect the flat "Registered actions" layout
• "Registered actions" label intentionally omitted from the form since the fieldset is already titled "Actions"
• Raw model keys in the detail view (e.g. dcim.device) left as-is; not something Jeremy asked for
• clean() now collects all validation errors before raising instead of stopping at the first
• This one is wrong, help_text is already displayed.
• Double-click path for moving options is out of scope; the existing .move-option listener covers the supported interaction

[jeremystretch]

While the UI functionality is pretty slick, I'm afraid there's way too much logic baked into the form and widgets to justify it. There's too much going on in the frontend for me to even review in a reasonable amount of time.

In the interest of moving this forward, I'm going to suggest a different approach: Rip out the fancy UI bits and just implement a regular form with a checkbox for each available permission. (Don't worry about enabling/disabling them dynamically.) IMO that's plenty sufficient to meet the needs of FR #21357. We can always revisit the advanced functionality at a later date, after the upcoming v4.6 release.

[jeremystretch]

Can we rename these migrations to something like foo_x_permission?

[jeremystretch]

Can we move these validation checks into ModelAction itself to ensure they're always applied?

class ModelAction:
    def __post_init__(self):
        if not self.name:
            raise ValueError("Action name must not be empty.")
        if self.name in RESERVED_ACTIONS:
            raise ValueError(f"'{action.name}' is a reserved action and cannot be registered.")

[jeremystretch]

We can skip this check if we change registry['model_actions'] to defaultdict(set).

[jeremystretch]

Suggest dropping the model name from these to avoid confusion in the UI.

Suggested change

	('render_config', 'Render device configuration'),
	('render_config', 'Render configuration'),

[jeremystretch]

Suggested change

	('render_config', 'Render VM configuration'),
	('render_config', 'Render configuration'),

[jeremystretch]

This seems like a lot of logic to bake into a UI panel. Suggest moving the logic for resolving registered actions to the ObjectPermission class.

[jeremystretch]

This seems like it's getting out-of-hand. We should avoid creating custom widgets for specific fields. This splits off from the original SplitMultiSelectWidget class, which is now unused.