Bug 967450 - GET /alert/definitions does not render conditions and notifications
GET /alert/definitions does not render conditions and notifications
Product: RHQ Project
Classification: Other
Component: REST (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: RHQ 4.8
Assigned To: Heiko W. Rupp
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2013-05-27 04:07 EDT by Libor Zoubek
Modified: 2015-11-01 19:43 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-31 06:11:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Libor Zoubek 2013-05-27 04:07:51 EDT
Description of problem: 

Version-Release number of selected component (if applicable):
RHQ 4.8-master

How reproducible:always

Steps to Reproduce:
1.create an alert definition on any resource, define at least 1 condition and 1 notification
2.GET /alert/definitions.json or /alert/definitions.xml

Actual results:"conditions" and "notifications" are empty

Expected results: "conditions" and "notifications" must be rendered within a response body.
Comment 1 Heiko W. Rupp 2013-06-03 11:08:00 EDT
You can get notifications and conditions either in an individual call or by 
requesting only one definition.

I am not sure the full details should automatically be returned as this may be 
a huge amount of information.

I can imagine though, to pass a flag "full" to request the definitions 
including conditions and notifications.
Comment 2 Libor Zoubek 2013-06-03 15:30:29 EDT
I agree with potential amount of information, but as soon as we have paging when listing definitions, I don't see it as an issue. 

I was not accurate when defining steps to repro. conditions and notifications are not retrieved even when requesting a single alert definition using

GET /alert/definition/<ID>.json
Comment 3 Heiko W. Rupp 2013-06-03 15:34:16 EDT
You need to pass full=true as query param to GET /alert/definition/123.json?full=true

This flag is what I am thinking of for this BZ as well.
Comment 4 Libor Zoubek 2013-06-03 15:50:51 EDT
Ah .. I am sorry, I've completely overlooked it in API documentation. 
It actually now makes sense for me not to include conditions and notifications when GET /alert/definitions (a client listing all alert defs is not interested in those data), having full parameter in this case might prevent client doing X requests (in case he really needs 'all' definitions with all details)

But I still don't see use case why it is for one alert definition full=false by default.
Comment 5 Heiko W. Rupp 2013-06-04 15:12:24 EDT
master e718326

GET /alert/definitions now supports a boolean flag  full, that is false by default .
If set to true, conditions and notifications are returned as well.

GET /alert/definition/{id} also has this flag. This is now true by default
Comment 6 Heiko W. Rupp 2013-08-31 06:11:19 EDT
Bulk close of old bugs in VERIFIED state.

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