Virtually all fcli commands that accept an application version id as input generate an incorrect error if a non-existing application version id is specified, for example:
$ ./fcli ssc issue count --appversion 3
com.fortify.cli.common.rest.unirest.UnexpectedHttpResponseException:
Request: GET https://ssc.uat.fortifyhosted.net/api/v1/projectVersions?limit=2&fields=id&q=id%3A3:
Response: 403
Response Body:
{"message":"Access Denied. One of these permissions are required to complete this action: [Generate reports, View application versions], or user does not have access to specified entity.","responseCode":403,"errorCode":-10301}
This error is misleading as there's nothing wrong with permissions, but unfortunately it's SSC that returns this incorrect response. There's nothing we can do in fcli to generate a more appropriate 'not found' error, as we can't identify whether this incorrect SSC response was caused by a non-existing id or an actual permission error.
Potentially, if SSC returns a 403 error on this particular endpoint, we could inform the user that this error is caused by either non-existing id or actual permission error, or we could have a troubleshooting section in the documentation that explains this.
Virtually all fcli commands that accept an application version id as input generate an incorrect error if a non-existing application version id is specified, for example:
This error is misleading as there's nothing wrong with permissions, but unfortunately it's SSC that returns this incorrect response. There's nothing we can do in fcli to generate a more appropriate 'not found' error, as we can't identify whether this incorrect SSC response was caused by a non-existing id or an actual permission error.
Potentially, if SSC returns a 403 error on this particular endpoint, we could inform the user that this error is caused by either non-existing id or actual permission error, or we could have a troubleshooting section in the documentation that explains this.