Bug 967450 - GET /alert/definitions does not render conditions and notifications
Summary: GET /alert/definitions does not render conditions and notifications
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: REST
Version: 4.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: RHQ 4.8
Assignee: Heiko W. Rupp
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-27 08:07 UTC by Libor Zoubek
Modified: 2015-11-02 00:43 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-31 10:11:19 UTC
Embargoed:


Attachments (Terms of Use)

Description Libor Zoubek 2013-05-27 08:07:51 UTC
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 15:08:00 UTC
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 19:30:29 UTC
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 19:34:16 UTC
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 19:50:51 UTC
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 19:12:24 UTC
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 10:11:19 UTC
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.