Add issue get command for FoD and SSC

[jmadhur87]

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.

fcli fod issue get
fcli ssc issue get

feat: Add get command for fcli ssc issue and fcli fod issue(#974 )

[Copilot]

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/--include descriptions can be shared beyond the list command.

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.

[rsenden]

Apart from the individual comments on implementation details, we need to decide on what id's we should support, which is a tradeoff between fcli consistency vs usability.

For (almost) all other get commands in fcli, we just accept a single type of id, which corresponds to the id expected by the corresponding REST endpoint. This is what you've implemented for SSC, and would simplify the FoD implementation.

Also, we want to ensure consistency between issue get and issue update commands; these should accept the same type(s) of id('s). I think both FoD and SSC issue update commands currently only accept a single type of id (id for SSC, vulnId for FoD), so we should have the issue get commands accept those same types of id's only.

Having said that, for future consideration, we might want to consider deviating from this approach given that issues have multiple id's (id, issue instance id, and for FoD, vulnId).

For example, although users can see the SSC issue id in the output of the issue list command, I don't think this id is visible anywhere in the SSC UI. So, if users view an issue in SSC and then want to work on this issue in fcli (through issue get or issue update commands), they need to somehow figure out the issue id. Even SSC itself uses issueInstanceId filter instead of passing the issue id when opening the details for a given issue in a different browser window.

We can leave support for multiple types of id's as a future enhancement, although we need to think about the potential impact on command structure, for example whether we should have explicit options instead of a positional parameter (but that's inconsistent with other fcli get commands), to be able to differentiate between --id and --instance-id for example if we can't automatically determine the type of id being queried by the user. Alternatively, we can just try passing the given id through multiple REST queries on different fields (like you're more or less doing for FoD now, but not optimal from performance perspective), or support an optional prefix for the positional parameter, i.e., fcli ssc issue get instance-id:... vs fcli ssc issue get id:....

Somewhat related, for the issue update commands, I can imagine having a generic query option, i.e., update all issues that match a given query to perform bulk update, for example updating all issues in SQL Injection category, but again that's a potential future enhancement.

To summarize, maybe best to just have the issue get commands accept the same type of id as accepted by the issue update command for now, and raising an enhancement request for supporting additional id types on the issue get and issue update commands (again, these should be consistent as to what id types they support, likely through some shared helper class or resolver mixin), and another enhancement request for adding query support on the issue update command (maybe such an ER already exists though).

[rsenden]

Please double-check, but I think qm request parameter is not supported by SSC on this endpoint.

Also, we could consider using the issueDetails endpoint instead as that doesn't require application version to be specified (thereby simplifying CLI usage), but output of that endpoint is not the same as what we return on the list command, so users may not expect that inconsistency.

[jmadhur87]

Verified the SSC api reference , query parameter is available for this endpoint.

[rsenden]

I think this uses the following endpoint, which doesn't list a qm query parameter:

[rsenden]

Code still shows qm request parameter, which is not supported on GET /projectVersions/{parentId}/issues/{id} endpoint.

[rsenden]

Please check review comments. Also, as there's been some refactoring on FoD issue-related classes in http-mcp branch (which has higher priority to be merged than this PR), let's wait until that branch has been merged to dev/v3.x first, then update this PR as needed before merging it.

[rsenden]

I think this uses the following endpoint, which doesn't list a qm query parameter:

[rsenden]

Code still shows qm request parameter, which is not supported on GET /projectVersions/{parentId}/issues/{id} endpoint.

[rsenden]

Actually, same is true here as what I wrote for SSC. Although (contrary to SSC) the FoD endpoint used by this command does support the query parameters generated FoDIssueIncludeMixin, the user shouldn't need to explicitly pass --include if the given issue id is hidden/removed/... If user passes an id, we should just gt that id regardless of issue state. In other words, we should automatically pass query parameters to find issues in any state.

[jmadhur87]

To confirm my understanding the fix here would be to remove the [--include] option from the [get] command and hardcode includeFixed=true and includeSuppressed=true in [findIssue()] for both ssc and fod, so that any issue can be retrieved by ID regardless of its state, without requiring the user to pass extra flags. Is that what you're expecting?

[rsenden]

Correct for FoD; you'd always add the request parameters to have FoD return fixed/suppressed/... issues, such that FoD will return the issue data for the requested id independent of whether it's visible, fixed, suppressed, ...

For SSC, you're using an endpoint to get the issue data for a specific issue id. This endpoint will return that data independent of whether the issue is hidden/removed/suppressed; the endpoint doesn't support the request parameters generated by the SSCIssueIncludeMixin, and doesn't support the qm request parameter as explained in other comments.