Bug 534621 (RHQ-13)

Talking this through with Joe its obvious we still need to keep the metric templates since we need a place to update the default settings which are shipped with each plugin. However given we dont ship any alert templates there is nothing there which could be edited by a user, so I think creating alert templates through groups might be more intuitive as we increase the set of things you can do on a groups.

I don't think requiring the creation of groups to do this is more intuitive. I'd be fine with having that as an additional feature, but i think the current templates should stay. In fact, I'd like to see a way created so that plugins could define default alert templates.

accepting and setting to 1.2 for further discussion.

list of features and system side-effects included under the "group alerting" umbrella:

basics

1a -- if the resource group is a compatible group, then allow the creation of alert definitions at the group level
1b -- support alert>definitions sub-tab at the resource group level, which supports CRUD operations for group alert definitions
1c -- support alert>history sub-tab at the resource group level, which supports viewing as well as deleting alerts that have been created against any resource that is currently in the group
1d -- support searching alerts at the group level by alert priority and creation date
1e -- support sorting and paging for 1b and 1c

parity with alert templates

2a -- similar to alert templates...updates to a group alert definition should trickle down to the corresponding resource-level alert definitions: any and all general properties; the set of conditions; and the notification, dampening, and recovery rules (see 2d)
2b -- similar to alert templates...when a group alert definition is created, a copy of the alert definition is applied to each member of the group
2c -- similar to alert templates...when a group alert definition is deleted, its corresponding children alert definitions should be deleted too
2d -- similar to alert templates...when a group alert definition is updated, the updates should trickle down to its corresponding children alert definition (see 2a)
2e -- similar to alert templates...an alert definition spawned from a group alert definition can be deleted, but if the group alert definition is updated it will be recreated with the new group alert definition data
2f -- similar to alert templates...an alert definition spawned from a group alert definition can be updated, but if the group alert definition is updated the resource-level changes will be overridden
2g -- similar to alert templates...an alert definition spawned from a group alert definition can be updated and "frozen", then if the group alert definition is update those updates will NOT trickle down to this alert definition
2h -- similar to alert templates...an alert definition spawned from a group alert definition can be updated and "frozen", but if the group alert definition is deleted it will still delete this "frozen" resource-level alert definition

side-effects of resource group maintenance

3a -- if a compatible group has a member added to it that makes it a mixed group, all group alert definitions must be removed (see 3a)
3b -- if a new member is added to a resource group, all group alert definitions need to be applied to create corresponding alert definition on that resource
3c -- if an existing member is removed from a resource group, all resource-level alert definitions spawned as part of group definitions need to be removed from that resource
3d -- if a resource group is deleted, then all group alert definitions for that group must be deleted to, which implies that all corresponding resource-level alert definitions spawned from them need to be deleted too (see 3a)

user interface

4a - 'flag' icon for compatible groups on browse resources
4b - 'flag' icon for compatible groups on inventory>overview sub-tab of a resource (groups this resource is a member of)
4c - alert tab when viewing group details
4d - right-click 'flag' icon when in the group left-nav tree

additional testing activities

* since this feature adds a few new columns to the alerting tables, there needs to be testing to make sure that db-upgrade (and fresh installs) work against our support databases. * need to make sure we haven't regressed on alert templates or resource-level alert definitions 

group alerting complete according to list of test cases in previous comment

Tested via testopia testplan
https://testopia.devel.redhat.com/bugzilla/tr_show_plan.cgi?plan_id=1120

All tests have been run, issues have been opened separately.  rev4856

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-13