Revise / Save As during checkin

[Pekholm]

A common usecase during change is that you don't know if the result of the change is a new revision, new variant or a new item or might be dropped. In Windchill, the user is forced to revise, then he can do a save as, but a unreleased revision will remain and pollute the revision history. As in Pro/IIntralink 3x (and other plm systems), the user was able to work on the current revision and could decide during checkin if this shall become a new revision or a new item. In this way, no unused revisions is created.

[BjoernRueegg]

We're missing for a sure a solution here. If the engineer gets the change task to edit something, but afterwards he finds out, that actually another part is the problem, then he need a possibility to undo the created revision.

For me it would be also a good possibility to have for each change a project where the objects can be added, revised and edited but at the end, he selects all the objects which actually are being revised and the rest stays untouched.

[Pekholm]

HI Bjoern

Thanks for your reply. Yes, its a good idea to use projects. Whats missing is the capability to continue working at the released data within the project and during checkin from project select to checkin as a new revision or new item. The project will then act as a isolated container from PDM. If the change is rejected, the history is still in the project.

[BjoernRueegg]

Jep, that's exactly what I meant.

[cmilligan]

Could you leave the resulting objects (RO) table empty and have the engineer edit it later after they dig into the solution? I think the CIB might be out of order though if you did. They would be approving a plan that was based on an empty resulting objects table.

I have thought about having the workflow automatically delete UNDERREVISION objects if the CN was cancelled/rejected, or if it was removed from the RO table. Would that help? I don't think it would be terribly hard to implement. Record the RO to a WTArrayList after the user submits the CN, and any action that can change the contents of the RO table, check against the list to see what has changed. Delete the revision on any UNDERREVISION items that were removed, add new items to the list. You would probably want to popup a message that tells the user that data is about to be deleted when they submit a change to the RO table which would be more complicated.

[Pekholm]

Thanks for your comment. Yes, that would be a workaround, but deleting revisions can be very cumbersome due to references and relations (specially CAD data). It does either resolve the use case where the designer finds out that the change will not fulfill form-fit-function and therefore need to generate a new item number instead of new revision. In a CAD centric change, the workaround is to use "continue" in a workspace to perform the change. When the designer can confirm form-fit-function of the change, he can checkin as new revision or do a workspace save as to a new item. This is not possible for non cad data.

BR
Per

[cmilligan]

I agree having the workflow delete things could get tricky if things start getting linked together with CAD references.

A simple solution might be open up delete rights for objects in that are under revision. Then have the user manually delete incorrectly revised items. Depending on your lifecycle though, there may be use cases where you don't want those rights granted. In that case I would add another state to the lifecycle that limits the states purpose to just objects being revised.