I agree that in theory it should be possible for HP to add this functionality. Unfortunately, In practice this is something different and the current method is the recommended. The design idea is that only a select few have admin capabilities to limit the possibility of too many changes being made and not being documented correctly or followed up on correctly, as well as those with admin rights will ''supposedly'' have the necessary skills and training to administer Quality Center.

For changes such as enabling version control, once it is enabled you would not want to disable it (unless preparing the project for upgrade) as this will delete all of the previous version history upon re-enabling it. Adding and deleting users from projects can be accomplished within the individual projects to contain this functionality. Projects usually aren't created at such great lengths that it would facilitate the need for a special role of that sort. (These suggestions are just some of the reasons that the need for this level of hierarchy is not really needed).

The other issues that can be presented through different levels of admin, those accounts should be admin accounts only. If you assign the user accounts to multiple groups (ie admin, tester, viewer, etc) the permissions can be assimilated from one group to the next and strange occurrences in user permissions can occur.

Regarding your last paragraph

> The other issues that can be presented through different levels of admin, those accounts should be admin accounts only

I don't understand your point there. The ability to create projects is available only through Site Admin. And the ability to create users at the Site level (with LDAP authentication enabled) is also only available through Site Admin. These are two relatively simple and innocuous tasks that could be assigned to somebody who would not also need to have the ability to manipulate Site configuration parameters, modify database or application servers, change log levels, or change the authentication parameters. But granting those rights is an all or nothing proposition. Those rights can't be granted to users through assignment to a user group in a project. And, back to the original point of my post, we can't grant levels of Site Admin access.

In our situation, for instance, only two people are fully trained to understand the ramifications of modify Site Configuration items, changing authentication settings, and modifying the database and application servers. We don't want those two people to also be the only two people (for an organization of thousands) with the ability to create users and projects. So, we grant Site Admin access to a small additional group of users. There is nothing preventing those additional users from modifying other data, except that we've told them not to. Luckily, so far, they have complied. But there is no pre-built way for us to prevent them from doing things they shouldn't, except by creating interface applications and then removing those users from the Site Admin group.

Also, at this point the Site Admin module ''documents'' the changes only through the log files, which in my opinion is grossly inadequate. It can't be effectively parsed or reported against. I've noticed that there is an Audit table in the Site Admin schema, but it remains obstinately empty. I've asked on other forums about auditing SA activities, and everybody says all there is is the log files.

Just my humble opinion. Always open to an energetic debate :)

I'll try to clarify the point I was trying to make regarding admin accounts. The user accounts should not have multiple roles and be admin accounts solely. When multiple roles (viewer, tdadmin, developer, etc) are assigned to an account then oddities can develop (and usually do) around the permissions assigned. When multiple groups permissions are assigned then the permissions assigned are not guaranteed to be correct as sometimes permissions can be blocked or cross migrate from one group to the next creating a situation where the permission desired are either not fully granted or not limited correctly. It is best to have these user accounts that are to be admin privileged to be admin accounts solely and not serve the purpose of dual roles (such as admin and developer) to eliminate unwanted permission allowances or omissions.

I agree that it is hard to have only a few people responsible for the entire operation (even the menial tasks) but by doing this it eliminates the possiblity of things being messed up/ changed and the person responsible for the change not being able to repair the issue due to lack of training. It also insures that the lack of documenting of changes doesn't allow for errant changes without responsible parties being notified or having knowledge of the changes (or errant changes being made unknowingly). I agree that the lack of fail safes is not very prudent, but this is the design reason and the reason to limit the staff the capabilities to the trained and responsible staff members assigned (As the old adage goes: ''too many cooks can spoil the stew'').

Your answers are correct in that the log files are the only means currently. Unfortunately, this isn't always enough but it is all we have at this time.