Item’s lifecycle state must be “Work in Progress in order to..."

[kolesaa]

Since we start using Item lifecycles user began to  complain on impossibility to assign Items to some IAMs. It happens because of Item restrictions occur «Item’s lifecycle state must be “Work in Progress in order to perform the operation» on one of «child» Items that already has secondary file link to one om IAM’s components and is already released.

Changing lifecycle of restricted Item to WIP does remove restriction, but it is not something we’d like to do.

We don’t see any reason for “updating” and in fact “updating” of the restricted Item as part of assign Item on its parent changes nothing in restricted item itself (apart from value of “Last updated” property). No changes in rest of properties, no new file links etc. Why do we need new revision which is same as previous?

Isn’t it a bug of the Vault Pro?

PS: We are using Vault Pro 2014 SR1.

[kolesaa]

there is still a thread of with such a problem http://forums.autodesk.com/t5/Vault-General/Assign-Item-Failure/m-p/3763999#M46215. 

The problem is not solved

[cbenner]

I'm not sure about why it won't assign item because of a child being released,... but did you know that if you change the released Item to WIP, you can skip the Revision bump?  You will still create a new Version, but you do not have to have a new Revision.

As to why it is doing that in the first place... I might have to play around with that a bit to see if I can get a clue.

Any other vault gurus know this one?

[j_spiradek]

I think that, my client has the same problem.

The problem has been reported to Autodesk over a month ago, and still no solution 😞

[kolesaa]

1. change state Item WIP

2. Assign To Item

why two items?

if I do "check in/check out" problem file, the problem assign item disappears.

[Neil_Cross]

Unfortunately, there is simply no solution to this.  I battled with this very problem on a daily basis, it consumed literally days of my life trying every trick in the book but there was nothing.  

As I described in my original post, the problem doesn't actually make any sense. 

If you can't release Item 'A' because 'Z' is released, for a start that makes absolutely no sense on any level.

But then you try and release 'B' which also uses this 'Z', and it happily releases B! It's nonsense.  

In literally every case I had to give up following hours of fruitless efforts to resolve it, only to find the next day it fixed itself.  I managed to obtain a hint from someone near the top that it could be down to the item lock clean up mechanism failing to do it's job properly, it runs on a fixed daily cycle and there's no way to force it on demand.

[Maxim-CADman77]

I can confirm that problem goes away if clean up procedure is executed in the database.

PS: Autodesk gave us recommendation on how to set up auto-executing the clean up procedure as often as needed:

...you can let this process running multiple times by adding the key LockVacuumTime multiple times in a row in the web.config.

For example:

    <!-- time of day to clear entity locks. -->

    <add key="LockVacuumTime" value="3:0:0" />
    <add key="LockVacuumTime" value="10:0:0" />

    <add key="LockVacuumTime" value="15:0:0" />

So the process would run at 3:00 and 10:00 in the Morning and 15:00 in the afternoon...

PPS: Unfortunately this workaround removes the sympthoms but it can't prevent issue repeating.

[gavbath]

Thanks, this remedied the issue for me too.

[Maxim-CADman77]

Great to hear it helped someone else but for us it is rather workaround
(not solution).

We still hope to get it solved.

[gavbath]

I hope a better solution arrives too but...

I just thought I would mention, this problem can occur if you go to assign an item, and then before clicking "Finish" you click the "X" in the top right hand corner to close the window. That leaves the children in a locked state, which only get's undone at a later time.

If instead, you use the "back" button in the Item Assignment dialog, and then "Cancel," it rolls back the changes and prevents the issue.

[Maxim-CADman77]

Maybe. But the message is definitely misleading...

[Neil_Cross]

Which product version is this limited to?

I was running Vault Pro 2013 at the time when I was told on good authority that there was no way to kick start a db cleanup to remedy this issue.  Great if it's been resolved, but is this restricted to a certain product platform?

[Maxim-CADman77]

The recommendation was received for 2014.

AFAIK they made somewhat "button" clear lock in 2015 in clien interface
(have not checked it myself yet).



PS: If software quality won't improve much they will need to introduce
button "Rreset server" in client 2016...kidding

[Anonymous]

We've been scratching our heads over "The item must be unlocked to perform the operation" when updating items in the Vault's item master since upgrading to 2016.  The referenced items were predominantly grandchildren of the items we're attempting to update.

We did discover that intermediate items, parents of the children that this message refers to, have .iam files as well as either a .docx or a .idw in the Vault.  In numerous cases the .iam became secondary and one of these other files is primary in the item.  Whether this happened as a result of the Vault upgrade or if the wrong file was always secondary is impossible to determine.  But, unlocking the assembly's item without revision bump, changing the .iam to primary while making the other files secondary and re-locking the intermediate item eliminated the "item must be unlocked" issue for a ton of what were formerly offending grandchild items.

There are still have a few that this didn't fix.  So, we are still scratching our heads.  Just not quite as much.