One of the things that had me scratching my head the first time I saw it was why you have to define both a User and a Person for every account you add to Teamcenter. And I know for a fact that I’m not the only one who’s had that question. For an in depth, detailed analysis of why Teamcenter has separate User and Person objects, continue reading…
…actually, I was just teasing. There’s not that much to say about it — not every topic we cover here has to take 2,000 words to explain.
Let’s start by defining our terms:
A User is someone who can log in to Teamcenter. User’s have an login ID, a password, a default group to which they log in, groups to which they belong, may be flagged as active or inactive (as in, can they log in, not how sedentary are they), and may have certain data access rights (ITAR, Government clearance, etc.). And in addition, a User is linked to a Person. So, what’s a Person?
A Person lists thing’s like a
person’s human being’s (ever notice how hard it is to describe some words without using that word?) full name, address, email address, and phone number.
Okay, great, but why couldn’t we just include all that information in the User record? Why do they make us create both?
It’s actually quite simple. Teamcenter separates Persons from Users because there may be people who are not users at all and therefore don’t have a user account, and other people who have multiple user accounts. What kind of people are these, you ask?
People who are not Users
Why would you bother creating a Person record if that person doesn’t also get a user account and can log into Teamcenter? Well, perhaps they work for a supplier who doesn’t have access to your Teamcenter instance, but you need to email them an update when designs reach a certain maturity level. You create an Person record for them, which includes their email address, so that you can send them information, perhaps at a certain step in a workflow using the
CR-notify handler with the
-recipient=person:person's name argument, but you don’t create a user record for them. Another example might be managers who work for your company but don’t need to log into Teamcenter (and thereby consume a license), but still want periodic reports sent to them.
People with multiple user accounts
On the other end, you may have some users, typically administrative users, who need several user accounts. They probably would have one “normal” account, but instead of giving that account DBA privileges you could assign a separate user ID with DBA access. Another typical case would be “functional” accounts which aren’t used by a human actually logging into a terminal, but are used by automated processes which need to access the system. For example, I’ve written code for migrating legacy NX data into Teamcenter which used a functional account which had special privileges not granted to any other user account. In this case, we assigned the functional user ID to my Person record so everyone knew who was responsible for that account. Alternatively, we could have assigned it to a fake person record named something like, “Functional User”.
And that’s about it on that. Any questions? Did this clear things up a bit? Let me know.