topic Re: User permissions question in 10.2 in Windchill

User permissions question in 10.2

jhall2 — Wed, 02 May 2018 11:58:14 GMT

Hello,My company is working out a new installation of Windchill 10.2 We use Creo 2.0 along with it.We need our Users to be able to Reset Teams on our In Work WTParts, but not be able to Set State on those same, In Work parts. Our admin is telling us that the software won't permit

Re: User permissions question in 10.2

MikeLockwood — Mon, 25 Jan 2016 16:29:38 GMT

Not sure about Reset Team but suspect one has to be Admin or Manager of the context. It's possible that there would be an ACL to the Team object, but don't recall seeing.

Set State is enabled by either:

A) Administrator or Manager of the context (regardless of the lifecycle)

B) Set State transition in the lifecycle from the current state + Set State permission at the current state.

Re: User permissions question in 10.2

Nitin — Tue, 26 Jan 2016 08:37:26 GMT

In my opinion, you should address this with a specific set of users added to a new role created for this purpose.

Allowing designers to change teams as and when required can be dangerous at times particularly if you have to set limited access to certain data in contexts.

Also you might want to revisit your business process to understand if there can be other business solutions to the scenario you might be trying to address.

On a side note - Windchill workflows can be helpful here, since they can track your process and also provide ways to reset teams on fly.

Re: User permissions question in 10.2

jhall2 — Tue, 26 Jan 2016 13:58:16 GMT

Nitin

That special role sounds interesting. Could you describe what that might look like to me? Thank you!

Re: User permissions question in 10.2

jhall2 — Tue, 26 Jan 2016 14:13:30 GMT

Thanks Mike,

Do you think an ACL could be written to give certain users the ability to reset teams, but not Set State, or perhaps other Admin permissions?

James

Re: User permissions question in 10.2

kpritchard — Tue, 26 Jan 2016 14:36:02 GMT

James,

Modify Team is a separate permission from Set State and can be set for Object Type by Role and State in the Policy Administration Utility, and should allow the specified User Role to add and remove members. Reset Team would be a re-imaging and may not be what you're after. I would recommend testing in a non-production environment to be confirm desired behavior.

Re: User permissions question in 10.2

jhall2 — Tue, 26 Jan 2016 14:49:25 GMT

Thank you Keir.

Our processes set a default team on new parts, and that team is often not the team we want. So, in the past, Designers simply reset the Teams, and went on. We also add and remove members of that team, once in a while as well.

Since we have upgraded to 10.2 that is no longer possible without the Set State function as well (according to our Admin).

I am wondering if we could write an ACL to create a new Role with permissions to Reset Team, and no permission to Set State. I think that is what Nitin was suggesting above, with the idea of a specific new Role.

Re: User permissions question in 10.2

Nitin — Tue, 26 Jan 2016 17:09:49 GMT

James,

Reset Team requires administrative permission in order to be used. I am not sure about pre-10.2 behavior, but for 10.2, this is the case. I was expecting that the validation logic for 'Reset Team' action will itself be hidden for non administrative users, but digging into code, that's how it's implemented.

Administrative permission will grant set state implicitly,

You can decide to create a Windchill role, add users in that role, and make that role as Context manager. In that case only users in that role will be allowed to change the team.

If I map this activity to the real world, and if I am a designer, I can't decide myself to change the team of my design on which I am starting to work. I will have to approach my Design/R&D Manager to place a request to change team based on skill set requirement for my design.

It's same for Windchill. Consider Context team to the real team.

I can understand also it sounds easier than actually being implemented as such exercise will have organization impact with additional responsibilities and resources but from my experience, this will pay you back as you start mapping your business processes more into the PLM world.

Else the only option I can see is creating two users for each designer - one normal with basic privileges and other .admin with additional privileges. When they have to do rest team, they will in that case use .admin user. I honestly will not like to do that for this business case.

-Nitin

Re: User permissions question in 10.2

ehuffman-3 — Tue, 12 Apr 2016 00:11:30 GMT

James,

I assume you have different teams because the parts are being processed through a workflow? If so, you can reset your teams programmatically using standard APIs. Which team to use would have to be based on a determined logic. You can also configure use unique roles and only have one team. This would allow you to reset the target role of a task based on the requirement, using the specific role required. For example, Q1, Q2 and Q3 are unique Quality roles and Q is the target. Mapping either Q1, Q2 or Q3 members to Q can be done based on any configured logic (i.e. Soft Type Attribute or any combination of such).

You can allow any Assigned Task to be a task allowing the mapping of principals to a role. I believe the Change Request and Promotion Request both provide an example.

I know there has been other comments regarding your question. The truth is, WC is versatile, configurable and even customizable. There is always a way. Mine may not even answer your question.

To your original question:

wt.team.TeamHelper.service.reteam (wt.team.TeamManaged object, wt.team.TeamTemplateReference teamTemplateRef)

This is basically the API that will reset your team. You just have to fill in the gaps.