Beta release of the Activity Events dataset and streamlined edition of report columns
This release brings a new dataset to the Keypup family! The Activity Events dataset allows engineering managers to create activity feeds as well as historical "open at date" insights 📈 As part of this update we also improved the UX around column handling in our insight editor.
New Activity Events dataset in beta
The Activity Events dataset tracks historical events occurring on Issue and Pull requests. This dataset is currently available in beta and we are collecting feedback to further improve the data model.
The following events are currently captured:
CREATED:
the issue/PR was createdCLOSED:
the issue/PR was closedREOPENED:
the issue/PR was opened was being closedMERGED:
the PR was mergedREVIEWER_ASSIGNED:
a reviewer was assigned (requested reviewers) to the PR. Keypup generates one event per assigned reviewer in case of bulk assignments.REVIEWER_UNASSIGNED:
a reviewer was unassigned (requested reviewers) from the PR. Keypup generates one event per unassigned reviewer in case of bulk unassignments.USER_ASSIGNED:
a user was assigned (assignees) to the issue/PR. Keypup generates one event per assigned user in case of bulk assignments.USER_UNASSIGNED:
a user was unassigned (assignees) from the issue/PR. Keypup generates one event per unassigned user in case of bulk unassignments.WORK_LOGGED:
a user logged some time on the issue/PR.WORKFLOW_STATUS_UPDATED:
the issue transitioned to a new workflow status.
For each event, we also capture useful content fields:
- Parent: The parent issue or pull request is captured through the "Parent >Â *" fields. This allows you to filter events based on parent attributes such as the issue type, state, or labels.
- Duration:Â This field is populated on
WORK_LOGGED
events. It allows users to create time spent reports per week and/or per assignee. - Target User:Â This field is populated on assigned/unassigned events and captures who was the person being assigned or unassigned.
- Workflow Status:Â This field is populated on WORKFLOW_STATUS_ UPDATED events and captures the destination status
The types of Activity Events will vary slightly based on the apps you connect to Keypup. Here is the list of supported events for each application:
- Github:
CREATED
,CLOSED
,REOPENED
,MERGED
,REVIEWER_ASSIGNED
,REVIEWER_UNASSIGNED
,USER_ASSIGNED
,USER_UNASSIGNED
- GitLab:
CREATED
,CLOSED
,REOPENED
,MERGED
,REVIEWER_ASSIGNED
,REVIEWER_UNASSIGNED
,USER_ASSIGNED
,USER_UNASSIGNED
,WORK_LOGGED
- Bitbucket:
CREATED
,CLOSED
,MERGED
,REVIEWER_ASSIGNED
,REVIEWER_UNASSIGNED
- Jira:
CREATED
,CLOSED
,REOPENED
,USER_ASSIGNED
,USER_UNASSIGNED
,WORK_LOGGED
,WORKFLOW_STATUS_UPDATED
- ClickUp:
CREATED
,CLOSED
. ClickUp does not expose an events API. Keypup generates these two events based on the issue timestamps (date_created
&date_closed
) - Trello:
CREATED
,CLOSED
,REOPENED
,USER_ASSIGNED
,USER_UNASSIGNED
,WORKFLOW_STATUS_UPDATED
All the documentation for the Activity Events dataset can be found here.
So what can you do with Activity Events? Here is a list of insights and reports you can build on Keypup:
- An activity feed showing the most recent actions that were taken for all issues and pull requests, or a subset of them
- An open-at-date report, showing the historical running count of open issues, by summing (cumulative sum)Â the number of open/reopened events minus closed/merged events
- An "in status" at-date report for Jira/Trello, showing the historical running count of issues that were in a specific status (e.g. In Progress) by summing (cumulative sum)Â the number of transitions minus the number of transitions to the next status.
- A consolidated report of how much time has been spent on issues, per issue type or label
- An assignment report showing how often engineers get assigned to PRs for review
Have other use cases in mind? Need a hand setting up insights using the new Activity Events dataset? Just ping our team on the chat! 🤓
Easier handling of columns in the insight editor
Many of you were frustrated that columns could not be inserted in the middle of a report 🤯 This forced people to add a column at the end and then move it all the way up.
Well, the pain is over! This release includes two UX improvements related to column handling:
- The table columns in the "Configure table" section now properly use the label defined on the column, instead of using the column number. This makes the overall navigation easier, especially on large reports.
- The column menu now allows you to right-insert a dimension or a metric (depending on the type of insight).
It's a small change but it helps considerably when editing reports 😇
Other improvements and bug fixes
A few additional items worth mentioning 🥰
- Improvement: The state (OPEN/CLOSE)Â of Jira issues is now purely based on the status category of their workflow status ("done" status category or not). We no longer rely on the resolution field since this field is not longer standard in Jira flows (e.g. Jira Product Discovery does not support this field) and its use has become unreliable (e.g. some issues may have a resolution status without being closed status-wise).
- Improvement:Â Support
IS_NULL
 andIS_NOT_NULL
 filtering on number fields. - Bugfix: The edition modal of dashboard-wide filters now displays insights in alphabetical order instead of using the "add date" of each insight.
- Bugfix:Â Fixed the alphabetical listing of some fields in the datasets
- Bugfix:Â The search bar in the dashboard share modal now uses case-insensitive search for users
- Bugfix:Â Gracefully handle the login flow when an old session token is present in the URL (e.g. when bookmarked)