76 Kudos
jeff.noel

Rollback Revision Increment

Status: Future Consideration
by Valued Contributor jeff.noel on ‎07-25-2012 12:44 PM

Hi,

 

If a user accidently makes a change state of a model from Released to Work In Progress, it will increment the revision, and then leave us with no way to go back to the previous revision.  I understand why you would do this, as we shouldn't be going backwards with Revisions, so I don't believe every user should have access to this functionality, but an Administrator should be able to override the Revision if they determined there was a mistake made and we need to go backwards.

 

Thanks, 

Comments
by Valued Contributor dherman469 on ‎06-20-2012 06:10 AM

Hello,

     For Items, I can change the state forward and then roll it back if I find that the state change was a mistake.  Please add this feature to the file level revision scheme as well.  We will be forced to continue using Items to control the revision of documents, because we can't take the chance of not being able to rollback an error or mistake. 

 

Daniel Hermanson

by Contributor dmiller on ‎08-03-2012 01:13 PM

It would also be nice to have a mechanism to be able to pick the type of revision increment when changing state.  There are situations where I don't want to always revise by the Primary and need to pick Secondary or Tertiary.  Currently I would have to turn off Bump Revision or set it to Bump Tertiary and change revision again once it's in Work In Progress' state to get what I want.

by Board Manager on ‎08-07-2012 07:16 AM
Status changed to: Accepted
 
by Distinguished Contributor jparks_79 on ‎09-05-2012 07:13 AM

I would like to have this request above almost all others. it is such a huge hassle if a user accidentilly bumps a rev through state change or sync property. Especially if a file is used on several assemblies.

by Valued Mentor on ‎10-03-2012 02:00 PM

I agree 100% that Vault needs this functionality.  We have Vault Professional yet we have no plans for implemention the Vault item master and ECO module.  We have an item master that lives in our ERP system and have not currentl plans to maintain two.  We need to capability to roll back revisions when a change gets rejected or cancelled.  I've discussed this with some Autodesk folks and they all say implement the item master and ECO module and then you can do this.  NOT ALL CUSTOMERS CAN OR ARE WILLING TO DO THIS!  Vault needs to have this file centric functionality.  We moved from 3rd party PDM to Vault last year and this is the sngle most feature that we as a company feel needs to be part of Vault.

 

John Weiss

CAD Administrator

Follett Corporation

by Contributor bschupbach on ‎10-10-2012 05:54 PM

I could not agree more.  This is one of the single biggest issues my company faces as we rollout Vault from Product Development to the rest of the company.  Multiple engineers have brought up this issue independently in my company.  To start our ECR process we change our state from "released" to inwork" which triggers a rev bump so we can make the proposed changes to the drawing.  Then we initiate an ECR within our ERP system and attach a PDF of the proposed new Rev to this ECR to communicate the change.  Our Engineering Changes often have to go clear to our end customer and rejections are not uncommon.  What then?  I have yet to figure out a work-around here...

 

Aside from rejected ECR's, even adminstrators can accidentally bump a rev sometimes.

by Board Manager on ‎10-16-2012 08:16 AM
Status changed to: Under Review
 
by *Expert Elite* on ‎11-02-2012 06:24 AM

Agree 100%  We're moving more into actually USING lifecycles the way they were meant to be used... but along the line certain files have benn revised in Vault incorrectly.  Roll back would be awesome as long as there was good security on it... Admin function only.

by Board Manager on ‎01-14-2013 08:04 AM
Status changed to: Under Review
 
by Valued Contributor tmoney2007 on ‎02-07-2013 07:52 PM

Setting the revision to bump on the transition to "release" would be the proper methodology to protect against this.  You would need the ECO workflow to be allowed to put a file back into "released" if it were rejected.  Having to go through the workflow give accountability to the process by tracking those that make those mistakes and why they happen. 

 

It makes more sense to me than discarding a revision, and if any downstream systems trigger off of a revision change, you wouldn't run into issues.

 

That brings on the issue of what to do with the versions that are numerically higher than the latest released revision, but business rules can work around this.  "Any further modifications must start from the last released revision" could handle it.  Or, the eco process that moves the LC back to "released" could discard later version. 

You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
IdeaStation Guidelines
Review guidelines and best practices
before posting a new idea
Top Kudoed Authors
User Kudos Count
13
13
11
7
5