Visualization Update Error - Restrictions

[vandoren.david]

Im unable to update visualization files from Vault (update locally).  I get a "The file abc.idw.dwf cannot be deleted due to restrictions."  The solution is to open the file in inventor, check it out, save, check-in and create it then, this works 100% of the time, but updating from Vault Pro 2021 works 30-ish% of the time.

Things to note,

• Yes visualizations are part of "Record" category, which has full rights, not lifecycle or permissions. 
• Update from Vault is attempted via user account and full access admin account with same results
• It is possible to delete the dwf file, but we then loose it's history, which we want to try to keep
• dwf files are also used for mark-up (from design review).  This is the case with both the files that update and those who give error
• dwf are linked (attachment) to the idw, unless checked out, marked up and checked back in, then it looses its link.
• Support ticket with ADesk vendor didnt yield any results the first time around.  Will try again after this ticket.

[ihayesjr]

@vandoren.david 

This sounds like you are putting lifecycles and permissions on your DWF files. You shouldn't do this. That is why you are getting the delete restriction failure. 

[vandoren.david]

I too thought the same thing, but I am very careful with not assigning lifecycles to dwf files.  No life cycles, no states. 

[ihayesjr]

What are the security settings on the file? This could be coming from the folder.

[vandoren.david]

There are no permissions set for file or folder.  Effective Access reads "Allow" for all properties for all users, including user and admin accounts. 

[ihayesjr]

You stated:

"I'm unable to update visualization files from Vault (update locally).  I get a "The file abc.idw.dwf cannot be deleted due to restrictions."

When an Update View is executed, the version of the DWF currently linked to the parent file (IDW) is deleted and the new view is added. Users need the Delete permissions on the DWF file.

What else can your users be doing with the DWF files? The DWF files are hidden by default so they should not be checking them in or out at all.

[ihayesjr]

Also, in the Visualization Management commands, are any of these unchecked?

[vandoren.david]

We are using dwfs in a manner that is not supported by Adesk, I understand that.  We have dwf visibility turned on to all users and we use dwfs for mark-ups.  Manager can check out the dwf, redline/mark-up and check back in.  When user checks out the idw, then back in, it over-writes the markups and replaces with updated copy.   This method always works.  Its understood there could be a write conflict if things care checked back in at the right times, but thats not the issue here. Its re-generating the dwfs from vault (Actions>Update View>Update Locally) that fails ~70% of the time and update views via Job Processor that fail for the same reason too.

[ihayesjr]

@vandoren.david

Yes, checking the DWF files in and out is highly not recommended and most likely the cause of your issue.

I understand the need to markup the DWF files, however, I recommend that they get checked in as a different file name.

The DWF files are classified in a certain way when they are created during Checkin and Update View.

They cannot be classified that way if users are checking them in and out.

[ihayesjr]

The Update view and the Job Processor will fail when the DWF file is checked out.

[vandoren.david]

You are correct, dwf creation will fail if checked out.  How-ever this is not the issue here.  Some dwf files, even those that have not been checked out before or currently, fail to create from vault update due to "unable to delete" error.  I'm unable to find any difference between those who can be update and those who cant.  The only solution is to open/check-out/save/check-in the idw with "create visualizations locally" option enabled.

[ihayesjr]

@vandoren.david 

I recommend that your users stop checking out the DWF files. They should be marking up the DWF files and adding them back to Vault as a different name. 

Vault does this with the Change Order Markup workflow. A user can markup the DWF and when it is added back to Vault, it is given a new name.

[ihayesjr]

By the way, if the marked-up version of the DWF is the tip version, an Update View is going to delete the markup and create a new one.

Checking in the IDW and creating a DWF creates a new version of the DWF file.

[vandoren.david]

@ihayesjr I hear your point and understand this is not a supported method.  Over the last year of having this issue I've read dozens of forum posts and articles of people with similar issue where the topic is just left as "you shouldnt be doing it", which doesnt get anyone any closer to understanding the problem and developing work-around or fixes.  With that said, I wanted to continue the conversation on reason why this might be happening. 

It appears that when updating a visualization during check-in only creates a new version.  Does this error imply that updating from Vault is trying to first remove the dwf, then replace it with a new copy without any versions?

[ihayesjr]

@vandoren.david 

Yes, which is what I stated in my last response. So, if one of the users marked up the DWF file making it the tip version then someone performed an Update View, the marked-up version id deleted and replaced with the new DWF created.

As I recommended before, it is okay if the get the DWF file to mark it up. Don't check it out. Mark it up and check it in with a new name. You can even attach it to the parent file the DWF came from.

[vandoren.david]

@ihayesjr, Im sorry, not sure Im totally understanding.  When a user checks in a document and it creates a visualization, it doesnt delete the idw, instead superimposed a new version on top (as far as Vault is concerned), maintaining a version history.  We've experienced that mark-ups just add to the versions and new visualizations after checking in a markup just stack on top and never experienced a dwf file be completed deleted and recreated (losing its version history).  So this makes me confused on the "delete" part.  Here is an example:

Created by:

Brown = Visualization created local to user during check-in

Blue = Mark-up performed by reviewer (Checkout idw, mark-up, save, check-in)

Green = New visualization created during idw check in (addressing mark-ups)

Red = Check-ins, lifecycle changes and other triggered event sent to remote Job Processor

In most cases, the above workflow works perfect.  How-ever, in some cases, the JP and update command within Vault fail with delete restriction.  Is the delete restriction a vault delete (ie. vault delete command failing) or a windows explorer delete (ie. actual file on the server is locked).

Again, I do appreciate your patience helping me understand the issue here.

[ihayesjr]

@vandoren.david 

Ok, let's circle back to your original post.

You stated the following.

"Im unable to update visualization files from Vault (update locally).  I get a "The file abc.idw.dwf cannot be deleted due to restrictions."

You will only get this error if the DWF file is checked out or the user doesn't have permission to delete the DWF file.

• Clicking Update View deletes the tip version of the DWF file and creates a new one. That is why you are getting a delete restriction error.

Since you also state that the DWF files are assigned to the Record category but it doesn't have any permissions set in the category, it shouldn't be a permissions issue.

You stated:

"The solution is to open the file in inventor, check it out, save, check-in and create it then, this works 100% of the time, but updating from Vault Pro 2021 works 30-ish% of the time."

• Checking out the IDW and checking it in to create a new version of the IDW and creating a DWF, creates a new version of the DWF. It will not delete the previous version of the DWF. However, if the DWF file is checked out, it cannot create a new version of the DWF and the checking should fail. 

My guess here is that you are running up against a race condition. If a user had the file checked out to mark it up and checked it back in before you checked in the new IDW, you won't see the error. 

What I recommend not doing

Don't allow users to check out DWF files. If they need to mark them up, get the DWF file, mark it up, save it as a different name, check it back into Vault with the different name and attach it to the original IDW. 

This just might remove the issue altogether.

This DWF markup process that you are using runs the risk of losing the marked-up DWF file.

1. User checks in an IDW and creates a DWF at the same time.
2. IDW and DWF are at version 1.
3. A user checks out the DWF, marks it up.
   This is where a different user clicking Update View on the IDW will get the delete restriction error.
4. The user checks in the marked-up DWF file making version 2.
5. A different user decides to click Update View on Version 1 of the IDW. 
6. Vault will delete versions 1 & 2 of the DWF file, the marked-up version is deleted, and a new version 1 of the DWF file is created.

[vandoren.david]

@ihayesjr - Very detailed explanation, thank-you. 

1) I can confirm this is not a race condition, as we are aware of this possibility and have included checks within our workflow.  This issue is with all files checked in.

2) I'm not understanding the "6. Vault will delete versions 1 & 2 of the DWF file...".  I cant say I've experienced Vault deleting any files, just stacking a new version (as shown in the above screen cap).

It sounds like what you're saying, and correct me if Im wrong, is when an update to a visualization is triggered by a check-in or lifecycle change, it adds a new version to the history (ie. retains version1 and adds a version2), but if a manual (out of turn, where no new idw version was created) update is requested (ie. by clicking update view within Vault) it instead deletes the idw and creates a new dwf starting at version 1?

[ihayesjr]

@vandoren.david 

Scenario 1

1. Create an IDW
2. Save and check the IDW into Vault while creating a DWF file during check-in
3. Version 1 is created for the IDW and DWF
4. User click Update View, version 1 of the DWF is deleted and a new version 1 is created of the DWF file.

Scenario 2

1. Create an IDW
2. Save and check the IDW into Vault, do not create a DWF file during check-in
3. Version 1 is created for the IDW 
4. User click Update View, version 1 of the DWF is created and linked to version 1 of the IDW

Scenario 3

1. Version 1 of an IDW and DWF file exists in Vault
2. Check out the IDW and make changes
3. Save and check in the IDW into Vault while creating a DWF file during check-in
4. Version 2 is created for the IDW and DWF files

Scenario 4

1. Version 2 of an IDW and DWF file exists in Vault (a version 1 and version 2)
2. Check out the DWF file to perform a markup
3. Save and check in the DWF into Vault. 
4. Version 3 is created for the DWF file
5. User selects version 2 of the DWF file and clicks Update View
6. Version 3 and version 2 of the DWF file are deleted. Markup is lost. A new version 2 of the DWF file is created and linked to the IDW version 2

During check-in, a new version of the DWF file is created.

Update View, the tip\version of the DWF file is deleted and a new one created.

Without looking at your Vault and seeing it for myself, I have a strong feeling that putting marked-up versions of the DWF files in the middle of DWF files created automatically is causing or contributing to your problems. I recommend that you stop doing this.

[vandoren.david]

Scenario 1 - If an update is triggered, why is it being deleted and not a new version of the dwf created?

Scenario 2 - This is what I'd expect and believe happens

Scenario 3 - This is what I'd expect and does happen

Scenario 4 -  "6. Version 3 and version 2 of the DWF file are deleted. Markup is lost. A new version 2 of the DWF file is created and linked to the IDW version 2"  This is the part that doesnt make sense to me.   The update is trigger on the latest version of the idw, not the dwf.  Why would version 2 and 3 of the dwf be deleted and not version 4 of the dwf be created?  Is the issue with the linking back to version 2 of the idw? 

The only difference I see between a manually triggered update and one triggered by vault action is the versioning of the idw during check-in.  And again, this issue is also present on dwfs that have never been marked up and only followed the standard vault process.