Site-Admin differences between HPE/MicroFocus Saas and On-Premise assigning Users/Security on Projects?
Question ID: 108481

We recently switched from HPE/MicroFocus Saas to On-Premise (local).

What is the process for assigning Users/Security Groups now?
We used to have a nice table with the SaaS Admin tool (not Site Administrator, but similar) where we could just select various users and check boxes to assign which security group(s) they were assigned for the project.

Now it is different with this other (i suppose for local installed users the "regular" way) site admin tool.

Marked as spam
Posted by (Questions: 99, Answers: 7)
Asked on July 10, 2018 3:24 pm
Answers (1)
Private answer

Since you were previously using the ''alternate'' site Admin Tool supplied by MicroFocus for SaaS (Software as a Service/HPE-MF hosted/cloud), there are a few differences as compared to the ''regular'' Site Admin for ''on-premise'' or the ''regular'' load of QC/ALM installed locally on your corporate servers.

On the Site Projects tab, the project groupings in Site Admin are called ''Domains''. These are just a way to organize the list of projects and possibly to assist users in finding a project in a long list of projects.
Out of the box, it comes with one domain called ''Default''.

You can create as many as you want and they result in a separate folder in your repository.

The basic expectation is that a given project has it's repository tucked under the same folder related to it's Domain as seen in the Tree. For instance a project in the ''Default'' domain in the project tree seen in Site Admin should have it's corresponding repository folder UNDER the repository folder called ''Default''. You can find the full path to the Domain by clicking on a domain in the Project Tree and looking at the tab to the right.

So, if you copy a project repository into QC from another system or a backup, place it into the position below it's respective ''parent'' domain folder -- this will limit confusion later.

Then when you RESTORE a project, make sure to select the same Domain as the folder it's repository lives in.

Now, for assigning people to projects and which security ''groups'' they belong to in the project, this is done in TWO places:

1) You can put people on a project (give basic access) from Site Admin, but this only allows you to assign them to ONE group explicitly, the TD Admin role/group. If left unchecked (as it should for 99%), they are in the list of project users, but not assigned to any security group from that project.

2) To assign users to a project (they can login to it) from WITHIN a project, you must login to the project as a TD-Admin user (either by being assigned from Site Admin for project, or by being member of TDADMIN group on project). Then from Customize you need to find a user from your list of project users (sometimes from the ''site users'' list) and put them in at least one group, they inherit the security permissions from that group. If someone is in more than one group, it results is often confusing ''composite'' security, so if you can, put a user in only one group and adjust the group security to relate to user ROLES (like project manager, tester, lead tester, etc.). You can either assign various users to a group, or assign groups to specific users (same result either way).

Marked as spam
Posted by (Questions: 4, Answers: 509)
Answered on July 10, 2018 3:26 pm

Welcome back to "EyeOnTesting" brought to you by Orasi Software, Inc.

Scroll to Top