Secondary Item Link - File security not locked

[DewayneH]

In the past, if we released a file with an equivalent value of a pre-existing item, that file would be linked as a secondary to the item and locked. It work beautifully.

I just released a file with an equivalency value and it was linked as it should, but the file is still unlocked.

It seems the only way to lock the file would be to manually WIP or quickchange the item and update then re-release.

This is tedious, and could be very time consuming. It is a little risky as well with the files not being secured.

To my knowledge there hasn't been any changes that would affect this.

We did recently, within the last few weeks, upgrade from 2017 to 2020.

Has something changed? Is there a new behavior or a new setting I'm missing.

What could prevent the newly linked secondary from being locked?

[ihayesjr]

@DewayneH I do not recall Items ever working the way you described. If the Item is released, most users are locked from modifying the Item. This includes adding new files to the Item. The Item would have to be in a state where you can modify it, Quick Change, or Work in Progress, then you have to perform an assign or update Item on the file which it would then get attached to the Item. Then you would switch the state on the Item to Released which the transition to Released would set the security on the file.

[DewayneH]

Hi Irvin,

This has been the behavior for us as long as I've been using items and file security. I don't give it a second thought.

You can imagine my surprise when I noticed it was not working as usual.

This link https://autode.sk/2ZQKdub is a screencast showing the issue.

In summary, an item is created and then released. Then a second file with the same part number (equivalent) is assigned an item. That file is attached to the item as secondary link, even though the item is locked as expected. The problem is the secondary file is not locked. 

I haven't created a secondary link since upgrading to 2020, so naturally I assumed the upgrade had something to do with it.

[ihayesjr]

Dewayne,

The way it is working in 2020, is the way I would expect it always to work, even in previous releases. Security is set on the transition of states, not just by adding a file to the Item after it is released. I will have to try this in an older release to see if I can reproduce what you saying worked before.

[DewayneH]

Irvin,

Have you been able to find a solution?

[ihayesjr]

@DewayneH I went back to Vault 2018, it acts just the way you are seeing 2020 act. I also think 2017 acts the same way. Security is only set during the transition of a state on the item. It will not set the security on a file when the file is added to the Item.

[DewayneH]

We must have had a "bug" that was fixed.

This will definitely add a step when creating substitutes and representations of models.

We typically assign the item and when duplicate part numbers are present they are handled.

Now we will have to address the item manually on the back end to protect the files.

That'll require the guys to remember there was a duplicate somewhere in the design in order to update the item. I have a feeling they won't. I'm fully prepared to have the files unprotected.

Thanks for looking. I wish you could have replicated the setup to find a solution.