RHCLOUD-45800: Send notifications for V2 role operations

[randomnetcat]

Link(s) to Jira

RHCLOUD-45800

Description of Intent of Change(s)

Send notifications for V2 role changes.

Summary by Sourcery

Send notifications when custom V2 roles are created, updated, or deleted and verify this behavior in API tests.

New Features:

• Trigger notification events for custom V2 role create, update, and delete operations via the V2 role API.

Enhancements:

• Add a dedicated notification handler for custom V2 role changes with validation of supported operations and role types.

Tests:

• Extend V2 role API tests to assert that the correct notification messages are sent for create, update, and delete operations when notifications are enabled.

[sourcery-ai]

Reviewer's Guide

Adds notification sending for custom V2 role create/update/delete operations and updates tests to verify Kafka messages are produced when notifications are enabled.

Sequence diagram for custom V2 role change notifications

sequenceDiagram
    actor User
    participant RoleV2View
    participant custom_v2_role_obj_change_notification_handler
    participant NotificationService
    participant Kafka

    rect rgb(230, 255, 230)
        User->>RoleV2View: POST /v2/roles (create)
        RoleV2View->>RoleV2View: create RoleV2 role
        RoleV2View->>custom_v2_role_obj_change_notification_handler: role, created, request_user
        custom_v2_role_obj_change_notification_handler->>custom_v2_role_obj_change_notification_handler: check NOTIFICATIONS_ENABLED
        custom_v2_role_obj_change_notification_handler->>custom_v2_role_obj_change_notification_handler: validate role.type is CUSTOM
        custom_v2_role_obj_change_notification_handler->>custom_v2_role_obj_change_notification_handler: payload_builder(username, role)
        custom_v2_role_obj_change_notification_handler->>NotificationService: notify(custom-v2-role-created, payload, org_id)
        NotificationService->>Kafka: produce message
    end

    rect rgb(230, 240, 255)
        User->>RoleV2View: PATCH /v2/roles/{id} (update)
        RoleV2View->>RoleV2View: update RoleV2 role
        RoleV2View->>custom_v2_role_obj_change_notification_handler: role, updated, request_user
        custom_v2_role_obj_change_notification_handler->>NotificationService: notify(custom-v2-role-updated, payload, org_id)
        NotificationService->>Kafka: produce message
    end

    rect rgb(255, 235, 230)
        User->>RoleV2View: DELETE /v2/roles (bulk_destroy)
        RoleV2View->>RoleV2View: remove roles, collect removed_roles
        loop for each role in removed_roles
            RoleV2View->>custom_v2_role_obj_change_notification_handler: role, deleted, request_user
            custom_v2_role_obj_change_notification_handler-->>NotificationService: notify(custom-v2-role-deleted, payload, org_id)
            NotificationService-->>Kafka: produce message
        end
    end

Loading

File-Level Changes

Change	Details	Files
Introduce notification handler for custom V2 role lifecycle events and integrate it into V2 role create, update, and bulk delete flows.	Added custom_v2_role_obj_change_notification_handler to validate operation, ensure role type is CUSTOM, build payload, and dispatch notifications via notify Hooked handler into RoleV2View.create and RoleV2View.update to send notifications after successful DB commit and audit logging Extended RoleV2View.bulk_destroy to emit delete notifications for each removed role, logging errors per-role without affecting overall deletion response	rbac/management/notifications/notification_handlers.py rbac/management/role/v2_view.py
Extend V2 role API tests to assert notification Kafka messages are sent for create, update, and delete operations when notifications are enabled.	Imported unittest.mock helpers and patched RBACProducer.send_kafka_message in role V2 tests Decorated create, update, and delete tests with NOTIFICATIONS_ENABLED=True and verified send_kafka_message is called with the expected topic, event_type, payload structure, org_id, and timestamp placeholder Kept existing audit-log and behavior assertions intact to ensure notifications are additive behavior	tests/management/role/test_v2_view.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• In custom_v2_role_obj_change_notification_handler, raising a ValueError when the role is not custom or the operation is unknown will surface as a 500 from normal view code; consider returning early (or handling this as a no-op) to avoid runtime errors if new role types/operations are introduced or if the handler is accidentally reused.
• The string literals for event types (custom-v2-role-created/updated/deleted) are duplicated between the handler and tests; consider centralizing them as constants (e.g., in the notifications module) to reduce the risk of drift if these values change.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `custom_v2_role_obj_change_notification_handler`, raising a `ValueError` when the role is not custom or the operation is unknown will surface as a 500 from normal view code; consider returning early (or handling this as a no-op) to avoid runtime errors if new role types/operations are introduced or if the handler is accidentally reused.
- The string literals for event types (`custom-v2-role-created/updated/deleted`) are duplicated between the handler and tests; consider centralizing them as constants (e.g., in the notifications module) to reduce the risk of drift if these values change.

## Individual Comments

### Comment 1
<location path="tests/management/role/test_v2_view.py" line_range="989-998" />
<code_context>

         self._assert_audit_log(action=AuditLog.CREATE, description=f"Created V2 role: {data['name']}")

+        send_kafka_message.assert_called_with(
+            settings.NOTIFICATIONS_TOPIC,
+            {
+                "bundle": "console",
+                "application": "rbac",
+                "event_type": "custom-v2-role-created",
+                "timestamp": ANY,
+                "events": [
+                    {
+                        "metadata": {},
+                        "payload": {
+                            "name": data["name"],
+                            "username": self.user_data["username"],
+                            "uuid": response.data["id"],
+                        },
+                    }
+                ],
+                "org_id": self.tenant.org_id,
+            },
+            ANY,
+        )
+
     def test_create_role_multiple_permissions(self):
</code_context>
<issue_to_address>
**suggestion (testing):** Consider using assert_called_once_with to also verify call count for the notification producer

Currently the test only checks the call arguments, not that `send_kafka_message` is called exactly once. Using `send_kafka_message.assert_called_once_with(...)` would also guard against accidental duplicate notifications; you can apply this to the create, update, and delete notification checks.

Suggested implementation:

```python
        self._assert_audit_log(action=AuditLog.CREATE, description=f"Created V2 role: {data['name']}")

        send_kafka_message.assert_called_once_with(

```

```python
            ANY,
        )

```

To fully apply your suggestion, similar changes should be made for the update and delete notification tests in this file:
1. In `test_update_role_success` (and any other update-related tests using the same mock), replace `send_kafka_message.assert_called_with(...)` with `send_kafka_message.assert_called_once_with(...)`.
2. In the corresponding delete test(s) (e.g., `test_delete_role_success` or similar), also replace `assert_called_with` with `assert_called_once_with` for the `send_kafka_message` mock.
3. Ensure all such tests that validate notification payloads also verify the call count via `assert_called_once_with`.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion (testing): Consider using assert_called_once_with to also verify call count for the notification producer

Currently the test only checks the call arguments, not that send_kafka_message is called exactly once. Using send_kafka_message.assert_called_once_with(...) would also guard against accidental duplicate notifications; you can apply this to the create, update, and delete notification checks.

Suggested implementation:

        self._assert_audit_log(action=AuditLog.CREATE, description=f"Created V2 role: {data['name']}")

        send_kafka_message.assert_called_once_with(

            ANY,
        )

To fully apply your suggestion, similar changes should be made for the update and delete notification tests in this file:

1. In test_update_role_success (and any other update-related tests using the same mock), replace send_kafka_message.assert_called_with(...) with send_kafka_message.assert_called_once_with(...).
2. In the corresponding delete test(s) (e.g., test_delete_role_success or similar), also replace assert_called_with with assert_called_once_with for the send_kafka_message mock.
3. Ensure all such tests that validate notification payloads also verify the call count via assert_called_once_with.

[lpichler]

@randomnetcat can solve merge conflict please ? 🙏

[randomnetcat]

Done.

[lpichler]

Thanks @randomnetcat , can you please again rebase ?