Consistency in implementing SecureTransportAction class
Currently when one Transport Action calls another, and the called TransportAction implements SecureTransportAction for backend filtering, we generally do not need the calling class to implement SecureTransportAction.
However we can implement it and "nip it in the bud" ( For example, if backend filtering is enabled and the user does not have a backend role configured) and raise the Exception. Only TransportGetFindingsAction nips it in the bud. TransportGetAlertsAction and TransportAcknowledgeAlertsAction do not.
This issue when resolved will take a consistent approach for all such cases.
It is not a bug, just being consistent in coding.
Consistency in implementing SecureTransportAction class
Currently when one Transport Action calls another, and the called TransportAction implements SecureTransportAction for backend filtering, we generally do not need the calling class to implement SecureTransportAction.
However we can implement it and "nip it in the bud" ( For example, if backend filtering is enabled and the user does not have a backend role configured) and raise the Exception. Only TransportGetFindingsAction nips it in the bud. TransportGetAlertsAction and TransportAcknowledgeAlertsAction do not.
This issue when resolved will take a consistent approach for all such cases.
It is not a bug, just being consistent in coding.