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 wrote:

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

---

Visualization file (DWF) associated with the parent file (IDW) is meant to be a one-to-one relationship, not a one-to-many. For every version of the IDW, 1 visualization file is linked. That is why the tip version of the DWF is deleted if it exists during the Update View execution.

---

@vandoren.david wrote:

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 Update view is triggered off the latest version of the IDW. That IDW should only have one DWF file associated with it. Since there are two, both are deleted and a new one created. This goes back to the one-to-one relationship I mentioned above.

---

@vandoren.david wrote:

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.  

---

The Update View will create a new DWF for the latest version of the IDW if one does not exist or it will delete the associated version of the DWF and create a new one. During check-in, a DWF doesn't exist so one is created. 

---

@vandoren.david wrote:

And again, this issue is also present on dwfs that have never been marked up and only followed the standard vault process.

---

Show a video of this happening. It might be helpful to see it. Be sure to show all DWF versions and IDW versions. Also, show the permissions on the DWF file and effective permission for the user attempting to perform an Update View.

[ihayesjr]

Although I can't confirm this, you are not breaking the link between the latest version of the DWF and the IDW during any of these unchecked commands.

If you are creating a DWF every time you check-in, why not check the Check-in box?

[vandoren.david]

@ihayesjr 

Understood, the idw is linked to a version of the dwf, not all the versions.  Also, different versions of the idw could be linked to a specific version of the dwf. 

Im confused on why vault would be deleting (or wanting to) any version of the dwf.  Is the tip (or latest) version of a file not handled by vault the same as a version file?  During the update command, vault cant update the tip version of the idw to link to the tip version of the dwf?  Because at the end of the day, I want to ensure the dwf matches the idw.  And with these failures in dwf creation so prevalent, I cant trust the dwf represents the latest copy of the idw.  Even when vault warns that the visualization is out of date, an "update" still fails in some case.

Im getting stuck on why a delete (assuming we are talking about deleting a file, including all its version from Vault here) would happen.   Why in the case of a check-in, a dwf version is created, but an update it wants to delete the dwf completely?

If I were to check the "unlink on check-in", wouldnt that break visualizations all together (i havent tried).  What benefit does having the dwf linked to the idw provide?  What would happen if I broke all idw to dwf links?

[ihayesjr · Accepted solution]

@vandoren.david 

Let's say you have five versions of an IDW and five versions of the DWF.

You perform an Update View on version five of the IDW, version 5 (and only version 5) of the DWF is deleted and recreated. Once the operation is complete, you still have five versions of the IDW and 5 versions of the DWF. 

All DWF versions are not deleted, only the latest DWF.

DWF files are special in Vault which is why they are hidden.

When you create a DWF file during check-in, that is called an uncontrolled visualization file. The yellow bar will appear in the View tab of the IDW when you view the DWF.

Why, because the user could have different settings for creating the DWF.

When a DWF file is created using the Job Processor or Update View, that is a system-controlled DWF and the yellow bar disappears. Why, because the Vault settings will control how the DWF is created. These are the settings in the Visualization Publish Options. This makes all DWFs created the same in the Vault. This also ensures that the DWF file matches the IDW and is created with the setting set by the administrator, not by the user.

If you want to ensure your DWF file represents the latest copy of the IDW, then let the Job Processor create it. Don't put marked-up DWF files in the middle.

Update View does not do anything with the IDW file. It doesn't have to. Its task is to create the visualization file, not touch the IDW.

---

@vandoren.david wrote:

If I were to check the "unlink on check-in", wouldnt that break visualizations all together (i havent tried). 

---

Here are three scenarios of what happens when you have checked the Check-in option to break the link on check-in.

For both scenarios, there are five versions of the IDW and five versions of the DWF linked to each other one-to-one.

Scenario 1

• Check out the IDW
• Edit the IDW, and save it
• Check in the IDW and create a DWF on check-in
• Version 6 of the IDW and Version 6 of the DWF are created and linked.

Scenario 2

• Check out the IDW
• Edit the IDW, and save it
• Check in the IDW and Do not create a DWF on the check-in
• Version 6 of the IDW is created with no DWF
  • Versions 1-5 of the IDW still have versions 1-5 of the DWFs linked
• Click Update View (Locally or Job Processor) on version 6 of the IDW and version 6 of the DWF is created and linked to version 6 of the IDW

Scenario 3

• Check out the IDW
• Edit the IDW, and save it
• Check in the IDW and Send the DWF creation to the Job Processor
• Version 6 of the IDW is created with no DWF
  • Versions 1-5 of the IDW still have versions 1-5 of the DWFs linked
• Once the Job Processor completes the DWF creation job, version 6 of the DWF is created and linked to version 6 of the IDW.

---

@vandoren.david wrote:

What benefit does having the dwf linked to the idw provide?  

---

It provides exactly what you asked for, a DWF that represents the version of the file it is linked to.

---

@vandoren.david wrote:

What would happen if I broke all idw to dwf links?

---

You can't break all IDW to DWF links. You can only break the Tip version link. 

There are five versions of the IDW and five versions of the DWF linked to each other one-to-one.

You detach the DWF from the IDW at version 5. Really what you are doing is creating version 6 of the IDW with no DWF. If you go to the History tab, right-click on version 5 of the IDW, and select View in Window, the DWF associated to version 5 of the IDW will appear.

[ihayesjr]

---

@vandoren.david wrote:

 Because at the end of the day, I want to ensure the dwf matches the idw. 

---

One thing I forgot to mention.

Having the option to break the link on check-in uncheck can do the opposite of what you want.

There are five versions of the IDW and five versions of the DWF linked to each other one-to-one.

• Check out the IDW
• Edit the IDW, and save it
• Check in the IDW (the user forgets to create a DWF on check-in or send it to the Job Processor)
• Version 6 of the IDW is created with no DWF
• Version 5 of the DWF is linked to version 6 of the IDW
  • The DWF file no longer accurately represents version 6 of the drawing. If version 7 of the drawing is created, there is no way to go back to version 6 to fix it.

[vandoren.david]

@ihayesjr 

I think I finally understand the issue now.  I had incorrect assumption that that updat process would create a new version and link it to the idw.  What you're saying is its simply updating by replacing the linked version with an updated copy (ie. v.5 of idw linked to v.5 of dwf, Vault is updating v.5 of dwf which requires a deletion of v.5 dwf first).  During check-in, since new version of idw is being created, it can freely be linked to a new version of the dwf.