Ownership blocks multi-site lifecycle progression

[delete3]

This is reference to the post that appears to have expired.................

RobEndert

Contributor

Posts: 1

Registered: 07-23-2010

Vault 2011 ownership blocks multi-site lifecycle progression

Options

145 Views, 0 Replies

07-23-2010 02:09 AM

We’re setting up an Inventor2011/Vault 2011 multi site environment with three mutually replicating servers. The lifecycle stepping, revision bumping, synchronizing properties and update views goes well for as long as one has ownership. We also enforce the “children released” check to inhibit release of assemblies without full release status of components. Synchronizing properties and update views automated through the JobServer.

Trouble starts when one or more components are owned by another workgroup location. The system refuses any lifecycle change of an assembly even if you are owner of the assembly, and when all the components are in the “released” state. The only way to advance a multi ownership assembly’s lifecycle is to take out the “children released” check, the synchronization and the view update. This leaves us without the coherence and the automation we need. In our view, the bottom-up the “children released” check sufficiently prohibits release steps of assemblies higher up, and checking one level down is enough. Ownership of the assembly to advance in the lifecycle is enough, we don’t care for who is the owner of components one or more levels down. It is simply not feasible to properly release a machine with 1200+ parts with parts and subassemblies dispersed in Switzerland, Malaysia and China when you need full ownership of the all files, including the Content Center!

Any suggestion to help us get forward is welcome!

------------------------------------------------------------------------------------------

I am looking for anyone that has Vault Collaboration or Pro 2012 running Full Replicatoins between multiple sites.  Looking for users that have pin pointed effective workflows in parallel with Ownership and Content Center Files.

Any responce would be of assistance...

[delete3]

We’re setting up an Inventor2011/Vault 2011 multi site environment with three mutually replicating servers. The lifecycle stepping, revision bumping, synchronizing properties and update views goes well for as long as one has ownership. We also enforce the “children released” check to inhibit release of assemblies without full release status of components. Synchronizing properties and update views automated through the JobServer.

Trouble starts when one or more components are owned by another workgroup location. The system refuses any lifecycle change of an assembly even if you are owner of the assembly, and when all the components are in the “released” state. The only way to advance a multi ownership assembly’s lifecycle is to take out the “children released” check, the synchronization and the view update. This leaves us without the coherence and the automation we need. In our view, the bottom-up the “children released” check sufficiently prohibits release steps of assemblies higher up, and checking one level down is enough. Ownership of the assembly to advance in the lifecycle is enough, we don’t care for who is the owner of components one or more levels down. It is simply not feasible to properly release a machine with 1200+ parts with parts and subassemblies dispersed in Switzerland, Malaysia and China when you need full ownership of the all files, including the Content Center!

Any suggestion to help us get forward is welcome!

------------------------------------------------------------------------------------------

I am looking for anyone that has Vault Collaboration or Pro 2012 running Full Replicatoins between multiple sites.  Looking for users that have pin pointed effective workflows in parallel with Ownership and Content Center Files.

Any responce would be of assistance...

[Richard.Rankin]

I just updated that previous thread with a note that Autodesk released a hotfix that relaxed the rules a little in 2011

http://usa.autodesk.com/adsk/servlet/ps/dl/item?si​teID=123112&id=15980840&linkID=9261341

To the best of my knowledge, this change should have been included in 2012 as well.

I hope this helps

______________________________________________________________

If my post answers your question, please click the "Accept as Solution" button. This helps everyone find answers more quickly!

[delete3]

OK RIchard...  can you explain further the statement "relaxed the rules a little in 2011"?  depending on your explanation I will be able to determine if it was rolled into 2012.  The main issue at hand relates to Content Center files (Content Center Library\enu\...) having to be "Owned" in order to check-in an Assembly.  My testing in  full replication mode over three sites is that in order to check-in an Assembly with fasteners, they must be owned by that workgroup.  This "by design" Data Flow seems troubling.  Any further comments would be appreciated.

-Kevin

[Richard.Rankin]

I think there is a problem with all links from Autodesk.com. I am not sure how long it will take to resolve.

In ts15853682 is the following text

"In a replicated workgroup environment, ownership is required in order to perform operations like a state change. The ownership requirement for dependent files required that all dependent files are owned by the workgroup performing the state change. This update relaxes the requirement to allow a state change without owning dependents."

[delete3]

Hello Richard... Completely understand Ownership and state changes and dependent file relationships.  Again, the sticking point is Content Center Data ($\Library\Content Center Files\enu\...) and its relationships.  A CCF that is generated (i.e. Socket Head Cap Screw) as a Standard component and saved in the library structure becomes a non-editable component in an Assembly.

So!  If Workgroup 'A' takes ownership of the Content Center Libary in order to check-in data, that means users in Workgroup 'B' are unable to check-in data until Workgroup 'A' releases ownership?  If this is a true statement, then there is a design flaw!  If I am misinterpreting the CCF library design workflow please help me understand?

Thanks,

-Kevin