We are happy to announce the release of qTest Manager 9.3 which includes an enhanced UI experience for Site Administrators, the ability to create and manage User Groups, assign user permissions in bulk, a new API for Jira Integration and many other exciting features. Please read below for further details.
The qTest Administration section has been enhanced with the following:
- The 9-box is renamed to Product Navigator for this release.
- The Product Navigator has been added to the Administration section so you can access your qTest applications directly from any page within Administration.
Note: You will not have access to your projects from within Administration. You must select Manager in the App Navigator to gain access to your qTest projects.
- A new UI for the header that includes the Administration tabs. The Action tabs are now grouped together by how they function for the system. Global Administration tabs are grouped on the left, while qTest Manager Administration tabs are on the right.
- The Licenses page has also been updated with a new UI and now houses the ability to update users' authentication systems during import.
- A new tab for Groups has been added. Read below for further information.
Private Values of Site Fields
Users are now able to manage Site fields more effectively with the ability to keep certain Site Field Values private in a project. Previously, upon applying a Site Fields template to projects, any value added to that Site Field Template would also then be added to any project(s) associated with that template.
Now, you can make site field values private and unique to a given project, and they will only be able to to be used internally within that specific project. This applies to System or Custom Site Fields that use a control type of combo box, or multiple selection combo boxes.
Note: While we do allow Site Administrators to keep values private to a project, they cannot create new private values within a project. Management of site field values must be handled in Site Fields from within Administration.
I have Template A applied to Projects 1,2,3,4 and 5. I decide that I want to add a site field value to projects 1-4, but not 5. I can now add that value to the Site Field template, but specify that it should only affect projects 1-4, and not 5.
Limiting Site field Values to Certain Projects
Administrators can also limit the usage of a Site Field Value within certain projects.
Read this article for further information about Site Fields.
User Groups is a comprehensive tool that allows Site Administrators to better manage users and their permissions. You can simply assign a user to a User Group, and all permissions associated with that User Group are granted to that user. You will need the new permission, Manage User Groups, to manage and add users to User Groups.
The User Group permissions exist above the project level. So, a user within a User Group will retain the permissions assigned no matter what project they may be working. To assign project-specific permissions, you will use User Profiles.
User Groups can also be used as permission-less groups to tag and better organize users. This allows Site Administrators to sort through and search for existing users. Project Administrators will be able to search for users using User Groups as filters.
qTest will offer system pre-defined User Groups, but also allows Site Administrators to create custom User Groups. The pre-defined User Groups and their permissions are as follows:
- Administrators: Super users who can perform any site level configurations
- qTest Insights Viewers: Users who can view reports in qTest Insights
- qTest Insights Editors: Users who can define reports in qTest Insights
- qTest Pulse Users: Users who can access qTest Pulse
- qTest Launch Users: Users who can access qTest Launch
- Administrators who have already set up Admin Profiles do not have to worry about the introduction of User Groups, as all existing Admin Profiles will be migrated into new Custom User Groups. This way, Project Administrators will not have to start from scratch in defining new sets of user permissions.
- In a Sessions Only package, the only pre-defined User Group available is System Administrators. Administrators cannot modify or create new User Groups.
Read this article for more information on User Groups.
Along with User Groups, Manager 9.3 offers Site Administrators a wider variety of Batch Actions. These Batch Actions help administrators manage and modify potentially large groups of users simultaneously. You will find the Batch Action button on the License Information page.
The Batch Actions include:
- Assign projects
- Reset Passwords
- Export Users
- Update Users
- Activate Users
- Deactivate Users
- Resend Invite Emails
If a Site Administrator wants to assign multiple users to multiple projects using the Batch Action feature, follow these steps:
- In qTest Manager, select Administration from the username drop-down menu.
- The Licenses tab page displays. Here, select the checkbox(es) associated with the users whom you want to be added to your project(s).
- Select the Batch Action icon. From the drop-down menu, select Assign to Projects.
- The "Add Users to Projects" dialog displays. Select the Project(s) from the menu on the left, and then select the right arrow.
- Select Save. Your selected users have now been added to the selected project(s).
Site Administrators can now also bulk edit user profiles for one user within multiple projects. This can be helpful for adding a user to multiple projects. For example:
- Use "Add to Projects" if a user has already been assigned to Project P-1 with user profile UP-1: If you add the user again to P-1 with another User Profile (i.e., UP-2), this will not affect the user. The user profile in P-1 is still UP-1.
- Use"Edit Projects and Profiles:" As opposed to the above, this will update the user's user profile in P-1 to UP-2. This can also be used for adding a user to other projects.
The Batch Action associated with updating user information allows site administrators to export an Excel file from qTest. Users can then modify the Excel file and re-import the file into qTest. qTest will read the file and can update the following user information accordingly:
- SSO username
- LDAP username
- First Name
- Last Name
- Auth system
- Projects (separated by a new-line character)
- User profile
- User Last Login (date and time of the most recent login, in the configured Internalization format)
- Activation Link column - activation link for "New" users, only include the data if the status of the user is New
- Reset Password Link - Active reset password links (active users have NOT accessed them to reset password)
Note: If an internal user was once authenticated by an SSO system, his or her old SSO username would be included in the export file.
Admins can also check logs for exact error reports for each user. These logs can be exported into Excel, modified, and then re-imported back into qTest Manager to send an invitation with the correct information.
Site Administrators can now batch manage User Authentication. The following actions can be performed in batches:
- The system now supports admin importation of user info from an XLS file. Here, an admin can change auth system information.
- Admins can now save the external username of an internal user. That way, the admin can reuse these usernames if there is a switch from LDAP to SSO authentication. Previously, these external usernames were not imported when changing the authentication system, and if changing back, the admin had to re-enter external usernames.
- Users are automatically activated when an admin changes their authentication system from Internal to LDAP/SSO using the import tool.
Example Use Case:
When changing the authentication system from LDAP to SSO, in most cases, SSO usernames will be the same as LDAP usernames. The site admin may want to export users with LDAP usernames first and then re-use the LDAP usernames as SSO usernames.
In qTest, enabling SSO will automatically disable LDAP, and all LDAP usernames are cleared out. In this case, the site admin should export users BEFORE disabling LDAP or enabling SSO.
Integration with Jira Cloud
You can now establish a connection with Jira Cloud through the following:
- Jira API token (new for 9.3)
- Jira OAuth
- Jira Username and Password (will be deprecated by Atlassian December 1st, 2018)
Previously, a connection could be established using the Jira username/password of a Jira Global Admin. However, Atlassian is deprecating the username/password authentication option on December 1, 2018. More details, check out this Atlassian Announcement: Deprecation Notice.
Therefore, the Jira Connection dialog has been updated to include 'Token' in the password field along with a link to instructions on how to create an API token in Jira.
Customers who are connected to Jira Cloud MUST edit their existing connection to switch from their basic password to use either the OAuth or the API Token. To avoid duplicating data, we recommend that users not create brand new connections. Instead, click into the Connection Name to modify the existing connection. In order to do this, you will need to be a qTest Project Admin and use the Jira Global Admin permission to edit your connection.
We highly suggest you update your authentication connection as soon as possible to avoid a disruption in your integration, in the event you need help from QASymphony Support.
Read this article for instructions on Configuring your Jira Cloud Integration.
Integration with Jira Server
Atlassian has not announced a plan to deprecate the basic authentication option (username and password), so you can continue to use your existing connection without any issues after December 1st.
Note: The behavior is different between integration with Jira Cloud and Jira Server.
- Jira Cloud: If a Jira issue is moved from Project A to Project B, and Project B is configured to qTest, the Jira issue is automatically synced to qTest. If B is not configured, the Jira issue is not automatically synced but can be manually synced.
- Jira Server: This is more strict than integration with the Jira cloud. When a Jira issue is moved to another project or converted to another issue type, if that destination issue type is configured in qTest, then Jthe Jira issue is automatically synced. Otherwise, users will have to sync manually.
Note: Project Administrators will need to access the integration configuration page and manually select the Retrieve Date icon to apply this enhancement to existing synced requirements.
- Site Fields
- For other fields, only the private values show up as Italicized in the project's Field Settings. For an Environment field, all values are italicized.
- You cannot configure an Environment field's value to exclude from specific projects
- When you add a new site field to the template, given a site template which has been applied to some projects, its values are merged with any matched fields from the projects. The option to keep unique values in projects are not yet available for this case.
- Passwords have been updated from SHA-1 to SHA-3
- Note: This is an update to the hashing algorithm. This only applies to native password manager and not for SAML integrated users. You will need to reset your password for this change to take effect.
- The SSO login method has been made more secure.
- Cross-site scripting (XSS)