Description of problem:
If you create an Alert Definition via the GUI on a ResourceGroup you have access to, but you do not have any Global Permissions you cannot then access the Alert Definition once created
Version-Release number of selected component (if applicable):
4.4
How reproducible:
Steps to Reproduce:
1) Create a Compatible Group (TestGroup)
2) Add a platform to TestGroup
3) Create a role (TestRole) with the Manage Alerts (read/write) Resource Permission and TestGroup as an Assigned Resource Group
4) Create a user (testuser) with TestRole assigned
5) Login as testuser
6) Open TestGroup
7) Create a group level alert
8) Go to back to definitions and the alert definition is not displayed
9) Log back in as an admin user and the alert displays fine
Actual results:
Error banner displayed: Failed to fetch alert definition data
Expected results:
List Definitions
Additional info:

I've attached a patch that addresses two issues.
Firstly the issue described in 846451 is caused by the relationship between AlertDefinition and ResourceGroup. AlertDefinition maps the relationship with a property "resourceGroup" which causes the CriteriaQueryGenerator to create an incorrect query when attempting to restrict results based on authorization. The CriteriaQueryGenerator expects this relationship to be defined by a property named "group". A work around has been submitted to avoid refactoring AlertDefinition and the database schema.
The second fix covers the issue described in the post https://lists.fedorahosted.org/pipermail/rhq-devel/2013-March/002676.html.
"From the main dashboard, or any view not associated to a group or
resource the only users capable of acknowledging or deleting alerts are
those with global permissions. The effect is that users with specific
role permissions to manage alerts against a resource group must drill
into the heirarchy before they can ack or delete those alerts."
The fix affects only those users without MANAGE_INVENTORY permissions and only when they are viewing Alerts from views not associated directly with a resource or group. In these instance selection of an Alert row in the view triggers a call to the authorization service to check if they have a MANAGE_ALERTS permission for the associated resource.

Mark, thanks for the detective work and submission.
Problem 1, the AlertDefinition issue: The analysis is spot on, the entity field does not have standard "group" field name and instead has "resourceGroup". Your fix would work but I think I prefer the alternative you touched on, which is to just rename the entity field. It's a private field and changing it will not break public API. We can deprecate the public setter/getter and add a new getter/setter for the renamed field. Instead of adding special-case support for the misnamed entity field, let's make it conform.
Problem 2, the portlet "Ack"/"Delete" issue: You're right about this as well. We had originally made the conscious decision to not allow this due to the inefficient nature of the callback.
Since you present a real need, and I'm not sure it will actually be a problem, I'll apply your change. If we run into issues we can work on the implementation, using composites, or possibly make it optional based on maybe a portlet configuration setting.
I made one small optimization in ResourceAuthorizedTableAction. If constructed with a requiredPermission=null it will ignore the authz check. Using that we can make it perform like a standard table action. So, if in fact the user is an admin or otherwise has write access then it should act as before. I took away the isEnabled() overrides in your patch in favor of this approach. The overrides had a small issue because they did not consider "enablement". Meaning the buttons would be active (for admins) even if nothing was selected.
I'll be working this into master soon...

master commit dc97319555c5760bfc97662c2d2108c58e03269f
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date: Fri Apr 5 16:14:33 2013 -0400
Change AlertDefinition.resourceGroup to AlertDefinition.group. This brings
the name into the convention we use everywhere else, and that the CriteriaGenerator expects for group FK relations.
- Update all relevant queries and AlertDefinitionCriteria
- For back compat, keep existing setter/getter and deprecate. Refactor all
internal code to use the new setter/getter.
See Bug 949082 for the Ack/Delete issue.

In RHQ 4.7 a user with normal privileges on a group (that means without any global privilege) is able to create an alert definition on a group, but then if he tries to view the definition the details are empty, see the screenshots.

Created attachment 803399[details]
alert-definition
Version: 3.2.0.ER1
Build Number: 54dd29c:464a643
GWT Version: 2.5.0
SmartGWT Version: 3.0
Able to create alert definition, however if we click that alert, it is showing empty details. screen shot is attached.
I had set "Disable When Fired : Yes", once the alert fired it should be disabled, but it was showing as enabled. When I click alert definition link via "alert history", it's showing the alert definition properly and immediately definition shows in disabled state. From this point I can able to view/edit alert definition via "Alert definition" page.

Verified on:
Version :
3.2.0.GA
Build Number :
7b00246:6d13523
Verified scenarios from description and from comment 12. Problem described in second part of comment 12 is still there. I will create a separate bz for this.

Note

You need to
log in
before you can comment on or make changes to this bug.