How to Customize Project in HP ALM (Quality Center)
⚡ Smart Summary
Customize Project in HP ALM lets a project administrator control who reaches a project and what each person may do inside it. This article walks through user properties, project users, groups and permissions, module access, project entities, lists, automail, alert rules, workflow, and the script editor.
What is Project Customization in HP ALM?
- Project Customization enables project administrators to control access to a project by defining the users who can access the project, and it also has capabilities to customise what type of tasks each user can perform.
- You can also customise a project to meet the specific requirements of your organisation.
- It also helps with adding and editing new customised user fields that can be added to each one of the modules in ALM.
Customisation is reached from Tools > Customize inside a project, and it is separate from Site Administration. Site Administration creates domains, projects, and site-level users, whereas Project Customization decides what those users may do once they are inside a particular project.
The Project Customization window is divided into the areas listed below. Let us look into them one by one.
| Customisation Area | What It Controls |
|---|---|
| User Properties | The signed-in user’s own profile details and password |
| Project Users | Which accounts belong to this project |
| Groups and Permissions | What each group may create, update, or delete |
| Module Access | Which modules each group can even see |
| Project Entities | System and user defined fields on each entity |
| Project Lists | The selectable values behind list fields |
| Automail | Email notification on defect field changes |
| Alert Rules | Alerts across requirements, tests, and defects |
| Workflow and Script Editor | Dialog layout and permitted actions per group |
💡 Tip: The product in these screenshots has changed hands more than once. It began as HP Quality Center, became HPE and then Micro Focus ALM, and is now published by OpenText as ALM / Quality Center. The customisation screens and the workflow scripting model described here remain the same.
User Properties
The currently signed-in user can edit their own profile details, and the page also allows the user to change their password.
Note: Only the currently signed-in user’s password can be changed here, even if the user is of type ‘Project Admin’.
Step 1) Click on the Tools link and select ‘Customize’ as shown below.
Step 2) The Project Customization dialog is displayed as shown below.
Step 3) To change the password of the current user, click ‘Change Password’ in the ‘User Properties’ tab.
Step 4) The change password dialog opens.
- Enter Old Password
- Enter New Password
- Enter Confirm Password
- Click ‘OK’
Step 5) The user will be shown the status message.
Step 6) The user can also edit the following profile details.
- Email ID
- Full Name
- Phone Number
- Click ‘Save’
Note: Users will not be able to edit their User Name, even if the user is of type ‘Project Administrator’.
Step 7) The status is displayed to the user as shown below.
Project Users
This module enables users to add and remove users for the current ALM project. You can also assign users to user groups to restrict user access privileges.
Step 1) Now let us add users to the Project area.
- Navigate to Project Users
- Click the Add User drop down.
Step 2) Upon clicking the ‘Add User’ drop down, the following methods are displayed to the user as shown below.
- Add User by Name – The project admin can add an existing ALM user to this project by giving their user name.
- Add New User to the Site – Add a new user to the site by entering all details, the same way users are added from Site Administration.
- Add Users from Site – Add an existing user by searching on their name or ID.
Let us see each one of these methods.
Step 3) Let us add a user based on name. Ensure that this user already exists in the ALM admin database, that is, a user created using the Site Administration module.
- Select ‘Project Users’ from the Project Customization window.
- Click ‘Add User’
- Enter User Name
- Click ‘OK’
Step 4) The added user is displayed as shown below.
Step 5) Now let us add a user using the option ‘Add New User to Site’.
Step 6) Upon clicking ‘Add New User to Site’ from ‘Add User’, the following dialog is displayed.
- Enter User Name
- Enter Email
- Enter Full Name
- Enter Phone Number
- Click ‘OK’
Step 7) The user is now added to the current project. The user appears in ‘Project Users’ as shown below.
Step 8) Now let us add project users using the option ‘Add Users from Site’. Ensure that the user is already in the ALM admin database.
Step 9) The following dialog is displayed.
- Enter the User Name and click the search icon
- The User Name is displayed
- Click ‘OK’
Step 10) The user is added to the project and displayed as shown below.
Step 11) The project admin can also remove a user from the Project Users module.
- Select the user
- Click ‘Remove User’
Step 12) A confirmation dialog is displayed. Click ‘Yes’.
Step 13) Upon clicking ‘Yes’ the user is removed from the project users list.
Step 14) Each user in ‘Project Users’ has a membership associated with it.
Note: By default, any added user has ‘View’ permissions only.
- Select the User Name
- Select the ‘Membership’ tab
- The membership for the selected user is displayed. The newly added user ‘Cathy’ has ‘Viewer’ permission.
Groups and Permissions
This module enables the project admin to assign privileges to user groups by specifying permissions.
There are 5 predefined groups in ALM, and each of those user groups has a different permission level.
- Developer
- Project Manager
- QA Tester
- TD Admin
- Viewer
Note: By default any user added to the project area carries only ‘View’ permission.
Step 1) Let us see the list of users in the ‘TDAdmin’ group.
- Select ‘TDAdmin’
- Under the Membership tab you will see users who are not in the group
- Under the ‘In Group’ section you will see the list of users within the group. In this case only ‘Admin’ is displayed.
Step 2) The predefined group permissions cannot be edited.
- Select ‘TDAdmin’
- Navigate to the Permissions tab
- Select any module (Defects in this case)
- The permissions cannot be edited, even if the current user is a project admin.
Step 3) The predefined groups cannot be renamed or deleted.
Step 4) In order to change a group permission, the project admin has to add a new group. Let us say we need to create a new user group whose members have ‘Edit’ permission for the Defects module and View permission for everything else. This means all permissions have to be the same as a ‘View’ user, except that the user should be able to update defects. To do this,
- Click ‘New Group’
- A confirmation dialog is shown to the user. Click ‘Yes’.
Step 5) Upon clicking Yes, the ‘New Group’ dialog is shown.
- Enter the Group Name
- Enter the profile it should be based on
Step 6) The user group is created as shown below. You can also see that we can rename or delete this group, because it was created by us. Predefined groups in ALM cannot be edited or deleted.
Step 7) To change the permission,
- Navigate to the ‘Permissions’ tab
- Click the ‘Defects’ tab
- Enable the ‘Update’ flag for Defects
- Enable the ‘Update’ flag for Links
Module Access
This module enables project admins to control the modules that each user group can access. This prevents users from reaching restricted modules.
Let us say developers have nothing to do with test cases. They can therefore be prevented from accessing the Test Plan and Test Lab modules.
Step 1) The default module access is shown below. All user groups have access to all modules by default.
Step 2) For demonstration purposes, let us remove all module access from the VIEW user type except the Defects module. Uncheck all the module access boxes against the View user except Defects, as shown below.
Step 3) Now let us log in using one of the ‘View’ user IDs to check that the changes have been applied correctly. From the snapshot below it is evident that the settings have been applied as intended, because only the ‘Defects’ module is displayed for the view user ‘Jim’.
⚠️ Warning: Module access and group permissions are two different controls. Removing module access hides the module from the menu, but it does not by itself revoke the underlying permissions. Set both when restricting a group.
Project Entities
- Project Entities enables project administrators to modify the behaviour of ALM system fields or define user defined fields.
- For example, if we are executing tests on various builds and we would like to add a ‘Build Version’ field in the Add Defect module, we can do so using the Project Entities module.
Step 1) User defined fields cannot be added under system fields, which are read-only.
- Select ‘Project Entities’
- Select ‘Defect’ and then the subfolder ‘System Fields’.
- Notice that we will not be able to add a ‘New Field’ or delete one, because system fields are read-only.
Step 2) To add a user defined field,
- Select the ‘User Fields’ subfolder under the ‘Defects’ module.
- Click ‘New Field’
- The field details appear as shown below and can be edited.
Step 3) Field details can also be edited as shown below.
- Rename the label to ‘Build Number’.
- Check ‘Required’, which means this field becomes mandatory when posting a new defect.
- Click Save
Step 4) Now we can see the change in the Defects module. Navigate to the Defects module and the user will see the newly created ‘Build Number’ field as part of the New Defect dialog.
Project Lists
- Project Lists enables project admins to add customised lists to a project. A list contains values that the user can enter in system or user defined fields.
- For example, the Bug Status list has six predefined statuses, namely New, Open, Fixed, Reopen, Closed, and Rejected. If we would like to add one more status, such as Duplicate, we can do so using this module.
Step 1) To add an item under a predefined list,
- Click ‘Project Lists’
- Select ‘Bug Status’
- Click ‘New Item’. The New Item dialog opens.
- Enter the Item Name.
- Click ‘OK’
Step 2) Upon clicking OK, the new item is created as shown below.
Step 3) Now we need to save the changes.
- Click the ‘Save’ button.
- A pop-up is shown. Click ‘OK’.
Step 4) Now navigate to the Defects module and verify whether the status field contains the newly added item. Adding a status also affects the defect life cycle, so agree the new value with the team before introducing it.
Automail
This module enables project admins to set up automatic mail notification rules, to notify users by email about changes made to specified defects. The automail feature is available only for the Defects module.
Step 1) To activate automail notifications, perform the following steps.
- Navigate to the ‘Automail’ link.
- The user can trigger email by selecting any number of available fields in the list.
- This grid shows the list of fields the user has selected to send mail about.
- The project admin can also select the email settings against each available user.
- Click ‘Save’.
Step 2) A pop-up is shown. Click OK.
Alert Rules
This module enables project admins to activate alert rules for the current project. This feature creates alerts and sends emails when changes occur in the project. It applies to requirements, associated tests, and defects.
Step 1) To activate alert rules,
- Navigate to ‘Alert Rules’.
- Enable the ‘Alert Associated with’ check box
- Enable ‘Send E-mail to’ and add the corresponding tester or designer.
- Click ‘Save’
- The first alert: the test designer is alerted when a requirement is modified, so that associated tests can be updated.
- The second alert: the tester is alerted when a defect changes its status to ‘Fixed’, so that the responsible tester can pick it up again for retesting.
Workflow
- This module enables project admins to generate scripts which help in customising the Defects module, that is, the Add Defect dialog or the View Defect dialog.
- With the help of this module, project admins can also write scripts to customise dialog boxes in other modules, and control the actions that users can perform.
Now let us customise the ‘Add Defect’ dialog for the ‘TDAdmin’ group user type.
Step 1) Under Project Customization,
- Click ‘Workflow’.
- Select the ‘Script Generator – Add Defect Field Customization’ link
Step 2) The Add Defect field customization dialog opens.
- Select the user group.
- Select the fields that you do not want to appear in the Add Defect dialog.
- Click the ‘<‘ link to push the fields out of the visible fields list.
Note: Mandatory fields cannot be moved out of the visible fields list.
Step 3) After pushing all the irrelevant fields out of the visible fields list, the customization dialog is displayed as shown below.
- The fields that are pushed out of the visible fields list.
- The fields that will be part of the Add Defect dialog.
- Apply the script changes.
Note: Although we customised this through the user interface, the changes are applied by generating scripts in the background. We will also deal with script editing through an example in the next section.
Step 4) Now log in as a user of type ‘TDAdmin’ and click ‘New Defect’ from the Defects module. The fields selected as visible are displayed in the New Defect window.
Script Editor
The script editor helps users write scripts to customise dialog boxes across modules, and to control the actions that users can perform within each module.
Let us change the way the ‘View Defect’ dialog is displayed to the user with the help of the script editor.
Step 1) To access the script editor,
- Navigate to the Workflow tab
- Click ‘Script Editor’.
Step 2) The script editor is shown to the user as below.
- Select ‘Defects Module Script’
- The comment shows the area where we need to make changes, because it explicitly says ‘defect details field customization’.
- It is scripted separately for each user group. The block we are looking at corresponds to the ‘Developer’ user group. We need to make changes to the ‘TDAdmin’ user group.
Step 3) Now scroll down to the ‘TDAdmin’ user group where we need to make changes. The current settings for ‘TDAdmin’ are displayed as shown below.
Step 4) Let us understand the script. Consider the following line of code:
SetFieldApp "BG_ACTUAL_FIX_TIME", True, False, 0, 0
Here are the details:
| Parameter | Meaning |
|---|---|
| SetFieldApp | The function call, made with 5 parameters |
| Field Name | BG_ACTUAL_FIX_TIME – the field name whose settings we are going to change |
| Visible Flag | If True, the field will be visible. |
| Required Flag | Checks whether the field is mandatory. If True, the field is mandatory. |
| PageNo Flag | Starts with 0. If there are many fields, they can be configured to display page by page. |
| ViewOrder | Sets the order of the field. Starts with 0 and increments by 1. |
Step 5) Let us make changes to the first field, ‘BG_ACTUAL_FIX_TIME’. The script for that field in the script editor is shown below.
SetFieldApp "BG_ACTUAL_FIX_TIME", True, False, 0, 0
With the script above, the Defect Details dialog is displayed to the user as shown below.
Edit that line of code as shown below.
SetFieldApp "BG_ACTUAL_FIX_TIME", False, False, 0, 16
Setting the visible flag to False hides the field. The script output is reflected in the Defect Details dialog as shown below.
Step 6) Let us make changes to all the available fields.
- Change the parameters of the function calls as explained in the previous step for each field, as shown below.
- Click ‘Save’.
Step 7) Now log in as a user of type ‘TDAdmin’ and open one of the defects, so that the ‘View Defect Details’ dialog opens. The dialog now displays as shown below.
Best Practices for HP ALM Project Customization
Customisation is easy to start and difficult to unwind, so a few habits save considerable rework later.
- Never edit a live project first. Apply changes in a copy of the project, confirm them, and only then repeat the change in production.
- Create custom groups rather than fighting the predefined ones. Base a new group on the closest predefined profile and adjust only the permissions that must differ.
- Keep user defined fields to a minimum. Every extra mandatory field slows defect logging and is often left with a meaningless default value.
- Comment every workflow script change. The script editor holds one long file per module, and an uncommented edit is difficult to trace months later.
- Back up the workflow script before editing. Copy the existing script into a text file, because there is no version history inside the editor.
- Test with a real account from each group. Permissions frequently behave differently from how the checkbox grid suggests.
To continue with HP ALM administration, read how to create a domain, project, and user in Site Administration, the HP ALM introduction, and the full HP ALM tutorial. For the modules affected by these settings, see requirements, test plan, and filters, flags, and history.






















































