Multi-metric stacked charts, better detection of Jira closure dates and improved auto-filling support on date operators
Our latest release brings new functionalities to some of our existing features, allowing users to unlock even more reporting use cases 🚀 Most of these features were requested by Keypup users, we thank you all for helping us build the best engineering analytics tool 🙏💙
Added multi-metric variants for stacked charts
Our 2-dimensions stacked charts already allow users to create reports using two dimensions (e.g. creation date and author) and one metric (e.g. lines changed, count of PRs), where the second dimension is used to generate the stacked slices.
But what if you want to create a chart with one dimension (e.g. creation date) and multiple custom metrics (e.g. sum of lines added and sum of lines deleted)? Well this is now possible thanks to the multi-metric variants! Our standard stacked charts now allow you to specify multiple metrics, which will stack with each other.
Here is the complete list of stacked charts available on Keypup. The multi-metric ones are standard and the (existing) 2-dimensions version have been renamed to be more explicit:
- Stacked Area Charts
- Stacked Area Charts (2-dimensions)
- Stacked Bar Charts
- Stacked Bars Charts (2-dimensions)
- Stacked Column Charts
- Stacked Column Charts (2-dimensions)
Have more use cases for stacked charts? Don't hesitate to contact us via chat!
Improved auto-filling support on date operators
Our auto-filling feature fills the blanks between data points on time series. This is useful to highlight zero-areas or plateaus (cumulative reporting) when data are missing for a given day, week, or month, instead of connecting the dots and giving a false impression of continuity between existing data points. Our auto-filling feature automatically activates when you select a date dimension with a standard formatter such as "Year > Month", "Year > Week" etc.
This week's release extends the auto-filling logic to also apply to custom formulas when using the following operators:
DAY(1..31)DAY_OF_WEEK(1..7)DAY_OF_YEAR(1..365)HOUR(1..24)MONTH(1..12)QUARTER(1..4)WEEK(1..52)
Note that the auto-filling logic will only activate if the date operator is used as a top-level operator (e.g. MONTH(...)) and not as a calculation element (e.g. CONCAT("Foo", MONTH(...)) ).
On top of this, we also enabled the auto-filling behavior on heatmaps. This allows you to create visual maps to help understand cyclic patterns, such as a contribution map:
Better detection of Jira closure dates
Our integration was previously solely relying on the use of the Resolution field in Jira to detect the closure state and date of issues. This field is usually populated as part of Jira Workflows when issues reach a "Done" status (this is the default in standard Jira Workflows).
Over the last two years we've observed that the usage of the Resolution field has been declining, becoming less and less standard in Jira projects. Jira Product Discovery, the newest product of the Jira family, even dropped support for the Resolution field.
In order to keep delivering consistent reporting on closed Jira issues, we have updated our Jira integration to detect issue closure if any of the following conditions match:
- A Resolution is set on the issue, in which case the resolution date will be used as the closure date
- The issue is in a Status that has a Status Category set to Done, in which case the closure date will be set to the last Status Category Changed Date. This means that if you post-mortem transition an issue from a done status (e.g. Won't do) to another done status (e.g. Released), the closure date will be set to the first closure event (e.g. Won't do).
Other improvements and bug fixes
A few additional items worth mentioning 🥰
- Improvement: Two new custom formula operators, SHA1 and SHA256, were added. These operators can be used to anonymize reports.
- Improvement: Stop retrieving ecosystem.atlassian.net projects when connecting Jira. These projects start appearing after liaising with Atlassian's support. They do not relate to any business-related project.
- Improvement: Jira project-specific custom fields will not be grouped under their respective project ID. The field name used by these fields in custom formulas will also include the Jira project ID. This is done to help differentiate custom fields with identical names from different projects.
- Improvement: Add negative variants for user filters, allowing you to exclude specific users based on their connected identities. The list is: Is not me, Is not user, does not include me, does not include user.
- Improvement: The maximum number of allowed dimensions and metrics on insights has been increased, from 20 to 30 and 10 to 20 respectively. Many insights will restrict this hard limit further based on type (e.g. a heatmap has two dimensions and one metric, no more no less).
- Improvement: Wait for custom formulas to be valid before triggering a reload of the insight. This improves the custom formula editing experience and avoids many unnecessary reloads.
- Bugfix: Fix the sorting of the axis values (or slice names) for the secondary dimension when using charts with two dimensions. The sorting of the could previously appear out of order.
- Bugfix: The array element accessor (e.g.
assignees[1]) was not returning the correct type with date or boolean arrays. This could prevent users from applying type-specific operators on some array elements (e.g. Jira custom field sprint date array). - Bugfix: The CSV export functionality of insights was not taking into account the auto-filling behavior of insights.
