Using Profiles to cleanize the UI

[hvaradharajan-2]

Hi all,

We are looking at the "Profiles" functionality as a means to control the UI visibility.

I was reading through the documentation that the context specific "Configure Actions for Roles" will over ride the Org wide profile settings.

The documentation reference is below.

Default Visibility for Application Context Managers

The site and organization administrator can choose to set defaults for and hide control over a specific product, library, project, or other application context action or user interface element. That is, the site and organization administrator can carefully control which elements that application context managers (project, product, and library managers) are able to override in a context instance.

Removing the ability for an application context manager to override a profile setting is done by globally hiding visibility to the Configure Actions for Roles action for a specific context. If this is done, then the visibility of actions and areas of the user interface in a context instance cannot be modified by that application context manager.

It seems that on already created contexts, applying the profile settings seems to be  a challenge.

All I want to know is that a simple way to disable the Context setting for the UI for Roles, so that my profile setting at Org level is activated.

Is there preference or property to achieve this?

Any good practices on profiles? Dos and Donts?

Best Regards

Hari

[MikeLockwood]

I've used Profiles extensively for many years in multiple Windchill systems.

As you state, they are helpful to "de clutter" / simplify the UI by removing functionality / icons not currently in use - not intended to be used as an access control mechanism.

In general, configurations as Product/Library level override those at Site or Org, but Profiles don't override - they are additive.  Think of them as clear sheets laid on top of each other, and they may exist at Site, Org, Product.  For every action, if any Profile has a checkmark, then that action is displayed.

You can apply Profiles to principals in various ways; I've always come to the conclusion that it is best to apply to Org level Groups, but there are pro's and con's to this.

For sure, create some test user accounts and apply Profiles to them and test.

[doehr]

It's also worth noting, that very function "Configure Actions for Roles" in the contexts, it has no settings within itself to control access to itself. The main way to control access to it is through Profiles.

Yet another thing worth noting is that there are different settings available between the two functions.

For us I've found the best use of Profiles is with just two of them; one for a standard user and one for administrators. First main difference that you might have guessed, standard users don't get access to the Configure Actions for Roles function. But they get a good healthy chunk of options set up, and keep in mind, this just controls which action buttons they see on the menus. The Policy Administrator also has to match giving someone (ideally by role) access for them to actually use those functions, so with a standard Profile for buttons combined on top of access controls by role you really shape how each user can work in the system.

Daryl