- **Type**: defect --> enhancement
---
** [tickets:#351] ntf:The check for the "Mandatory" parameters to be filled
while sending the notification is missing.**
**Status:** unassigned
**Milestone:** future
**Created:** Mon May 27, 2013 09:31 AM UTC by Praveen
**Last Updated:** Mon May 27, 2013 09:31 AM UTC
**Owner:** nobody
Migrated from http://devel.opensaf.org/ticket/2074.
There are some mandatory parameters to be filled in the notification structure,
while sending the notifiction.
But the notification is being sent succesfully, without setting those
mandatory parameters.
This is a bug. The send API should fail with proper return code, if the
mandatory parameters in the notification structure are not filled.
Below mentioned are those mandatory parameters for them there is no check is
being made.
1.The common parameter for all type of ntification ( Header parameter )
*notificationObject
*notificationClassId
2. The notification specific parameter for Security Alarm type
*probableCause
*severity
*securityAlarmDetector
*serviceUser
*serviceProvider
Changed 20 months ago by arne
■priority changed from major to minor
■status changed from new to closed
■resolution set to invalid
I don't agree on that this is a bug. The parameters should be checked so their
values are valid. If they are given a random non valid value (due to not being
set) then invalid param should be returned.
It is not obvious for all those parameters how to set a non valid value to be
able to recognize if the value has been set. For example what is a non valid
notificationClassId number?
If you find some checks are missing please write ticket for those.
Changed 20 months ago by vdeshapande
■status changed from closed to reopened
■resolutioninvalid deleted
As per the spec, any parameter mentioned as mandatory has to be filled, for the
notification to be sent successfuly. I am not filling the invalid vales for
these parameters, but filled nothing for them. For this there no INVALID_PARAM
returned, instead notification was sent successfuly.
I agree with your point, that how to assess invalid value for
"notificationClassId". Skipping that you can consider this bug for the
parameters like "probableCause" and "severity" in the security alarm
notification.
In the case of "severity" parameter, in the security alarm notification,
without filling any value the notification is being sent, without returning the
invalid param.
Please reconsider this bug.
Changed 20 months ago by arne
■milestone changed from 4.2.0.GA to future_releases
probableCause and severity does not have any specified "not provided" value
either in earlier specifications. So if this is a bug that bug is in the spec.
The latest spec A.04.01 has specified such "not provided" values even though
they were meant to be used for filtering. See comment in ticket #616 which is
related since it also need updates from A.04.01.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
