Update property mapping functions on state transitions

[f_calebh]

Bi-directional property mappings used in combination with the 'Create' file property option currently wipes out existing Vault user property values on state transitions if the file doesn't yet have the file property created. 

It seems as though a state change does a mini property update with the file version that was created from the state transition based on property mapping choices. For bi-directional property mappings, it will update the Vault property value to match the file property value. If the property that has bi-directional mapping doesn't yet exist in the file, a "blank" value is written over to the Vault property.

I would like to see this updated to either allow a mapping direction priority during these state changes or make it so that if the file doesn't yet have that property, it's not writing back a "blank" property value.

My current situation is that we have a user defined property mapped bi-directionally with a custom iProperty in Inventor. Previously this custom iProperty was only needed in IDW file types. The custom iProperty is part of our IDW template, so we never needed to use the 'Create' option. We simply had it set up as bidirectional mapping. Now, I'd like to create the custom iProperty ipt and iam file types. The user property already exists as a Vault property for these files, so when I set the property up to 'Create', I expected the Vault property would be written to the file. Unfortunately, unless the user performs a property sync before they make a state transition, the Vault value for that property is wiped out if the file doesn't yet have the custom iProperty.

[ihayesjr]

@f_calebh 

Thank you for posting the idea. Are you using the Property Compliance check to ensure all properties are compliant before the state change?

[f_calebh]

No, I didn't want to pass that burden on to the users. I know that as soon as I add that check, my support inbox will fill up with "I can't make state changes", even with the prompt. It's just something they haven't had to deal with before. We've always had Property Syncs running after the transition because we're using the 'Historical State' property on some of the documentation.

To handle our current situation, I've set the specific property we're having issue with to map only one direction from Vault to File. Our users are already familiar with datacards, so they shouldn't miss a beat if they need to update the property with the file open. I want to use this iproperty in some ilogic later on, so I'll to run some script to sync properties on files where that property is non-compliant. Once the script finishes, I should be able to set it to bidirectional mapping without seeing the issue. 

[cdbussey]

I agree that there should be some checking on the part of Vault. Doesn't seem to be a huge stretch to assume that there would be logic in the code that looks to see if a value exists, then skip that directional overwrite...since there are only two available (Vault to File / File to Vault).

[ihayesjr]

@f_calebh 

In your post you stated:

"Bi-directional property mappings used in combination with the 'Create' file property option currently wipes out existing Vault user property values on state transitions if the file doesn't yet have the file property created."

This could only happen if the file was in Vault and had a Vault UDP that was not mapped but had a value. The mapping happened afterward; the user did not check out the file but transitioned it to a new state, and then the UDP value would be wiped.

When the property is mapped, and the file doesn't have a value, editing the property inside of Vault will push the value in the file. Therefore, a property synchronization is not needed before the state transition. 

How often are you getting into this situation?

[f_calebh]

@ihayesjr 

Yeah, the issue would only appear when modifying the mapping, though in my situation, this property was already mapped bi-directionally and had a value. What I changed was the option to "Create" if the file property didn't exist. I only ran into this issue one other time after we first migrated files from our old PDM into Vault a few years ago.

[ihayesjr]

@f_calebh 

Thanks for the information. However, this is what property compliance checks are for. The user can handle this by simply running the synchronize property command. If you leave it up to Vault, that value could be wrong. The user should be directed to review the property for the correct value and then place it in the file.

[f_calebh]

@ihayesjr 

I hear what you're saying, but it's not as simple when asking the userbase is to change their expectations. This will be a new responsibility they'll be tasked with on state changes, and the prompt doesn't really provide all that much detail. I foresee a lot of frustration in having to back-track from transitioning a bunch of files if I implement an equivalence criteria block on state changes. There is also an equivalence issue that pops up when a property value doesn't match the value from a list. If the file is currently released, it's Read Only and can't be fixed by our users until it's transitioned out of the released state. I think it will be more straight forward if I script the sync properties. We use the Historical State property on some files, so we sync after each state transition as it is. That has really prevented any non-compliance issues for us with exception to this specific scenario. It just feels like this could work a little smoother.

[ihayesjr]

After a discussion, it might help to have Synchronize Properties sent to the Job Queue for multiple file selection.