[feature:gsoc26] Link Command execution history to MassCommand history and execution tracking

[dee077]

Is your feature request related to a problem? Please describe.

Currently, each command execution is stored independently in the Command model, but there is no relationship between individual command executions and the mass operation that triggered them.
With the introduction of mass command execution, multiple Command objects will be created as part of a single MassCommand operation. Without an explicit relationship between these models, it would not be possible to identify from the device command history whether a command was executed individually or as part of a mass operation.

Describe the solution I would implement

I would like to add a relationship between Command and MassCommand by introducing a nullable foreign key in AbstractCommand.

mass_command = models.ForeignKey(
    get_model_name("connection", "MassCommand"),
    null=True,
    blank=True,
    on_delete=models.SET_NULL,
)

1. Add a nullable mass_command foreign key field to AbstractCommand so that commands created as part of a batch operation can reference their parent MassCommand.
2. Commands executed individually through the existing single-device workflow will continue to have this field set to NULL.
3. On the device detail page, the command history should indicate whether a command was executed as part of a mass operation.
4. If a command belongs to a MassCommand, the UI should provide a link to the corresponding mass command execution result page, allowing administrators to navigate directly to the parent batch operation.

Details to preserve during implementation

The device detail page integration should explicitly cover the Recent Commands section mentioned in the proposal. Commands created by a MassCommand should be visible there with enough context to show they belong to a parent mass operation.

The deletion behavior should be coordinated with the REST API and lifecycle work in #1349. The currently proposed on_delete=models.SET_NULL preserves child Command records but removes the parent link if the MassCommand is deleted. Possible approaches to investigate include allowing deletion and losing the parent link, protecting MassCommand deletion while child commands exist, soft-deleting or archiving MassCommand records, or another lifecycle rule that preserves traceability.

Automated tests should cover the nullable mass_command relation, single-device commands keeping this field set to NULL, command history rendering, and navigation from a command history entry to the parent MassCommand when applicable.

[nemesifier]

Updated the issue body to preserve the traceability details from the proposal review.

Summary of changes:

• Added an explicit reference to the device detail Recent Commands section.
• Clarified that commands created through a MassCommand should show enough context to identify the parent operation.
• Added deletion and lifecycle behavior as an open investigation point to coordinate with [feature:gsoc26] Add REST API for mass command execution and operation management #1349.
• Listed possible approaches for deletion and traceability, including SET_NULL, protected deletion, soft deletion, archival behavior, or another lifecycle rule.
• Added automated test coverage notes for the nullable relation, single-device commands with NULL, command history rendering, and navigation to the parent MassCommand.

To review the body edits, open this issue, navigate to the top bar of the issue, click last edited by nemesifier, then click most recent in the edit history dialog. Unfortunately there is not a quick URL to share for this.