Remove hard coded restrictions from all roles

[ptc-4482159]

Last week, I encountered two separate instances where hard coded restrictions were developed into Windchill 10.1 roles in regards to some permissions that were previously available to provide to these roles via the Policy Administrator in ACLs in 9.1.  The two examples are:

1.  Guest Role - We can no longer simply provide someone with guest access if that user needs to read / download Creo data to view.  The Guest role now has a hard coded restriction preventing the user from creating a workspace within the respective context.  Users that already existed in a previous Windchill version that have already created workspaces within these contexts are still able to use those existing workspaces.  New users provided with this access cannot create workspaces and thus encounter an error when attempting to register Creo to Windchill.  A custom role has to be designed as a work-around.

2.  Product Manager / Administrators - A user must be a Product Manager or an Org / Site Admin to be able to view task details within the respective context's task page.  No matter what permissions are supplied to other roles / groups / users through ACLs (even full control to WTObjects at all states), only specific roles can click on the name of a task to enter the task details and view related information (Notebook, etc.).

I'm sure I will encounter more security nuances as I go, but the product idea here is simple:  Remove all hard coded restrictions related to roles and allow business and system administrators the ability to structure the security according to their business needs.  Make all permissions run through ACL entries.  I don't think the application should be dictating how the customer functions.  The application should be flexible enough to allow the customer to mold it to fit the needs of the business.

At a very minimum, warn us and document the hard coded restrictions so that customers can plan accordingly and not have to stumble across these in a Production environment.  Work-arounds for these types of issues are difficult to implement and make the system much less user-friendly, which was one of the goals of the new 10.x interface, right?

Thanks.

[DavidCobb]

This issue has been one of the most challenging to deal with in the business process impact of our recent PDMLink 10.2 implementation. We would very much prefer to see the capabilities available to Product Manager and Org Admin available to assign to roles as separate, individual permissions so that we can have more flexibility in determining the best range of roles to support our business processes.

For example we want a subset of business users (vs. an IT support team/Help Desk) to be able to:

• View and reassign Promotion Request workflow tasks assigned to other users
• Undo Checkout for an unavailable user
• Delete objects that have been added to other user's Workspaces

These fundamental elements of managing work in a dynamic, global resource pool, yet we don't want those business users to have the other elevated privileges of Product Manager and Org Admin like editing user accounts, assigning roles (we have a global account management process), creating/removing contexts, bypassing business process validations we've configured in the system, etc. It would be extremely helpful if we could effectively configure roles with the full set of capability/permissions applicable for our process.

[joe_morton]

Hi,

I'm a new Windchill admin and I'm having the same issue. I hate that undo checkout permission is bundled together with Administrative rights. I'd like to see this as a nested set of permissions so I could see everything included and only assign what is needed (like undo checkout).

[slapha]

Ran into a new issue on this just today. Only an administrator can unlock a package (which includes the Product Manager role). The package is in work, not delivered. There should be no reason the originator shouldn't have access to unlock the package at that point.

We're trying to push away from using Product Manager because of the extra access it gives users. For example the ability to delete and change items. We grant a different role team modification access, but then of course they are lacking in some of the controls they do need to manage regular items.

[kjurgens]

Another hard-coded restriction is that Guests cannot view AML/AVL. The hard-coded restrictions around the Guest role have made it all but unusable in our Windchill instance. I've requested documentation on the hard-coded restrictions on multiple occasions (since 8.0) and PTC has never been able to answer this request.