Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
Try the following,
Create a new site admin user (please don't mess with wcadmin, or you may get into a spot you cannot readily recover from), remembering to add that user to the Administrators Group.
Create Deny Read rules in the Org Default Domain, and possibly the Org Private domain, for the objects; Project2, Library and PDMProduct. This will "hide" the application contexts themselves.
Create Deny Read rules in the Org Default and Private domains for the business objects; docs, parts, etc. that you do not want the admin to read. Don't use WTObject, or you may well get behavior you don't want.
You may have to vary the exact domains in which you create the deny rules depending on whether you want the site admin to also act as org admin. The example given may be overly restrictive for an org admin, but you could move the rules down a domain level.
Keep in mind though, that there may be some administrative UI's which still expose the application contexts to some degree. Policy Admin comes to mind.
Again, do NOT restrict the primary admin user, wcadmin, in this manner or you will find yourself in trouble at some point in time.