Purpose of /System domain at product level

[DarrenStorey]

Is anybody able to enlighten me to the purpose of the /System domain at product level?

The parent /Private domain at organization level I get (I think). For private products this becomes the parent of /Default domain at product level.

Out of the Box the /System domain is a child of /Private for products, libraries, projects and programs and this is the case regardless if the container is part of a shared team, or marked private or public.

When do the /system rules at product level come into play? To take just one specific example out of the box /System contains a rule to grant all permissions on cabinet to teamMembers, which I can’t explain as the cabinet is associated to the /default domain. Hence it would appear to be redundant.

[shussaini]

Excerpts from the WHC

>>>

Serves as the default domain for most system administration objects, including queues and life cycle definitions. /System is the default domain of the Administrators group.

The /System domain is not intended for general user business objects.

<<<

Check description about other domains here.

Hope this helps.

regards
~Syed

[DarrenStorey]

Syed,

That moves me forward a bit thanks.

All the default groups are associated to /User/Unaffiliated with the exception of the

Administrator - /System (site)

ORG ADMIN - /user/{org name} (organization)

This is perhaps not connected with /System (product) though.

I see there is a cabinet in the /System (product) called Administrator and it appears the product level templates at least reside here. I presume therefore that the product context team members need read permissions on the cabinet in /System (product) domain and read access to the templates within so they can initialize template instances. Is this correct?

Thanks

Darren