User assigned license & last login report

[RK_11492709]

Using the attached QML, I was able to retrieve the users assigned to their respective licenses. However, the report is also returning the associated team roles along with the license or group names to which the licenses are mapped.

Do you have any suggestions on how to exclude all team roles from the report? Although the criteria section technically allows filtering out roles, it is not practical to identify every possible role and create separate criteria entries for each one.

[Fadel]

try this ,I used a dummy trick , all license groups starts with PTC:

[mmeadows-3]

FYI: To include all PTC license groups, including those not beginning with PTC (e.g. License Exclusion and Platform Structures), filter groups where their description includes the word 'license'.

[Fadel]

@mmeadows-3 

license exclusion is not a license group ,and  its intended to be used only for admins to test actions.

the "platform structure" that you mean  is also not a license one , the license platform license one has well  PTC in its name : 

[mmeadows-3]

@Fadel,  Thank you for adding to the explanation.  Here is a more thorough explanation.

License Exclusion is used in any scenario where a user account should not count against licensing.  That includes any person with multiple Windchill accounts (training, development, business configuration testing, dual-role administrators, etc.), and headless accounts used to connect PTC products to PTC products (e.g. publishing administrator).  Third-party integration accounts must be licensed.  Always follow up with PTC to ensure they haven't recently changed account licensing requirements.

Then there are scenarios where a user is a member of License Exclusion and a member of a 'PTC*' license group.  These need to be sorted out.

Most importantly, the OOTB site administrator account should NEVER be a member of any license group, including License Exclusion.  If it is returned in the report, it needs to be removed from all licensing.

Platform Structure has been deprecated for a while - replaced with PTC Platform Structures.  It still exists in Windchill systems and should not be in use, but we can't assume it doesn't still have users assigned to it.  If it is empty, it won't show in the results set.  If it is not empty, it's appearance in the results set prompts the report user to clean it up.

The full scenario wasn't fully explained.  Since the topic is reporting, the assumption is the requester is a site or organization administrator and may want to report on all license groups.  Our collective responses provide a level of report filtering.  Your response covers the license groups that pull a license.  My response expands to cover all license groups.  It is up to the reader to choose which is appropriate for their use case.

[Fadel]

Hi @mmeadows-3   , we can change the the report and add the constraint on group description containing  the string "license" as it is include exclusion group and other license  grp too : 

[mmeadows-3]

@Fadel FYI: I loaded your report in my Windchill 13.0 dev system and kicked the tires.

Notes:

1. The report complained that PrincipalType doesn't exist.  It doesn't prevent loading of the report in 13.0.

That attribute was added in 13.1.    Just need to remove the attribute from the Select or Constrain tab before running the report in 13.0 or earlier.

2. Reports like this only work for direct user assignment to a license group.  It pointed out where my dev system still had users assigned to license groups we no longer have licensing to use.

3. Many larger implementations add users to user-defined (org) groups that are then added to the (site) license groups.  There could be one or several intermediate groups between the user account and the license group.  I don't recall if it is possible for query builder to recursively navigate group relationships to return users directly or indirectly associated to license groups.  It might be possible with a custom reporting class that recursively navigates groups until it identifies license groups.

It is a simple request, but the actual report isn't easy.  I'm not asking for a rewrite of the report.  Just sharing expectations for this kind of report.

[Fadel]

  @mmeadows-3  you can edit the report and remove the type columns as below , file attached

: 

[RK_11492709]

Hi Fadel, 

Thank you for your update.

The last XML you shared is not retrieving the complete list of users. In our organization, the licenses shown in the screenshot are not assigned directly to user profiles. Instead, the licenses are mapped to specific groups (for example, the Design group), and users are added to those groups.

Because of this, your XML is returning only users who have licenses like PTC Navigate, while it is not retrieving users who inherit licenses through their respective groups.

Could you please help me address this?

[Fadel]

Hi, this is not my xml , its yours ,I just tried to remove the non lincense groups 

[joe_morton]

You'll have to update your report. Instead of reporting Users directly linked to the license group, you'll need to report users in a group in the license group. Ex: User -> Group -> License Group

Just keep in mind that once you make that update, the report won't return any information on a user who is directly assigned a license. Ex: User -> License Group

You'll also want to consider if you have subgroups. Ex: User -> Subgroup -> Main Group -> License Group

For the reporting to work, you may need to create several reports to cover all cases of license assignment that you use at your company. (Direct assignment, 1 level group, 2 levels groups)

The only other way (I know of) would be to create your own Java Method, and use that in your QML. That would be the way to have a single report that can recursively navigate group structures to get the final license assignment, regardless of how many group levels there may be.

[Fadel]

@RK_11492709 I agree with Joe the query builder doesn't do  any recursive calls , it reports only against tables and links in the report