Manager 9.3 Release Notes

October 29, 2018

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.  

Enhancements

Site Administration

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.

    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.

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.

Example: 

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

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.

Batch Actions

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

Example:

If a Site Administrator wants to assign multiple users to multiple projects using the Batch Action feature, follow these steps:

  1. In qTest Manager, select Administration from the username drop-down menu.

  2. The Licenses tab page displays. Here, select the check box(es) associated with the users whom you want to be added to your project(s).

  3. Select the Batch Action icon. From the drop-down menu, select Assign to Projects.

  4. The "Add Users to Projects" dialog displays. Select the Project(s) from the menu on the left, and then select the right arrow. 

  5. Select Save. Your selected users have now been added to the selected project(s).

User Authentication

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.

Improvements

Jira Connection

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.

Refer to Connect to Jira Cloud 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. 

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.

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.

Known Limitation

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

Security Improvements

  • Passwords have been updated from SHA-1 to SHA-3.

    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)