Unable to Create New Product/Library - Windchill 13.0.2.6

[BF_13811900]

Hi.

Was wondering if anybody can help. I am an admin of a new Windchill instance. I am a site admin and also an admin at two organization levels. My account is a "Product Creator" in one of these organizations. I am also a user listed in the table under "Participant Administration" at the organization level. My account is a member to the "PTC Windchill Base License" group and is also assigned to the "PTC Windchill Administrator" profile. The license profile called  "PTC Windchill Base License" is enabled and the system is recognizing that I'm consuming a license. I have Windchill PDMLink installed. Yet, I am still unable to create a new library or product. The button simply isn't displaying when I go to "Recent Products" > "View All".

Can anybody explain what I am missing please?

[Fadel]

if you are added to administrators group, you should be able to create products with no license groups if you are part of an organization 

[BF_13811900]

Hi Fede. That's my understanding of how the software should work. But unfortunately I am not seeing this behavior despite being a member of the "Organization Administrators" list that can be accessed by selecting "Administrators" under each Organization! 

[avillanueva]

Let's try this, Go to the Product page where the action should exist. add "?jcaDebug=true" to the end of the URL. Send us what you see:

This should tell us what validator is hiding the action.

[BF_13811900]

Hi. Thanks for your support.

The validator is set to "com.ptc.windchill.enterprise.product.validators.CreateProductActionValidator". Whereas the top line of the text in your screen grab says "Enabled By:", mine is saying "Hidden By:".

[avillanueva]

Next step would be to enable DEBUG logging on that class to see more and then check MethodServer logs.

[BF_13811900]

Ok so I've done this. The MethodServer log produced these two bits of info:

com.ptc.windchill.enterprise.product.validators.CreateProductActionValidator *MYUSERACCOUNTNAME* - WTContainerHelper.service.canCreate: false

com.ptc.windchill.enterprise.product.validators.CreateProductActionValidator *MYUSERACCOUNTNAME* - createProductWizard: hidden

[rhart]

I suspect the problem could be the site administrator is not a member of the org or domain they are attempting to create a context in, but rather than change the domain of the site admin, I recommend you create a new user to test with.

Create a new user in the participant administrator, make sure the user organisation is set to the org where the new product or library will reside. Edit the user to check, the domain should be the same org. Add the user to org administrators, add the user to product/library creators, add the user to base license group, then try again.

[BF_13811900]

Hello. Thanks for getting in touch. My Windchill instance is currently linked to an LDAP server which is set to read-only. I cannot change this due to company policy. Consequently, it seems I have no ability to create local users in the instance. I can only import users from AD. Consequently, when I attempt to edit a user account, under the "Set Attributes" section, I am unable to assign a value to the "Organization:" field. I am able to change the "Domain of User:" field, but I can only change this to "Default", "System", "User" or "Unaffiliated". Aside from making the LDAP server not read-only. Have you got any suggestions how I could achieve what you have suggested?

[rhart]

Hi, user has to be part of the organisation they want to create the product in, as far as I know.

[mmeadows-3 · Accepted solution]

That was a good call by @rhart.

https://www.ptc.com/en/support/article/CS162556

https://www.ptc.com/en/support/article/CS231606

However, these picks won't work in a read-only LDAP.

Organization mapping is performed by JNDI Adapter (adapterservice.json) where the Site Administrator account is being read from LDAP.
If there is an attribute in the LDAP that matches the organization name, use: {service name}.windchill.mapping.user.o={AD: company, OpenDJ: o}
If there isn't an organization mapping attribute, use: {service name}.windchill.mapping.usersOrganizationName={Organization Name}

In a properly configured LDAP integration, the default site administrator is assigned to the Site unaffiliated domain by not setting a value to the organization attribute.  Other site administrators can be assigned to an organization.  I have seen issues when the default Site Administrator is assigned to an organization.  Here are some site admin best practices: https://www.ptc.com/en/support/article/CS361438

[BF_13811900]

Hi. Apologies, there's a few points you have made in your comments that I am a bit unclear on. I am quite new to Windchill administration and some of the stuff you have touched on is new territory for me!

When you refer to "Organization mapping", can I assume that you are referring to the mapping between the organization attribute of a user/group/organization stored in the LDAP to the appropriate fields against the user/group/organization participant that is stored in Windchill?

You have also said that "Organization mapping is performed by JNDI Adapter (adapterservice.json) where the Site Administrator account is being read from LDAP". - This should be the case for any account that is imported into Windchill, not just for Site Administrators right? So any account that is imported from the LDAP with no attribute that matches the organization context's name in Windchill will not be able to inherit a value to the "Organization" field? Any account that exists in Windchill that does not exist in the LDAP, such as "wcadmin" could have their Organization field updated as it has no relationship to an LDAP profile. Is this correct? I'm just trying to understand the relevance of your statement and how it relates to my issue and everything else you have suggested.

As it stands, it looks as if none of the participants that exists in my Windchill instance (including any Site/Org admins) have any value associated with the respective "Organization" field (the install was performed using an AD account). This has led me to conclude that this value is also probably not specified in our LDAP entries, otherwise it should be pulling through into Windchill. Based on this, can you confirm that I should be using "{service name}.windchill.mapping.usersOrganizationName={Organization Name}"? And that this is an entry I should be incorporating into the .json file you have made reference to somehow?

As it stands, the account used to complete the installation (I'm assuming this is the equivalent of the "default Site Administrator") is assigned to no Organization. But, the "Domain of User" field is set to "/System". Is it key that this is changed?

I've also noticed today that one of the users has no ability to see an Organization within the instance despite being an Administrator of the organization and being named in the "Participant Administration" table of the Organization. When he selects "Browse", he is unable to even see the "Organizations" icon which sits between "Site" and "Changes" for me. Is this likely to be anything to do with the issues I have reported above where user participants have no "Organization" attribute value set?

Thank for getting in touch. I'd be grateful for any response that will help me develop my understanding and resolve the issues mentioned.

[BF_13811900]

Hello. Since my last comment, I have gained a little more of an understanding of your last response. Since our entries in our enterprise directory have no attributes which match my organization context name, I have used "{service name}.windchill.mapping.usersOrganizationName={Organization Name}" as a property within our JNDI Adapter (to clarify, I have been sure to replace "{service name}" and "{Organization Name}" with appropriate values).

However, when I view users that currently exist in Windchill and import new users, their accounts are still not associated with any "Organization" value. Are you aware of anything further that needs to be done to get the updates to the adapter to take effect to existing and new users? For example, would the web server have to be rebooted?

[mmeadows-3]

You can try various things like purging the participant cache, but most likely you will need to clear the tomcat and info*engine caches and restart Windchill.

[BF_13811900]

Thank you so much for your help! In combination with your last response, this has resolved the issues experienced creating new libraries/products and users having visibility or organization contexts.