Added issue get command for FoD and SSC#978
Added issue get command for FoD and SSC#978jmadhur87 wants to merge 1 commit intofortify:dev/v3.xfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adds new get subcommands to the ssc issue and fod issue command groups to retrieve a single issue/vulnerability by identifier, supporting optional embedded data and avoiding manual client-side filtering workflows.
Changes:
- Added
fcli ssc issue get <id> --av <appversion>command and supporting i18n/table output definitions. - Added
fcli fod issue get <id|vulnId> --rel <release>command with i18n updates and command registration. - Refactored SSC issue option message keys so
--embed/--includedescriptions can be shared beyond thelistcommand.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| fcli-core/fcli-ssc/src/main/resources/com/fortify/cli/ssc/i18n/SSCMessages.properties | Adds SSC issue-get help + table defaults; renames embed/include message keys for reuse. |
| fcli-core/fcli-ssc/src/main/java/com/fortify/cli/ssc/issue/cli/mixin/SSCIssueIncludeMixin.java | Updates description key to new shared SSC issue include message key. |
| fcli-core/fcli-ssc/src/main/java/com/fortify/cli/ssc/issue/cli/cmd/SSCIssueGetCommand.java | New SSC leaf command to fetch a single issue for an app version. |
| fcli-core/fcli-ssc/src/main/java/com/fortify/cli/ssc/issue/cli/cmd/SSCIssueCommands.java | Registers SSCIssueGetCommand under ssc issue. |
| fcli-core/fcli-fod/src/main/resources/com/fortify/cli/fod/i18n/FoDMessages.properties | Adds FoD issue-get help text keys. |
| fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/issue/cli/cmd/FoDIssueGetCommand.java | New FoD leaf command to fetch a single vulnerability for a release. |
| fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/issue/cli/cmd/FoDIssueCommands.java | Registers FoDIssueGetCommand under fod issue. |
| @DisableTest(TestType.CMD_DEFAULT_TABLE_OPTIONS_PRESENT) | ||
| @Command(name = OutputHelperMixins.Get.CMD_NAME) | ||
| public class FoDIssueGetCommand extends AbstractFoDOutputCommand { |
There was a problem hiding this comment.
FoDIssueGetCommand disables CMD_DEFAULT_TABLE_OPTIONS_PRESENT, but there is no *.output.table.args defined for this command in FoDMessages.properties. Rather than disabling the command-tree test, add a default table column definition (for example fcli.fod.issue.get.output.table.args or a shared fcli.fod.issue.output.table.args that get can inherit) and remove the @DisableTest annotation so this command adheres to the same output conventions as other leaf commands.
| private JsonNode getIssueByFilter(UnirestInstance unirest, String releaseId, String fieldName, String value) { | ||
| HttpRequest<?> request = unirest.get(FoDUrls.VULNERABILITIES) | ||
| .routeParam("relId", releaseId) | ||
| .queryString("filters", fieldName+":"+value) | ||
| .queryString("limit", "1"); |
There was a problem hiding this comment.
This get implementation still calls the vulnerabilities list endpoint (FoDUrls.VULNERABILITIES) with filters + limit=1 and then takes the first result. That contradicts the PR description/issue goal of avoiding list+filter for single-issue retrieval. Consider switching to the single-vulnerability endpoint described in #974 (GET /api/v3/releases/{releaseId}/vulnerabilities/{vulnId}), or at minimum document why the list endpoint is required here.
| HttpRequest<?> request = unirest.get(FoDUrls.VULNERABILITIES) | ||
| .routeParam("relId", releaseId) | ||
| .queryString("filters", fieldName+":"+value) | ||
| .queryString("limit", "1"); | ||
| JsonNode body = includeMixin.updateRequest(request).asObject(JsonNode.class).getBody(); | ||
| JsonNode items = FoDInputTransformer.getItems(body); | ||
| return items!=null && items.isArray() && !items.isEmpty() ? items.get(0) : null; |
There was a problem hiding this comment.
getIssueByFilter() ignores HTTP status codes and treats any response without items as "not found". For example, authentication/authorization errors or an invalid release id could result in an error response body that then gets converted into the misleading "No issue found..." exception. Consider using Unirest's ifFailure(IfFailureHandler::handle) (or explicitly checking response.getStatus()) before attempting to parse items, so real API errors are surfaced correctly.
| more immediate output. | ||
| fcli.ssc.issue.list.output.table.header.visibilityMarker = | ||
| fcli.ssc.issue.list.output.table.header.friority = Priority | ||
| fcli.ssc.issue.get.usage.header = Get application version vulnerability details. |
There was a problem hiding this comment.
The new fcli.ssc.issue.get.usage.header text says "Get application version vulnerability details", which reads like an application version command rather than an issue command. Consider aligning the header with the actual command (ssc issue get) to avoid confusing help output (for example, "Get vulnerability details" or "Get issue details").
| fcli.ssc.issue.get.usage.header = Get application version vulnerability details. | |
| fcli.ssc.issue.get.usage.header = Get vulnerability details. |
Added issue get command for both SSC and FoD to fetch a single issue by ID, avoiding full list + client-side filtering.
Supports optional --embed to include additional issue details.
feat: Add get command for fcli ssc issue and fcli fod issue(#974 )