cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Set User to inactive on Production Environment

Set User to inactive on Production Environment

Allow for an administrator to set a user to Inactive on the Production environment without forcing the updates through the staging environments

8 Comments
Aquamarine

Hello,

for this request what do you think about this workaround:

  1. Create a groups disabled
  2. Create a global Permission  "Login not allowed" for that group
  3. Add the user to that group

This user won't be inactive (== can be chosen in issues), but he can't login any longer.

Gravel

Paul Hartwig‌ Thanks for submitting this idea. However, Administrator access is maintained at 'Read-only' level in Production environment in "Staging -Production" concept. Allowing users to explicitly enable or disable any of the features/capabilities in Production, would be against this concept. For that reason, I am marking this as No Plans to Implement in future.

Amethyst

I think answering this request with the general (and current) implementation of the staging-production concept is missing the point. In effect, you are saying "we cannot change it because that's the way it is". What we have learned over the years is that the current implementation is too strict, mainly because it was done more than 10 years ago and rarely improved (as of 10.9 for me).

In this case, this request is part of allowing to do user management in a way that's closer to reality: every user is supposed to have access to the production system, but most don't have access to the staging system. There are other similar and related requests that I'm sure PTC is familiar with and they should be reviewed as a whole.

Just to chime in, to give a little backstory on this;

Back when Integrity 10.5 was released, we did relax *some* Admin Staging constraints when it came to administering Integrity users and groups directly on production servers, as customers were asking for some of that, and had some obvious needs to do so.

The user being active/inactive, did not come into play with that - perhaps because of admin staging constraints that could not be overcome?  I cannot answer that.

But some things were relaxed, in that we did allow (and still do), the following operations directly on production:

- importing new users from the underlying authentication realm

- modifying user metadata (full name, email address, description, image - not active/inactive status though)

- importing new groups from the underlying directory service realm

- modifying group metadata (email address, description, image)

- deleting un-referenced users or groups

Gravel

Thanks for your responses folks ! Looking at the different scenarios, I believe it's a good idea to get into a call sometime in June and deliberate more on this requirement. Let's keep the discussion focussed on needs regarding the issue mentioned here. I'm going to change the status back to 'Open for voting' to see if any other customers would like to join the conversation.

Hi Paul,

I did a review of this idea, and I want to know why the answer from KHoppe did not fulfill your request.

 

The actions are as follows:

  1. Create a Group "Inactive Users" as Domain group,
  2. Import it into W&D
  3. Set the permission to "Login disabled" in W&D
  4. Set the permission also on Config Management to "Login disabled"
  5. Now, when you add any user into the "Inactive Users" group, this user can not login to Source / W&D anylonger.

This solution is not effected by the staging mechanis at all.

 

Please check this solution and tell me if it is sufficient to solve the use case you described at the beginning.

Thank you

Volker

Regular Member

I support this request and also I disagree to the offered workaround.

 

We already have that concept in place to block users from logging into Integrity by the help of a domain group (user ids get pushed in there after 90 days not logging in). But this does not solve another issue with users no longer working with the company or changed positions. 
In case no longer available users are still assigned to active items this could block further processing of these items.

For example in our solution we have separate tasks & review data types being related to each other and triggering automated state transitions.

A very common conflict scenario at our end was that a user assigned to a Task finished is implementation work and pushed it into review state.

This triggers a Review item where a second user has to perform the necessary review activities. When he has finished his review work he closes the review and also the Task item is then triggered to it's final state. This last trigger often failed in case the review took place a longer time after the Task was prepared and the assigned Task user has left the company in the meantime. In that situation the trigger to push the Task to it's final state failed, hence also the active Review user was not allowed to finish his review work. 

The only way out is to deactivate the im user entry for that already left Task user. 

In a staging server environment you have to migrate that im user deactivation.

In our case we have even 2 staging server in a row before we push changes to production. So we have to perform migration steps even 2 times for every change.

Hence it would be of create help to be able to deactivate im users directly on production even within a staging server environment.

 

This would also be of help to improve our scripts & automations as we are able to filter automatically which users left the company.

But when it comes to migration we always have to do that manually.

 

Hence this change to control it directly on production server would save a lot of manual process steps and increase implementation quality as less manual interaction is needed.

 

 

 

Aquamarine
Status changed to: Acknowledged