Adding new values to extensible list-type custom tags in SSC issue update during remediation#994
Adding new values to extensible list-type custom tags in SSC issue update during remediation#994jmadhur87 wants to merge 1 commit intofortify:dev/v3.xfrom
Conversation
…te during remediation
SangameshV
left a comment
SangameshV
left a comment
There was a problem hiding this comment.
Also please check whether the SSCCustomTagDescriptor requires extensible field
| SSCCustomTagDescriptor desc = getDescriptorByCustomTagSpec(tagGuid, true); | ||
| ObjectNode body = (ObjectNode) desc.asJsonNode().deepCopy(); | ||
| LinkedHashMap<String, ObjectNode> valueMap = buildValueMap(body); | ||
| if (!valueMap.containsKey(newValue)) { |
There was a problem hiding this comment.
A case mismatch in the keys can create duplicate list values in SSC. The buildValueMap method returns the listValues map with lowercase keys, and the containsKey check always returns false due to the case difference, thereby allowing duplicate list values to be added to the overall list.
Note: The same bug would cascade into extendTagWithValue, which caches the returned newLookupIndex in tagInfo.getValueList() a wrong index would be reused for all subsequent issues in the same command run.
| } | ||
|
|
||
| private int extendTagWithValue(CustomTagInfo tagInfo, String newValue) { | ||
| int newIndex = new SSCCustomTagDefinitionHelper(unirest).addValueToListTag(tagInfo.getGuid(), newValue); |
There was a problem hiding this comment.
The addValueToListTag makes a redundant full GET /customTags call.
extendTagWithValue in SSCIssueCustomTagHelper creates a new SSCCustomTagDefinitionHelper instance that triggers lazy-loading of all custom tags via GET /api/v1/customTags?limit=-1 just to get the descriptor for one tag. A targeted GET /api/v1/customTags/{id} would be more efficient.
| private String comment; | ||
| @Option(names = {"--assign-user"}) | ||
| private String assignUser; | ||
| @Option(names = {"--extend"}, defaultValue = "false") |
There was a problem hiding this comment.
--extend at issue update level, not per-tag.
If updating multiple custom tags in one command (e.g. --custom-tags TagA=NewVal,TagB=ExistingVal), which custom tag the --extend applies to? What if a custom tag is not extensible?
For the extensible custom-tag it should add a value and for the not extensible tags, proper error message must be displayed.
2 participants
This PR enhances the SSC issue update command used during remediation to support adding new values to custom tags of type list when the tag is marked as extensible=true using new option --extend.
ssc issue update --extendWhile verifying for ssc tag update command, found that value updates for non-LIST custom tags (TEXT, DECIMAL, DATE) were incorrectly reported as Updated in fcli, even though SSC made no change.
Added explicit validation and a clear error message so these unsupported value operations now fail fast instead of showing a false success.
Fix: Support adding new values to extensible list-type custom tags in SSC issue update during remediation(#959 )