I need to have the possibility to control the permission to modify attributes related to the lifecycle state of the object. It must be possible to modify some attributes in the lifecycle state RELEASED while others should should not.
People invariably find that some metadata needs to be changed after "release." Need to be very careful about this though - the release process triggers many downstream activities. Release at say B.3 with additional changes done without a Change Notice that result in B.4 causes problems - the current Iteration is B.4 but the release was done at B.3.
Product Analytics Compliance (InSight) data is one example of where compliance data can and does change without iterating the WTPart.
Also, actions such as Move do not iterate the Part.
Possibly need a deeper study of what metadata needs to be part of Iteration and what can be changed without Iterating.
I agree with Mike that it is important to dig into the details of the use cases. We are always trying to balance the number of different permissions with the ability to allow you fine grain control.
Last year at Windchill technical committees, we heard the business reasons for why customers would want to add a related document such as a brochure to a released part.
Martin - what type of attributes do you want to change after the object is in the release state? Why?
Gregory - can you describe the situations where you want to control access by the View?
we manage for example our tooling request in PLM. These toolings are created as WTParts and do have several IBAs. Some of these attributes have to be maintained even though the WTPart is in state released. So the attribute "Number of shots" and "Date of first shot" have to filled and modified after the tooling is released. These attributes are used for reporting and controlling of the tooling and to order new toolings at the right time.
Currently we use workflows to update these attributes on released parts.
If you need detailed informaiton, please contact me.
