Describe the bug

When a user is restricted in Director so they can modify Host objects but not Service objects, the restriction is only enforced in the Director UI.
In the Monitoring View, the Modify button for Services is still available, and the user is able to apply and save changes to Service objects successfully.

This results in users being able to modify Service definitions even though all Service-related modification permissions have been removed in Director.

To Reproduce

1. Create or use a role that has permissions to modify Hosts, but only read-only permissions for Services (or no Service permissions at all).
2. Assign this role to a test user.
3. Log in with the test user:
   • Director: the Service section is not accessible or is read-only.
4. Navigate to Monitoring → Service → pick any Service → click Modify.
5. Apply changes and save.

Service modifications are accepted even though the role should prevent them.

Expected behavior

The user should not be able to modify any Service objects when Service modification permissions are removed in Director. The Modify button in Monitoring View should not appear, and any attempt to change a Service should be blocked.

Screenshots

Your Environment

• Director version (System - About): 1.11.4
• Icinga Web 2 version and modules (System - About): Icinga Web 2: 2.12.4
• Icinga 2 version (icinga2 --version): 2.14.0
• Operating System and version: Red Hat Enterprise Linux 8.10 (Ootpa)
• Webserver, PHP versions: Apache 2.4.37 / PHP 7.4.33

Additional context

This behavior was reproduced on a clean environment. Permission restrictions configured in Director are not reflected in Monitoring View, allowing modifications that should be prohibited.