January 13, 2017 release notes
A few new updates were made to the recently launched GitLab Integration.
Improved labels behavior: With the initial 2-way label syncing behavior, adding a label in GitLab added a corresponding tag in Aha! but removing a label did not remove the corresponding tag. The new update will now ensure that Aha! tags match the GitLab labels on a webhook event to make the integration more consistent with the behavior of other Aha! integrations.
Better ID handling in GitLab self-hosted environments: The self-hosted/on-premise GitLab solution reuses IDs for issues and milestones [note: the web version does not] which can cause syncing problems with webhooks. The integration has been updated to use different keys for milestone vs. issue integration fields to circumvent potential problems.
Performance improvements impacting account settings were launched to aid customers with a large number of products. This includes an update to the user interface for the Settings - Account - Configure product lines page where each branch of the product hierarchy can be expanded or collapsed for an improved user experience when managing a large product hierarchy.
Changes were announced last week that included the option to use your own SSL certificate or have it automatically issued and managed by Aha when using a custom CNAME for your idea portal. This necessitated a few additional idea portal authentication changes that were rolled out this week.
Now when using either username/password or SAML authentication for your idea portals, you will always be prompted for your email address first before taking the next step. What happens next will be determined based on whether your environment is setup to use a custom CNAME domain.
Using a CNAME domain: If the email you enter matches an Aha! user in the account the idea portal is from, you will be re-directed to the Aha! login page for your account. Once you sign-in, you will be re-directed back to the portal.
Not using a CNAME domain: It should continue to behave as it did previously where you will still be automatically logged in to the portal.
One benefit of this change is that it should help to reduce confusion around Aha! users not being logged into the portal and resulting in them being created as separate portal users.
Previously when reporting on a custom table and then adding columns from a standard table, certain column combinations -- especially description, status, and type columns - would result in all the data disappearing. This has been corrected.