Fix multiple downtime deletion permission issue

[Copilot]

Users with icingadb/command/downtime/* permission were unable to delete multiple downtimes, receiving "No permission for icingadb/command/downtime/delete" error despite having the required permissions.

Problem

When attempting to delete multiple downtimes from the Downtimes view, users would get a permission error even though they had the icingadb/command/downtime/* permission which should cover downtime deletion:

The audit log would show the permission was granted but the deletion still failed:

Root Cause

The issue was in the DowntimesController::fetchCommandTargets() method. When deleting multiple downtimes, this method returned a Query object, which triggered the bulk permission check via isGrantedOnType(). This bulk check failed because it couldn't properly validate permissions on the underlying host/service objects that the downtimes belong to.

Solution

Changed fetchCommandTargets() to return an array instead of a Query. This forces the system to use individual permission checks via isGrantedOn() for each downtime, which properly validates permissions on the underlying host/service objects.

Key Changes

• Modified fetchCommandTargets() return type from Query to array
• Added iterator_to_array($downtimes) to convert query results to array
• Added explanatory comments documenting the reasoning

Technical Details

When fetchCommandTargets() returns an array, the CommandActions::isGrantedOnCommandTargets() method iterates through each downtime and calls isGrantedOn() individually. The isGrantedOn() method in DowntimesController correctly checks permissions on $object->{$object->object_type} (the host or service that the downtime belongs to).

This approach is consistent with other controllers like HostController and ServiceController that also return arrays from fetchCommandTargets().

Fixes #1256.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[cla-bot]

Thank you for your pull request. Before we can look at it, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://icinga.com/company/contributor-agreement to sign the CLA.

After that, please reply here with a comment and we'll verify.

Contributors that have not signed yet: @Copilot

Details

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Please contact us if you think this is the case.

• If you signed the CLA as a corporation, your GitHub username may not have been submitted to us. Please reach out to the responsible person in your organization.

[cla-bot]

Thank you for your pull request. Before we can look at it, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://icinga.com/company/contributor-agreement to sign the CLA.

After that, please reply here with a comment and we'll verify.

Contributors that have not signed yet: @Copilot

Details

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Please contact us if you think this is the case.

• If you signed the CLA as a corporation, your GitHub username may not have been submitted to us. Please reach out to the responsible person in your organization.

[cla-bot]

Thank you for your pull request. Before we can look at it, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://icinga.com/company/contributor-agreement to sign the CLA.

After that, please reply here with a comment and we'll verify.

Contributors that have not signed yet: @Copilot

Details

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Please contact us if you think this is the case.

• If you signed the CLA as a corporation, your GitHub username may not have been submitted to us. Please reach out to the responsible person in your organization.

[nilmerg]

This does not even remotely resolve the issue. That's a bad workaround (even if, didn't test). #1246 solves a very similar issue and the underlying problem is the same here.

[Copilot]

This does not even remotely resolve the issue. That's a bad workaround (even if, didn't test). #1246 solves a very similar issue and the underlying problem is the same here.

You're right that this is not the proper fix. I can see that PR #1246 addresses the same underlying issue with filter qualification. Could you provide more guidance on the correct approach for handling the bulk deletion case?

The problem is that isGrantedOnType is called with downtime-specific filters that can't be applied to host/service queries. Should I:

1. Transform the downtime filters to be applicable to host/service models?
2. Override the permission checking logic entirely?
3. Something else?

I want to implement the correct fix rather than a workaround.

[cla-bot]

Thank you for your pull request. Before we can look at it, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://icinga.com/company/contributor-agreement to sign the CLA.

After that, please reply here with a comment and we'll verify.

Contributors that have not signed yet: @Copilot

Details

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Please contact us if you think this is the case.

• If you signed the CLA as a corporation, your GitHub username may not have been submitted to us. Please reach out to the responsible person in your organization.

[nilmerg]

The filters to remove multiple downtimes, based on a manual selection of multiple downtimes, are not qualified enough. Instead of name, they have to use downtime.name in each comparison. Patch the area where the filters are defined, that's probably a data attribute consumed by javascript.

[cla-bot]

Thank you for your pull request. Before we can look at it, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://icinga.com/company/contributor-agreement to sign the CLA.

After that, please reply here with a comment and we'll verify.

Contributors that have not signed yet: @Copilot

Details

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Please contact us if you think this is the case.

• If you signed the CLA as a corporation, your GitHub username may not have been submitted to us. Please reach out to the responsible person in your organization.

[Copilot]

The filters to remove multiple downtimes, based on a manual selection of multiple downtimes, are not qualified enough. Instead of name, they have to use downtime.name in each comparison. Patch the...

Fixed the filter qualification issue. Changed the multiselect filters to use qualified names: 'downtime.name' instead of 'name' for downtimes and 'comment.name' instead of 'name' for comments. This ensures proper filter qualification when multiple downtimes are selected for bulk operations. (4c210fb)

[nilmerg]

Good. Quite surprised of your ability to navigate the code based on such a rough hint. Still, without that hint…

[nilmerg]

I consider this a trivial change, especially since I needed to guide the bot to the fix quite substantially.