Deactivated Users: What restrictions are forced by adding a user to the Deactivated Users group?

[Prabhu]

Hi,

Adding one more thread on "Deactivated Users" topic.

Refer article CS167448.  To deactivate a user, do below:

• 1. Create Site level group:
     • Go to Site > Utilities > Participant Administration
     • Select Create new group and set the name to any value (e.g. DEACTIVATED)
     • Add users that you want to get marked deactivated to this group
  2. Set the property:
     • From Windchill shell:​

xconfmanager -s wt.org.ReportRegisteredUsers.group=DEACTIVATED -t codebase\wt.properties -p

• Restart Windchill

I need to understand what restrictions are forced in Windchill system just by adding a user to the Deactivated Users group.  Do I need to define any specific ACL in addition to this?

By adding a user to this Deactivated Users group, what this user WILL and WILL NOT be able to do in the system?

Thanks,

Prabhu.

[ScottMorris]

This is an interesting topic and the DEACTIVATED group is a feature we are not currently using. Instead, we put a prefix on the user name (X-) and move them to an ORG named DELETED. If the user returns, we can restore their original username and move them back to the company ORG. Moving them into a unique ORG takes away all the permissions granted by the company ORG. I am also curious what restrictions, if any, are applied by using this configured DEACTIVATED group.

How are others dealing with "leavers" in Windchill?

[Prabhu]

Hi @ScottMorris 

Thanks for the response and your approach is a good one too.  I see each organization / administrator had devised their own ways to cater their needs.

There are other threads on this very topic in this forum which you might find interesting:

Windchill Deleted / Deactivated User Process - PTC Community

Deactivate users - PTC Community

and so on..

Since the mechanism behind the Site level "Deactivated Users" group is officially recommended by PTC, probably they have built better ways for administrators to manage:

• Access control
• User management (deactivating, reactivating, etc.,)
• Membership management (Windchill business groups, Context Roles, License groups, Profiles, etc,).
• Other points

I want to understand on these aspects:  What are the things that gets into force if we move a user to this "Deactivated Users" group.  What else then we need to perform?

Inputs and Comments please..

Thanks.

[MikeLockwood]

Important to also evaluate where a deactivated user appears in UI's that a user can use to select that person (e.g. assign for a workflow task, add to a Product context Team, etc.).  Should be very clear that the deactivated user not be selectable for these - but be able to reverse this if that user is re-activated.

I think that there is a great opportunity for PTC to do a much better job of addressing this in general.

- In general, the number of users for any system will grow without limit

- the norm is that the user is deactivated and never re-activated

- the exception that occurs often is that a deactivated user is re-activated (e.g. a contractor returns)

The procedures for this should be simple and explicitly spelled out by PTC.

[HelesicPetr · Accepted solution]

Hi @Prabhu 

The group DEACTIVATED do not strict any access. The group is just container for deactivated users. 

The users in the group are just ignored for a PTC license reporting and are not count as active user.

An access restriction is administrator job to remove users from any other groups teams and org.

If you want to restrict access then you can create an ACL rule for the DEACTIVATED group to deny all access for WTObject. 

PetrH 

[Prabhu]

Hi @HelesicPetr 

This is exactly what am looking for..!!  Thanks a lot for your explanation.

Prabhu.