PURGE ENHANCEMENT ON PREVIOUS DOCUMENT VERSIONS

[philippelandry4954]

Hello,

By using the files purge command in the ADMS, it is possible to purge the file store by basing on the document life cycle states. However, the rule is applied for each file previous version state, but not based on the last version.

For example, the user is working on a document and save it several times into the database in a state allowing the edition (eg WORK IN PROGRESS). If you want to keep all version in the database during the design step you, you define in the life cycle state that none version is purged. When the document is validated (eg in RELEASED state) you would wish to keep only the document last version between the previous Revision and the current one.

Unfortunately, the ADMS purge command will check the life cycle state of each version of the document, apply the rule and then keep a lot of useless files.

My wish would be to consider the last version file state and apply the purge rules for the previous versions except the RELEASED and CANCELLED state. As long as the document is in an edition state, no purge could be applied because a user should be able to return to a previous version of design. When the document is in REALEASED state, all intermediated version should be purgeable even.

Today we are able to set if we want to keep all versions, first and last, version, the last one or none. Moreover we are able to define what kind of state it is (Released or cancelled). Why isn't there a new option in RELEASED state saying that we want to keep the last version and purge all unflagged state previous versions ?

Of course all RELEASED or CANCELLED document should be kept in the database.

However, I think that we should keep the current working as today. when a child document is linked to another one (eg INVENTOR assembly) the document can not be purged whatever the life cycle state rule.

[Anonymous]

I want to be able to purge upon transitioning to a new state. More precisley when I transition to a "released" state I want to purge all intermediate versions. If the file has been release before the I want to purge back to the last release version. I can do this manually but automation is key.

I know that purging can be done Vault wide but the important point here is that I want to keep all versions until there is a released version. Purging vault wide could blast out a version that i may want to"go back" to.

[tmoney2007]

Currently, our options for data purging is limited to rules applied across the entire vault and based on the entire version history of a file. For example, if you are using lifecycles and you have released lifecycle states, you have the choice to keep all, none, first and last, or last of a particular state.  Also, it has to be applied across the vault as an administrative action.

I think it would be more manageable if the release state of a particular file could trigger a purge of its history. Also, the purge rules could relate to the consecutive versions of a particular lifecycle state.

Version Number Lifecycle State Action

1. WIP: Working checkin
2. WIP: Working checkin
3. WIP: Working checkin
4. WIP: Working checkin
5. Review: LC Change for Record of Review Process
6. WIP: Changes Made based on Review
7. Review: LC Change for Record of Review Process
8. Release: Record of Approval
9. Release: Sync Properties to show approver
10. WIP: LC Change when Revision Process begins
11. WIP: Working checkin
12. WIP: Working checkin
13. WIP: Working checkin
14. WIP: Working checkin
15. Review: LC Change for Record of Review Process
16. Release: Record of Approval
17. Release: Sync Properties to show approver of second revision

Under current rules, we could purge all WIP versions, and all Review versions across the entire vault, and keep all Release versions (as an example.)

My proposal would be to include a set of rules that would only keep the last version of a consecutive set of versions of a particular lifecycle state. For example, 9 and 17 would be kept, but not 8 and 16. These are versions that aren't actually released revisions of record because they hadn't had the properties updated on the file.

I would also like to have an option that could trigger a version purge for a specific file on a lifecycle transition. It could be set that on the transition from 7 to 8, purge rules would be applied, that is upon release, WIP and Review versions are purged. It would automatically happen again between 15 and 16.

This would allow versions purge management to no longer require admin interaction and for each user to know when their WIP versions would be purged.

[gilsdorf_e]

Greetings.

We just had two of our test systems purged and are now gathering feedback from the users.

One big issue are the limited options when using lifecycle controlled versions. For uncontrolled versions we see options for -keepver and -minage.

These would be highly welcomed in combination with the lifecycle rules.

For example we set up the lifecycles to keep first and latests version of all "Work in Progress" files. This is argued by our users, when the current revision is in "Work In Progress" state, while files are under heavy development. Quite often a  (manual) rollback to a previous version is required, which would not work after purging. Once a released state or new revision is reached, it would be okay to purge these version.

Example:

Version 1 WiP

Version 2 WiP

Version 3 WiP

Version 4 WiP

-> Expected result: Do not purge at all

Version 1 WiP

Version 2 WiP

Version 3 WiP

Version 4 WiP

Version 5 Released

-> Expected result: Allow purging of version 2 and 3.

Alternatively, if in case 1 version 4 did not change for a number of days (for example 180 days), then allow purging of version 2 or 3.

Regards

Erik

[RajSchmidt]

After I have released a document I usually don’t care for any versions left over from previous WiP states. Of course, if there are old versions in a “Released” state (for instance) they must not be deleted.

So why not include an option for a lifecycle transition: “Purge previous versions according to LC settings”.

[ihayesjr]

The purge operation is one which should only run on a scheduled basis by an administrator. It is an operation that could consume some server resources during work hours which could affect the Vault users daily task. You can perform what you are asking for by setting the Purge setting in the Work in Process state to None and running the purge regularly.

[RajSchmidt]

Hi ihayesjr,

yes, I know that the administrator has the option to run a purge across the whole file store. And it’s easy to run this as batch file via the Windows task planner.

But think of the following: A designer tries out some stuff, checks in his work each day and so creates several versions. He could always get back a version from the previous day since nothing has been released yet. Now the general purge is run over the weekend. On Monday the poor guy finds that Friday’s design does not work and he needs the Thursday version. Tough luck, that went down the drain on Saturday!

Now if you start a purge operation for a single file or a small assembly that should not bring down the system’s performance too much. And I don’t think that people often go and release several hundred files at the same time. To the contrary, I believe that you would actually distribute the workload compared to the general purge an admin can do.

In any case, the impact on the server would be about the same as if a user grabs a handful of files and does a manual purge. (Although as far as I can see, no user ever does that. A mechanical engineer is usually much too lazy, sorry, too busy for such tasks 🙂 )

[ihayesjr]

Good point.

[c_stulz]

Hello, I think this will be a good Idea.

I allthough look for someting like this.

In my opinion it will be enough, to combine lifecycle controled with time controled.

example:

- set files "work in process" to "last" or "first and last"

- set time to 90 days (aktual not possible for lifecycle controled files)

I think that will help allthough.

(I will make a new post for it on ideastation)