Clarity

Having just established how partition configuration defines which view and data is used for displaying the resource properties view in the application

see

Resource edit properties view cannot be modified

I am wondering How is the resource partition field  value achieved?

When creating a new user/resource the partition is not a field in the create views as far as I can recall.

In the user properties the partition data is read only and you have to go through the partitions and the membership pages for direct user membership or it may be inherited through group memberships or OBS associations.

In practice that means that multiple memberships are possible as per design.

Now I should like to know which one if any of these goes into the resource properties (ODF_CA_RESOURCE.PARTITION_CODE) or is t hat NIKU.root by default until expressly changed in resource properties (or in the list view) or is the more than that to it?

The partition code on the resource object is more for the purpose of what data rules and requirements are to be imposed on that resource as a record (e.g. certain partition specific attributes and view definitions).

It's separate from the concept of a user having membership to a partition (or multiple partitions) in order to then access/create data within them, as managed through Administration > Partition Models > Partitions [properties] > Partition Members.

So any record in the system can belong to a single partition for the purposes of view/attribute setups, and the resource object is not really different to the project object in that respect.

Therefore I would agree with your closing sentence that the Resource ODF_CA_RESOURCE.PARTITION_CODE will be NIKU.Root by default until expressly changed in the resource properties.

In order for the partition column to not be read only, you would need membership to the partitions for the user you are logged in with, and for the Resource object to be assigned to the partition.  There should be more than one active partition in the model (within the active partition model) in order to have a 'choice' when creating new resources or editing the partition browse field as to which they will be set to.

Thanks nick_darlington

I've been looking at documentation, CA World Presentations since 2004 and third party materials and they cover mostly how you created partitions. They are lighter on the side of what exactly you do associate a record with a partition and what steps you need to do so that the user can see that particular record through the views defined for that particular partition and the discreet values in that partition.

Your answer defining the two things needed

"The partition code on the resource object is more for the purpose of what data rules and requirements are to be imposed on that resource as a record (e.g. certain partition specific attributes and view definitions)."

and

"It's separate from the concept of a user having membership to a partition (or multiple partitions) in order to then access/create data within them, as managed through Administration > Partition Models > Partitions [properties] > Partition Members."

makes it clearer for me.

It has been stated that partitions are not security, but those two things sure behave a lot like permissions.

For us that need more education on this a Tuesday's tip or a Cookbook article on this would be  welcomed

There are 2 concepts when talking about "resource" for CA PPM -

The User = the profile/person that logs into CA PPM; the user can become a member to 1 or more partitions.  This allows them to "see" visually different layout of data on objects that have been partitioned

The Resource = this is the data instance describing the workforce or non-labor resources and the Resource is the entity that gets managed by Resource Manager on their assignment to task, or allocation on a project (not the user).

So if you go with these definitions, Nick's comment is applicable to the User, ie When you look at the user (from Admin Tool -> Resources), this is where you are assigning access rights and partition membership and defining what visual experience a person would have when logged into CA PPM.

The partition works in conjunction with access rights.

Example:  User Jane Smith is a resource manager for IT Network organization.  She needs to be able to edit resources within IT Network group (all IT Network resources are associated to the "IT Network" department OBS unit).  CA PPM has been setup with a partition and there is a partition called "Network", where for any resource record created and associated to the "Network" partition, there is a specific code that has to be tracked within CA PPM and it is a reference to an external system that all network resources use.  Only Network resources have this ID, no one else within IT does.  So under the "Network" partition, the resource properties has a custom attribute defined called "Special Code" and has been configured to display on the Resource - General Properties page.

As a user, Jane Smith needs "Resource - Edit" right to be able to actually update network group resources (or she can inherit this right by being named the Resource Manager on individual resources).  Just being a member of the "Network" partition, will not give her editing rights on a resource.  So Jane Smith is actually assigned to the "Resource Manager" group where she gets the "Resource - Edit" right.

By being a member of the "Network" partition, as she navigates into a resource record that she has rights to see, she can see a field called "Special Code" appearing on the Resource - General Properties screen.

And so, a User can be a member of 1 or more partitions.  A resource (instance), is associated to one partition code only.  And  if a user is tied to multiple partitions, when the user look at a resource instance, they can choose what partition-view they would like to see the resource record under (it is part of the selection under the Action dropdown on the list view).

I hope that helped explain the differences.

The question was main about how you associate the resource to a partition.  nick_darlington *s confirms what I had already experienced in practise.

What is confusing is comparing what you pasted above

" And so, a User can be a member of 1 or more partitions.  A resource (instance), is associated to one partition code only."

and things like

TEC569561  Scenario: How to Set Up Partitions

which says

•   A user with Studio access rights can be a member of more than one partition within a partition model. However, when the user creates an object, the user selects the partition to use. For example, a user can be a member of the U.S. and European partitions, but the user selects one partition to use when creating a project.

•    Users can be assigned only one partition and therefore do not need to select a partition.