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.
@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.
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.
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.