Un-Resolved Problem Reports visible on current Rev of Object

[lgrant]

Hi,

I'm getting old but I remember that un-resolved PR's would move forward to the next Revision of the object they were associated with?

If a Document (Rev A) has three PR's against it and only one is acted on (CR, CN) and the Document is Revised to B.

That Document (Rev B) would still have two PR's associated with it.

Release: 11.2.1.6
 
Products Installed
windchill 11.2.1.0 supplier management
Creo View - Clients
windchill 11.2.1.0 mpmlink
windchill 2.1 REST Services
windchill projectlink 11.2.1.0
windchill 11.2.1.1 help center
windchill 11.2.1.6 service pack
windchill pdmlink 11.2.1.0
windchill 11.2.1.0 info*engine
windchill 11.2.1.0 Services
windchill 11.2.1.0 common base
windchill partslink 11.2.1.0

[JeffZemsky]

@lgrant Problem Reports do not automatically refresh in that case.  There is the business question of whether or not that Problem Report is valid for that new Revision.  We would not automagically decide that for the user.  Its an interesting discussion to go through on how this logic might work.  For Parts there is an attribute for Latest Revision that you could add to the Affected Table and see if your data (Parts anyway) are not the latest.

Who is responsible to decide?  Is the person who created the Problem Report?  An Change manger?  Some other role?  What is the right process?   Its definitely an interesting topic for the future.

[lgrant]

Our CM Engineers who process the change request are suppose to collect all PR's for the object in the table as the latest Rev of that part may not have included all the suggested corrections.

To do that, they look at all PR's on the current rev of the part but also need to go back and look at the previous rev to see if any PR's for that Rev are not resolved.

We use a priority scale on the PR if it needs to be addressed or it can wait. So a lot of PR's wait for the next rev.

[aacciano3]

@JeffZemsky 

I totally agree on your statement for a Problem Report, for a Change Request the behavior is the same but the need for the customers are different (e.g. multiple ECR on a Part, only one will be closed purposely).

While I agree with you that PTC cannot build OoTB logic for every customers, I still think that PTC should provide for the us a better way to see from within a Change Notice if the affected objects have Change Objects that are not carried forward, so the users (and the CMs) don't need to click many time (per many objects) to understand if something was missing. 

IMO, this could be a good enhancement to talk in your ongoing CN Redline Working group.

[Arjen]

A Problem Report is written on a specific revision of an object and might not be valid for a newer revision of that object. So I understand that from a 'related changes' point of view the Problem Report is not shown. I can however imagine that a second viewpoint is to have an overview of non-resolved Problem Reports on 'object master' (all revisions). To me this is a quite simple solution for not forgetting non-resolved Problem Reports on non-latest revisions. Would this be a solution? 

[avillanueva]

Old thread but should be resolved. You can have the workflow do whatever you want to solve this but it should not be automatic. There needs to be a human decision. The biggest issue with PRs, other than the overuse of the acronym PR, is the that workflow just ends. There is no mechanism to review accepted PRs later to make these kind of decisions. There is no route or workflow to change our minds later. There is certainly no mechanism to resolve when a change request is processed on that revision but was not linked to the PR so linking happens after the fact. Very manual. 

[Arjen]

@avillanueva having an additional table showing only the non-resolved problem reports on all revisions could be the solutions. Which problem reports to solve is of course a human decision. This way the non-resolved problem report are more visible to users.