[OASIS Issue Tracker] (OSLCCCM-29) References to before and after states of affected resources

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCCM-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62837#comment-62837 ] 

James Amsden commented on OSLCCCM-29:
-------------------------------------

Martin, I want to be sure I understand what you're asking for. When you say "allows the user to see the state of the affected resources prior to and after the requested changes have been implemented"...

Do you mean:
1. Resource version state can be captured at various points in time.
2. That change requests can be created
3. That changes made to a resource can be recorded and preserved
4. That the change requests can be associated with these changes
5. The collection of changes is frozen once committed/delivered and produce a new versioned state of the resource
6. Users can view the versions of a resource, the set of changes that were applied from one version to the next, the change requests associated with those changes
7. Users may also see differences between any two versions of a resource

If this is the case, then CCM might already support this.

> References to before and after states of affected resources
> -----------------------------------------------------------
>
>                 Key: OSLCCCM-29
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-29
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Bug
>          Components: Change Management
>            Reporter: Martin Sarabura
>
> Our PTC tools have a usability feature that allows the end user to see the state of the affected resources prior to and after the requested changes have been implemented. This allows a reviewer to easily ascertain that the implemented changes are consistent with the request, even if other changes had been introduced by other change requests concurrently. The alternative approach - which is supported by the current spec - is to review every change in the list of change sets. This approach adds cognitive load if more than one change set was created and/or if the same resource is represented more than once in the change sets.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)