Hi,
a regression in DNG 6.0.6.1 iFix 010 was discovered, when it comes to handling updates of Artifact Type, imported via ReqIF.
This needs to be submitted to IBM, with the attached evidence and explanations.
NOTE: The issue below is NOT observed in DNG 6.0.6.1 ifix003, as shown in the screenshots.
In February 2018, while we were on DNG 6.0.4 ifix007 , large amounts of artifacts were imported in DNG, via ReqIF. Those artifacts had their Artifact Types pre-assigned to fit into our data template, which they did with no issues.
In July 2020, on DNG 6.0.6.1 ifix010, a new batch was imported, updating the existing artifacts and adding new ones.
All Object text updates, module hierarchy changes, attribute value assignments were successful, however, for a limited number of artifacts, which had their Artifact Type updated in the new ReqIF, this was not reflected.
The way to determine the failure of updating Artifact Type is via the mismatch between the "DNG Artifact Type" Text attribute in the reqifz package, which carries the expected artifact type value, and the actual Artifact Type property, after the import, as seen in screenshot 3. The problem is NOT limited to a single module. As seen in the screenshot 5 from the example module audit history, attributes and Object Text changes for the affected artifacts were performed fine, just not the Object Type (Artifact type) change.
When importing the same OLD data and then NEW data packages in DNG 6.0.6.1 ifix003, the Artifact type is correctly updated, along with the rest of the changed attributes and Object Text, seen in screenshot 4.
Evidence and explanation:
1 TYPE OLD_Data DNG 6.0.4 iFix 007.reqifz - the original package, containing the artifacts to be updated later.
2 TYPE NEW_Data DNG 6.0.6.1 iFix 010.reqifz - the updated package, carrying the new Artifact Types for several objects.
3 Type in ifix010 - created as Stakeholder Requirement then NOT updated - all.png - a filter by difference between actual Artifact Type and expected Artifact type ("DNG Artifact Type"). "DOORS ID" is a unique identifier, which can be used to locate the artifacts after the import. The crossed-out artifacts are not available in the NEW_Data package, so nothing to check for them.
4 Type in ifix003 - created as Stakeholder Requirement then updated - ASSYST__PLUS_3_V2.png - screenshot from the module audit history of one of the impacted modules,General_ASSYST_PLUS_3_V2, taken in 6.0.6.1 ifix003, showing the successful update of Object Type (Artifact type), along with the textual attributes, carrying the same value.
5 Type in ifix010 - created as Stakeholder Requirement then NOT updated - ASSYST__PLUS_3_V2.png - screenshot from the module audit history of one of the impacted modules,General_ASSYST_PLUS_3_V2, taken in 6.0.6.1 ifix010, showing the UNsuccessful update of Object Type (Artifact type), while the textual attributes, carrying the same value, are updated correctly.
Note: This issue is focused strictly on automatically updating Artifact Type, set originally, and only, by a ReqIF import. The case where the artifact type has been manually changed after an import is not relevant.
Our QA and Prod is in iFix010, and test (sandboxbox) enviornment is i n ifix003. Attaching the project templates from QA and sandbox along with reqif and screenshots.
Please find the attachments in TS004013510
