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.

  • 🔐 Access Control: Project Users adds or removes accounts, and Groups and Permissions decides what each group may create, update, or delete.
  • 👁️ Default Rule: Every newly added user starts in the Viewer group with read-only rights until an administrator changes the membership.
  • 🚫 Predefined Groups: The five built-in groups cannot be renamed, deleted, or edited, so a custom group must be created to change permissions.
  • 🧱 Custom Fields: Project Entities adds user defined fields, while system fields stay read-only and cannot be removed.
  • 📋 Project Lists: Lists supply the selectable values behind fields such as Bug Status, and new items appear immediately in the Defects module.
  • 📧 Notifications: Automail emails users when chosen defect fields change, and Alert Rules covers requirements and associated tests.
  • 📝 Script Editor: SetFieldApp controls field visibility, mandatory status, page number, and display order for each user group.

Customize Project in HP ALM

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.

User Properties

Step 2) The Project Customization dialog is displayed as shown below.

User Properties

Step 3) To change the password of the current user, click ‘Change Password’ in the ‘User Properties’ tab.

User Properties

Step 4) The change password dialog opens.

  1. Enter Old Password
  2. Enter New Password
  3. Enter Confirm Password
  4. Click ‘OK’

User Properties

Step 5) The user will be shown the status message.

User Properties

Step 6) The user can also edit the following profile details.

  1. Email ID
  2. Full Name
  3. Phone Number
  4. Click ‘Save’

Note: Users will not be able to edit their User Name, even if the user is of type ‘Project Administrator’.

User Properties

Step 7) The status is displayed to the user as shown below.

User Properties

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.

  1. Navigate to Project Users
  2. Click the Add User drop down.

Project Users

Step 2) Upon clicking the ‘Add User’ drop down, the following methods are displayed to the user as shown below.

  1. Add User by Name – The project admin can add an existing ALM user to this project by giving their user name.
  2. 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.
  3. Add Users from Site – Add an existing user by searching on their name or ID.

Let us see each one of these methods.

Project Users

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.

  1. Select ‘Project Users’ from the Project Customization window.
  2. Click ‘Add User’
  3. Enter User Name
  4. Click ‘OK’

Project Users

Step 4) The added user is displayed as shown below.

Project Users

Step 5) Now let us add a user using the option ‘Add New User to Site’.

Project Users

Step 6) Upon clicking ‘Add New User to Site’ from ‘Add User’, the following dialog is displayed.

  1. Enter User Name
  2. Enter Email
  3. Enter Full Name
  4. Enter Phone Number
  5. Click ‘OK’

Project Users

Step 7) The user is now added to the current project. The user appears in ‘Project Users’ as shown below.

Project Users

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.

Project Users

Step 9) The following dialog is displayed.

  1. Enter the User Name and click the search icon
  2. The User Name is displayed
  3. Click ‘OK’

Project Users

Step 10) The user is added to the project and displayed as shown below.

Project Users

Step 11) The project admin can also remove a user from the Project Users module.

  1. Select the user
  2. Click ‘Remove User’

Project Users

Step 12) A confirmation dialog is displayed. Click ‘Yes’.

Project Users

Step 13) Upon clicking ‘Yes’ the user is removed from the project users list.

Project Users

Step 14) Each user in ‘Project Users’ has a membership associated with it.

Note: By default, any added user has ‘View’ permissions only.

  1. Select the User Name
  2. Select the ‘Membership’ tab
  3. The membership for the selected user is displayed. The newly added user ‘Cathy’ has ‘Viewer’ permission.

Project Users

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.

  1. Developer
  2. Project Manager
  3. QA Tester
  4. TD Admin
  5. 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.

  1. Select ‘TDAdmin’
  2. Under the Membership tab you will see users who are not in the group
  3. Under the ‘In Group’ section you will see the list of users within the group. In this case only ‘Admin’ is displayed.

Groups And Permissions

Step 2) The predefined group permissions cannot be edited.

  1. Select ‘TDAdmin’
  2. Navigate to the Permissions tab
  3. Select any module (Defects in this case)
  4. The permissions cannot be edited, even if the current user is a project admin.

Groups And Permissions

Step 3) The predefined groups cannot be renamed or deleted.

Groups And Permissions

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,

  1. Click ‘New Group’
  2. A confirmation dialog is shown to the user. Click ‘Yes’.

Groups And Permissions

Step 5) Upon clicking Yes, the ‘New Group’ dialog is shown.

  1. Enter the Group Name
  2. Enter the profile it should be based on

Groups And Permissions

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.

Groups And Permissions

Step 7) To change the permission,

  1. Navigate to the ‘Permissions’ tab
  2. Click the ‘Defects’ tab
  3. Enable the ‘Update’ flag for Defects
  4. Enable the ‘Update’ flag for Links

Groups And Permissions

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.

Module Access

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.

Module Access

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’.

Module Access

⚠️ 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.

  1. Select ‘Project Entities’
  2. Select ‘Defect’ and then the subfolder ‘System Fields’.
  3. Notice that we will not be able to add a ‘New Field’ or delete one, because system fields are read-only.

Project Entities

Step 2) To add a user defined field,

  1. Select the ‘User Fields’ subfolder under the ‘Defects’ module.
  2. Click ‘New Field’
  3. The field details appear as shown below and can be edited.

Project Entities

Step 3) Field details can also be edited as shown below.

  1. Rename the label to ‘Build Number’.
  2. Check ‘Required’, which means this field becomes mandatory when posting a new defect.
  3. Click Save

Project Entities

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 Entities

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,

  1. Click ‘Project Lists’
  2. Select ‘Bug Status’
  3. Click ‘New Item’. The New Item dialog opens.
  4. Enter the Item Name.
  5. Click ‘OK’

Project Lists

Step 2) Upon clicking OK, the new item is created as shown below.

Project Lists

Step 3) Now we need to save the changes.

  1. Click the ‘Save’ button.
  2. A pop-up is shown. Click ‘OK’.

Project Lists

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.

Project Lists

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.

  1. Navigate to the ‘Automail’ link.
  2. The user can trigger email by selecting any number of available fields in the list.
  3. This grid shows the list of fields the user has selected to send mail about.
  4. The project admin can also select the email settings against each available user.
  5. Click ‘Save’.

Automail

Step 2) A pop-up is shown. Click OK.

Automail

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,

  1. Navigate to ‘Alert Rules’.
  2. Enable the ‘Alert Associated with’ check box
  3. Enable ‘Send E-mail to’ and add the corresponding tester or designer.
  4. Click ‘Save’

Alert Rules

  • 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,

  1. Click ‘Workflow’.
  2. Select the ‘Script Generator – Add Defect Field Customization’ link

Workflow

Step 2) The Add Defect field customization dialog opens.

  1. Select the user group.
  2. Select the fields that you do not want to appear in the Add Defect dialog.
  3. 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.

Workflow

Step 3) After pushing all the irrelevant fields out of the visible fields list, the customization dialog is displayed as shown below.

  1. The fields that are pushed out of the visible fields list.
  2. The fields that will be part of the Add Defect dialog.
  3. Apply the script changes.

Workflow

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.

Workflow

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,

  1. Navigate to the Workflow tab
  2. Click ‘Script Editor’.

Script Editor

Step 2) The script editor is shown to the user as below.

  1. Select ‘Defects Module Script’
  2. The comment shows the area where we need to make changes, because it explicitly says ‘defect details field customization’.
  3. 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.

Script Editor

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.

Script Editor

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.

Script Editor

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.

Script Editor

Step 6) Let us make changes to all the available fields.

  1. Change the parameters of the function calls as explained in the previous step for each field, as shown below.
  2. Click ‘Save’.

Script Editor

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.

Script Editor

Best Practices for HP ALM Project Customization

Customisation is easy to start and difficult to unwind, so a few habits save considerable rework later.

  1. Never edit a live project first. Apply changes in a copy of the project, confirm them, and only then repeat the change in production.
  2. 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.
  3. Keep user defined fields to a minimum. Every extra mandatory field slows defect logging and is often left with a meaningless default value.
  4. Comment every workflow script change. The script editor holds one long file per module, and an uncommented edit is difficult to trace months later.
  5. Back up the workflow script before editing. Copy the existing script into a text file, because there is no version history inside the editor.
  6. 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.

FAQs

Site Administration creates domains, projects, and site level users across the whole installation. Project Customization decides what those users may see and do inside one specific project.

The five built-in groups are locked by design so that a baseline always exists. Create a new group based on the closest profile, then adjust the permissions on that copy.

Yes, but the stored values are lost with it. Clear the field on existing records first, or export the data, because deletion cannot be undone from the customisation screen.

Check that the mail server is configured in Site Administration, that each user has a valid email address, and that at least one field is selected in the automail grid.

They can draft VBScript logic and explain existing blocks, but they do not know your field names. Confirm every entity name against Project Entities before saving the script.

Yes. Workflow scripts and custom fields must be retested after every upgrade. Keep customisation documented and minimal so that the verification effort stays manageable.

Summarize this post with: