"whoami" function for users to find out dyn. group membership in item context

[mrump]

It would be nice to have function for users that can show them their dynamic group membership based on a selection in item's context.

In a complex setup with several "process roles" based on dynamic groups its its often hard to find out e.g. why some state transitions are not possible.

[KartikOak]

Hello Matthias,

                        I was reviewing this Product Idea, can you please elaborate "on a selection in item's context"? Can you please help me with a use case or workflow that you are going thru where you would need this & how does this information help you in your daily routine?

Thanks

Kartik Oak

[VolkerEckardt]

Tag	Value
Status:	Reviewed by PTC Community Member
Main Category:	Integrity Lifecycle Manager Administration
Sub Category:	Users and Group Management
Related Working Group:	Integrity Lifecycle Manager Administration
Standard Functionality validated:	API, CLI
Standard Functionality available in Release 11.2:	Limited
Workaround exists:	Yes
Workaround Description:	A custom report has been created that will list the dynamic groups where the user is assigned to.
Workaround match:	60%
Other knows solutions:	Pull out all group details using CLI or API, and analyse programmatically the dynamic groups. But this approach is quite complex, and you would always read data which you don't need to answer this question.
Related other Ideas:	none
Related Questions:	none
Related Tips:	Administration Configuration Reports
Next review Milestone:	01/11/2018
Workaround Details
Please see this post from the same author.

[BKroell]

For IM it is almost impossible to understand the dynamic groups concept for the end-user.

In our solution many state transitions are multi-dynamic groups. Also users are assigned to many groups and mapped to multiple dynamic groups.

Hence the end user often does not understand why he is allowed / expected to work on one or the other item because of this multi-assignment.

A user expects a clear indicator out of what role / group he is now allowed to work on this element as this context would help him to understand the expected process step.

Also the item type workflow information is inconsistent as constraints are not evaluated within the workflow view.

This adds another level of complexity for the end user. A normal user has no chance to understand why a solid line (which is an allowed state transistion) in the workflow view is sometimes true and sometimes wrong because of a not visible field constraint the editing user is not satisfying.

[olivierlp]

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.