Need different permissions for versioned versus non-versioned attributes

[MikeFoster]

In Intralink 3.x a distinction was made between versioned attributes and non-versioned attributes with regard to permissions. In addition attributes could be restricted such that only certain users or groups had permission to modify them.

In that system we used both kinds of attributes and set up permissions as follows:

* Versioned attributes: Modify allowed unless the release level of the object is "Released"
* Non-versioned attributes: Modify allowed at all times regardless of release level
* Certain non-versioned attributes: Modify allowed at all times but only by certain users or groups.

In Windchill I'm trying to reproduce this functionality:

The versioned attributes we want to restrict from modification when an object is released are description attributes that we use to populate a drawing's title block and parts list.

The non-versioned attributes I want to allow modification at all times contain status and tracking information. In addition I want to restrict modification of certain non-versioned attributes to particular users or groups.

In Windchill all attributes seem to be covered by the "Modify" permission. As such I can't find a way to differentiate between the versioned attributes and the non-versioned attributes. The closest I've come is somehow adding the versioned attributes I want to protect to the class of attributes governed by the "Modify Identity" permission. This requires some customization which is not very clearly described in the customizers guide. Even that doesn't appear to allow restriction based on user or group.

Am I missing something? Is it possible to reproduce this 3.x functionality in Windchill (specifically Intralink 9.1)?

Thanks,

Mike Foster
ATK

[MikeFoster]

All,

I've answered part of my question in which I want to prevent modifications to versioned attributes but not to non-versioned attributes when an object's life cycle state is "Released".

* Allow a designer to modify "non-versioned" attributes of any object whether released or not
"Modify" accomplishes this
"Modify" applies to both non-versioned and versioned attributes

* Prevent a designer from modifying "versioned" attributes of released objects
Set up the life cycle state transitions such that a released object cannot be checked out
Modifying a versioned attribute requires check-out > Workspace modify > Check-in of a new iteration
This is not allowed for a released object - "Revise" must be used

Since non-versioned attribute modifications, by definition, don't trigger a new iteration I can allow them at any life cycle state.

As for the second part of my question, I still don't have a method of protecting a particular attribute for modification by permitted users only. Is it possible with customization to allow only certain users to edit particular non-versioned attributes and still have those attributes visible to all users as read only?

Thanks,

Mike Foster
ATK

[mkraegeloh]

Hi,

using a service with a pre_store trigger you can control this as you
want. it has the advantage that the rule is enforced regardless of
technology used (java class, I*E or jsp), but the disadvantage that you
only react - the users will (at least initially) think they can alter
the values but when they submit the page they will get an error.

nevertheless this is a very powerful mechanism - see windchill
customizers guide appendix C (or the sulis homepage for a ready-to-run
solution 😉

cheers, martin

On 09/28/2010 10:23 PM, Foster, Mike (Goleta) wrote:
>
> All,
>
>
>
> I've answered part of my question in which I want to prevent
> modifications to versioned attributes but not to non-versioned
> attributes when an object's life cycle state is "Released".
>
>
>
> • Allow a designer to modify "non-versioned" attributes of any object
> whether released or not
>
> "Modify" accomplishes this
>
> "Modify" applies to both non-versioned and versioned
> attributes
>
>
>
> • Prevent a designer from modifying "versioned" attributes of released
> objects
>
> Set up the life cycle state transitions such that a
> released object cannot be checked out
>
> Modifying a versioned attribute requires check-out >
> Workspace modify > Check-in of a new iteration
>
> This is not allowed for a released object - "Revise"
> must be used
>
>
>
> Since non-versioned attribute modifications, by definition, don't
> trigger a new iteration I can allow them at any life cycle state.
>
>
>
> As for the second part of my question, I still don't have a method of
> protecting a particular attribute for modification by permitted users
> only. Is it possible with customization to allow only certain users to
> edit particular non-versioned attributes and still have those
> attributes visible to all users as read only?
>
>
>
> Thanks,
>
>
>
> Mike Foster
>
> ATK
>
>
>
> *From:* Foster, Mike (Goleta) [
>
> • Non-versioned attributes: Modify allowed at all times regardless of
> release level
>
> • Certain non-versioned attributes: Modify allowed at all times but
> only by certain users or groups.
>
>
>
> In Windchill I'm trying to reproduce this functionality:
>
>
>
> The versioned attributes we want to restr...

[RussPratt]

Mike,

The "Modify Identity" permission may address what you are looking for. It does provide a different permission than "Modify" for non-versioned attributes such as Name and Number. I haven't looked at the details in a couple of months, so I don't remember exactly what things it controls.

Russ