What are the rules for Link Validity when the associated artifact is modified?
This question arose in the course of trying to write requirements and tests for Link Validity in CLM 6.0.1.
On a simple level - a change to an artifact's attributes (such as Title/Description/Text content) the Validity should (and does) revert to Suspect. For example: If the Link Validity has been set to Valid for artifact 1001 - and the Text Content for artifact 1001 changes from "old text" to "new text" - the Link Validity will now be shown as Suspect. What we've found, however, is that History plays a role - If the Link Validity for the new value is set to Valid and then the artifact is again changed back to a prior value where Link Validity was Valid (i.e. back to "old text") then Link Validity is NOT reported as Suspect - but is instead reported as Valid. Or - more accurately - setting the artifact data to a prior value for which a Link Validity state was assigned causes that earlier assigned Link Validity state to be reported for the artifact. Is this behavior indicated above - what is Expected/Intended for Link Validity? The answer will affect how we plan to test Link Validity - it was not what we expected (our expectation did not encompass any 'history' contribution, rather - any change (even to an older value) would result in Link Validity being set to Suspect .. this seemed to be a safer choice (and less complicated) to ensure that the associated Links were always reconsidered by the team after a change.. Product Version/Patch: CLM 6.0.1 iFix002a |
Accepted answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 18 '16, 2:20 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, remembering (and using) historical validity information is an essential feature of the Validity Service (and is one of the primary advantages it has over previous Suspicion Service). This is especially important when you are developing many variants of a given system, since this means that validity assertions made in one variant are automatically re-used in other variants that share those same artifact states (versions). For example, suppose the platform team has produced a new baseline of a system component, and they wanted to get that new baseline into the hands of all the customer project developers, without waiting until they have performed all the validity checks. With the Validity Service, they can do so, and whenever the platform team (or any of the variant developers) assert the Validity of some relation, that Validity information immediately appears in all of the other customer projects that are sharing artifacts from that new baseline.
Daniel Barbour selected this answer as the correct answer
Comments Hi Geoff,
While I think I understand the intent - I am not sure if it is directly applicable to the scenario I described so I'll beg for a little more time :) . You refer to reflecting the Validity information in all other projects sharing the same baseline. I agree with that goal - but the scenario I outlined is much narrower - no baselines have yet been created, there are no variants - so I am working within the current stream. Effectively, the current behavior is that the Link Validity State of the current artifact will be set to that of the most recent history copy of the artifact that matches the current artifact's signature (title/description/text..etc). From my perspective - I don't think we would ALWAYS want to say that you can simply reuse the most recent historical value (that earlier setting 'might' have been made by mistake). It might sometimes be true but the only way to ensure it IS looked at again would be to restore the Suspect state on 'any' change. If nothing else I would look for a settable mode to allow me to configure the system so it always defaults to Suspect.
Geoffrey Clemm
commented Feb 19 '16, 1:54 a.m.
| edited Feb 19 '16, 1:54 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note that baselining does not affect the behavior of the Validity Service (it doesn't care whether or not a particular version is captured in a baseline) ... that was just a way to set up the re-use example. So the sharing of the validity information is based solely on the content of the versions on each end of the link.
I am aware of the configuration comparison capability and acknowledge its value. And I recognize that Link Validity state is separate from the artifacts. Though I may have a different preference, I will ultimately accept the answer that it is working the way you, and the preponderance of users, intend for it to work (which, in summary, is that once a human has EVER set the Link validity state for the link between two artifacts that it will always be returned to that state regardless of the trajectory of changes made to the artifacts in the interim. If the trajectory again touches an earlier state matching one where validity had once been set - the link validity will, again, be reported for that state).
Geoffrey Clemm
commented Feb 19 '16, 10:48 a.m.
| edited Feb 19 '16, 10:49 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One way to think about it is that Link Validity is for a binary relationship with well defined semantics. So for example, if the artifacts are numeric formula, and the binary relationship is "equals", then if some human has asserted that the "equals" is valid for the two expressions "1+2" and "3", then any time you see the "equals" link type between the two artifacts whose content are "1+2" and "3", the system should tell you that this link is Valid". If you modify the content of the second artifact to be "4", the link will become "Suspect", but if you switch the second artifact back to "3", the link will again become Valid. You wouldn't want the system to respond by saying "you changed the second artifact, so the status must be Suspect".
Thanks Geoff - that explanation is helpful. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.