9 Replies Latest reply on May 21, 2012 1:58 PM by Corey Hinman

    Are you Rolling Back Rejected Changes?

    Brian Dalton

      When a user makes proposed modifications to a released part, the file history shows new versions created which are later than the official released one.  If that change is ultimately not approved, do you normally roll back the history of the part to remove the rejected changes.  In other words, do you roll it back to ensure that the latest version is the officially released one?

       

      My thinking is that one should not roll back these rejected changes, as they are a part of the file history, and the actual released version is still available anyway further down in the history, but I'm being asked to justify maintaining history of changes that were rejected.  I'd like to know how others are handling this sort of thing.

        • Re: Are you Rolling Back Rejected Changes?
          Gary Radish

          Brian do you use Cold Storage?  Versions aren't that important. Revisions are what you want to make sure what you keep. We run a dual revision system which catches those major rejected revisions that go thru a workflow transition (numeric)  Until final release which starts Alpha.  The versions in between are just the extra garbage left over.

            • Re: Are you Rolling Back Rejected Changes?
              Brian Dalton

              OK... so I'm guessing your answer is no, you don't roll back rejected changes...

                • Re: Are you Rolling Back Rejected Changes?
                  Jason Capriotti

                  We use the rollback although only an admin user is allowed as the function is too dangerous for the mere mortal. If the file is transtioned from "Release" to "Inwork" on an ECO, and it gets cancelled, the rollback is the only easy way to undo the changes and put it back to the unchanged reeleased state. Sure, you could create a transition back from Inwork to Release and go through pulling out the old release version and try and replace it but that's a lot of work that can easily miss something.

                   

                  As for history, we generate a separate PDF for each revision of every drawing anyway. The engineers are required to create a redline markup PDF of the drawing in the ECO folder. This documents the change that would've been made. This "Markup" pdf is set to cancelled but it is there for reference. I suppose if we really need to keep the orginal file, we could copy it to the ECO folder for reference but so far that hasn't been an issue.

                  • Re: Are you Rolling Back Rejected Changes?
                    Gary Radish

                    Yes the answer is No,  Like Jason said only an admin should rollback because they will make sure you are checking for all related files which a general user is more likely to ignore the effects it has on other files.  Usually they only care about the files they are currently working on.

                • Re: Are you Rolling Back Rejected Changes?
                  Brian Dalton

                  My purpose in this post is to determine what others have chosen to do with regard to the file version history and changes that have not or will not be made effective.  I appreciate all the responses so far and I hope to hear more from other PDM/CM admins.

                   

                  It's a very important issue that is causing some conflict in my company, and in order to help resolve it, I think we could all benefit from establishing some kind of 'best practices' list or at least the airing of relevant viewpoints.

                   

                  To me, a primary purpose and benefit of a system like EPDM is that it maintains a strong history of design activities, and a process like rollback defeats that purpose.  It's a necessary tool, but should be used minimally and only in specific cases where a real need is identified by an individual decision.

                   

                  Creating a policy where file history is routinely destroyed as a matter of course doesn't make sense to me.  Accordingly, I implemented a policy of rolling back (admin only) in only those cases where a specific instance decision is made by management.  Under this paradigm, when a change is proposed but rejected, the file history remains intact and the file is placed in the 'Not Released' state.  The only problem I have with this is that EPDM reports the file state to be that of the latest version, even if you Get an earlier version that was placed in a different state.  I don't feel right about placing the file back into the Released state when the latest version has not been released, but I don't know how this would best be handled.

                   

                  Moreover, I can't get my users to let go of the idea that the latest version should always be the one that they want, so any file which has versions later than the official released version confuses them.  Specifically, in the case of files where a proposed change has been rejected, they want to know why it is useful to retain later versions when those changes will not go into effect.  I'm not sure why having those versions available might be useful, but deleting file history summarily just seems anathema to me.

                   

                  Further opinions on these issues would be very helpful.

                    • Re: Are you Rolling Back Rejected Changes?
                      Corey Hinman

                      We don't have to do it often, but unfortunately we are rolling back. As part of our ECR system though, the work order requesting the changes is approved by management well before CAD gets their hands on it.

                       

                      What would the alternative be? Overwriting the latest version with an older version?

                        • Re: Are you Rolling Back Rejected Changes?
                          Brian Dalton

                          What I'm suggesting is leaving the rejected change versions in the history rather than rolling them back.  The latest Released Version is still available and using assemblies still refer to that version, but the latest version is not the one which represents the approved design or which is allowed for manufacture.  See example:

                           

                          8

                          7

                          6 Rev A (released)

                          5

                          4

                          3

                          2

                          1

                           

                          In this example, the part was approved and released to Rev A at version 6.  Later, versions 7 and 8 were created by an Engineer who proposed adopting those changes.  They were rejected, so Rev A (version 6) is still in force.  Mfg can only see released revs, so they can't see versions 7 and 8.  Engineering can see all versions, but can easily Get version 6 to ensure that they are working with the latest release.  If further revisions are proposed based on the latest Released Version (not the rejected versions) the Engineer can Get version 6, modify it and check it back in at version 9.  7 and 8 remain in history (for historical purposes) but are bypassed.

                           

                          Some of my users are quite unhappy with this, because if the Get the latest version, they don't have the latest Released Version.