Skip to content

GitHub Issues & Projects – August 10th update

Today’s Changelog brings you the brand new slice by, updates to issue forms, and a group menu across layouts!

🍕 Slice by

You can now slice by field values in your project views! Configuring a Slice by field allows you to quickly toggle through and review your project items broken down by a field, saving you additional filters and views to quickly understand the state and details of your project. While you can slice by your issue and project fields to customize your view, some helpful slice by views include:
– Single select fields to view items broken up by status, priority, or team
– Labels to group items by repository labels
– Assignees to see who is working on what

slice_by

Select a Slice by field from the view configuration menu. This will pull the field values into the panel on the left, allowing you to click through the values in the list to adjust the items shown in the view.

See it in action on the GitHub public roadmap, and check out the documentation for more details.

📋 Updates to issue forms

You can now configure custom issue forms to automatically add an issue to a project as well as set defaults for drop downs by adding a YAML form definition file to the /.github/ISSUE_TEMPLATE folder in your repository.

issue form yaml syntax

For more comprehensive instructions on syntax for issue forms, check out the documentation.

We’re looking to improve the experience around issue forms and templates. If you have any feedback 👉 drop a comment in our community discussion!

Group menu for item and group actions

We’ve added a group menu to quickly take action on items in a group or on the group itself. Click ... from the group header on your tables, boards, or roadmaps to archive or delete all items in a group, edit the group details directly, hide the group from the view, or delete it from your project.

group menu

✨ Bug fixes and improvements

  • Fixed keyboard navigation and focus when navigating to Make a copy from the project ... menu
  • Fixed group header spacing on the roadmap layout
  • Fixed a bug where using the @next filter qualifier for iteration fields was referencing the incorrect iteration
  • Fixed a bug with the numerical Field sum decimal precision

See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the docs.

Questions or suggestions? Join the conversation in the community discussion.

X-Accepted-GitHub-Permissions header for fine-grained permission actors

A new header will be sent back to API callers that use the fine-grained permission model (GitHub Apps and fine-grained PATs) to help developers discover which permissions are needed to call an API route. This new header, x-accepted-github-permissions, contains the list of permissions required to access the endpoint.

In the fine-grained permission model more than one permission may be needed to access an endpoint. Multiple sets of permissions may also be valid, since there are multiple ways to access data within GitHub. All valid sets are included in the header, each set separated by a semicolon (;).

For example, when calling "List project collaborators", you'll recieve the header x-accepted-github-permissions: repository_projects=write; organization_projects=admin. This indicates that to get the list of collaborators on a project, you need either the repository_projects Write permission or the organization_projects Admin permission.

This header is used in the same way as the x-accepted-oauth-scopes header for coarse-grained scope actors (OAuth apps and PATs (Classic)).

To learn more about troubleshooting permissions issues with GitHub Apps and fine-grained PATs and to get more information about this header, see "Insufficient permission errors". To see the permissions needed for each endpoint, see "Permissions required for GitHub Apps" and "Permissions required for fine-grained PATs".

See more

Actions runs triggered from tags or forks with the same name as a protected branch will now be blocked

GitHub environments can be configured with deployment branch policies to allow-list the branches that can deploy to them.

We are now security hardening these branch policies further by blocking runs triggered from forks with branches that match the protected branch name. We are also preventing tags with the same name as a protected branch from deploying to the environments with branch policies around protected branches.

Learn more about configuring environments with deployment protection rules to set up rigorous and streamlined guardrails for your deployments.

For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more
View all changes