Release Content
Summary
The following table provides a list of the customer facing / relevant changes in this release. Not all platform backend changes are included in this list.
|
Domains |
Type |
Notes |
Support Ticket |
|
Backend |
enhancement |
We removed the dependency of Task Runner component. From this release the predefined SWEAGLE jobs are run with the help of MongoDB.
|
|
|
Backend |
bug |
Fixed the issue of old exporters not working with mixed flavors.
|
|
|
Backend |
enhancement |
CDS history API now returns data of all the versions.
|
|
|
Backend |
enhancement |
New API is created to calculate and save the validation report of a CDS without making a change on the CDS.
|
|
|
Backend |
enhancement |
A new field "hideValue" is added to tag policies in order to define if a user can view the sensitive cdi's value. |
|
|
UI |
enhancement |
Changed the CDS history view to align with the updated API. |
|
|
UI |
Bug |
Fixed the issue of pagination not working on CDS list. When the preference cds_list.core_pagination.enabled is activated, the CDS list is loading as expected now.
|
|
Details – New API to calculate and save the validation report of a CDS without making a change on the CDS.
|
POST /api/v1/report/cds-validations?id={cdsId}&versionId={versionId}&tag={tag}&forIncoming={true/false} |
Details – Changing the CDS history view to align with the updated API.
Currently the CDS history API returns the old versions that only has history report. From this release, the API is changed to return a map instead of a list.
The key is the ID of a version, the value will be a delta report. If the value is empty, then a button is available in UI for that version to calculate the delta report.
The new API to return a map of versionId and delta report is below.
|
GET /api/v1/report/history?size=20&page=0&id={masterId} |
API to calculate delta report for a version:
|
POST /api/v1/report/delta-reports?id={masterId}&versionId={versionId} |
Details – New field "hideValue" is added to tag policies.
Currently cdi restrictions are controlled by tag policies where a user can view/edit a cdi. A tag policy has "canEdit" field where the user can edit a cdi.
For example, if a user creates a tag "sensitive", then a "sensitiveEdit" tag policy is defined as "canEdit" true, a "sensitiveRead" tag policy is defined as "canEdit" false and the "sensitive" tag is assigned to a cdi.
- a user who doesn't have any of these policies assigned won't be able to see that cdi
- a user who has "sensitiveRead" assigned will be able to view the cdi key and its value
- a user who has "sensitiveEdit" assigned will be able to view and edit the cdi key and its value
To handle preventing users to view the value of a sensitive cdi but allow them to see the cdi key, we are going to add a new field "hideValue" to tag policies to define if a user can view the sensitive cdi's value or not.
For example, if a user creates a tag "sensitive”, then a "sensitiveEdit" tag policy is defined as "canEdit" true (here hideValue field's value is not important, it's explained below), a "sensitiveReadAll" tag policy is defined as "canEdit" false and "hideValue" false, a "sensitiveReadKey" tag policy is defined as "canEdit" false and "hideValue" true and the "sensitive" tag is assigned to a cdi.
- a user who doesn't have any of these policies assigned won't be able to see that cdi
- a user who has "sensitiveReadKey" assigned will be able to view the cdi key but not it's value
- a user who has "sensitiveReadAll" assigned will be able to view the cdi key and its value
- a user who has "sensitiveEdit" assigned will be able to view and edit the cdi key and its value
if canEdit field is set to true for a tag policy it will override "hideValue" even if it is set to false. "hideValue" will be set to false by default in order not to break existing tags. If a combination of above policies assigned to a user, the broader policy will be applied.
