feat(issues): granular field-level permissions for status, priority, and custom fields #532

New Issue

2026-06-06T19:24:14Z

jmiller commented

2026-06-06 19:24:14 +00:00

Summary

Add granular permission controls for issue fields so that specific teams or roles can be granted edit access to individual fields independently.

Current Behavior

All issue fields (status, priority, custom fields, labels, milestones, assignees) share the same permission check: HasIssuesOrPullsWritePermission. Either you can edit everything or nothing.

Proposed Behavior

Field-Level Permissions

Each first-class and custom field should have configurable edit permissions:

Field	Default Permission	Configurable?
Status	Issues write	Yes
Priority	Issues write	Yes
Labels	Issues write	Yes
Milestone	Issues write	Yes
Assignees	Issues write	Yes
Custom Fields	Issues write	Per-field
Close/Reopen	Issues write + poster	Yes

Permission Levels

Anyone - any authenticated user can edit
Contributors - users with any repo access
Writers - users with write permission (current default)
Maintainers - team maintainers only
Admins - org/repo admins only
Team-based - specific teams can edit (e.g. only "QA" team can set priority)

Configuration

Per-org settings page where admins define which roles can edit each field type. These cascade to all repos in the org.

Closed Issue Behavior

When an issue is closed:

Regular users and posters see only Reopen
Writers see full status dropdown with Reopen option
Field editing follows the same permission matrix but defaults to read-only for non-writers on closed issues

Motivation

Different team members have different responsibilities. A QA engineer should be able to set priority but not change milestones. A support agent should be able to update status but not reassign. Granular permissions prevent accidental changes and enforce workflow discipline.

Authored by Jonathan Miller (@jmiller)

## Summary Add granular permission controls for issue fields so that specific teams or roles can be granted edit access to individual fields independently. ## Current Behavior All issue fields (status, priority, custom fields, labels, milestones, assignees) share the same permission check: `HasIssuesOrPullsWritePermission`. Either you can edit everything or nothing. ## Proposed Behavior ### Field-Level Permissions Each first-class and custom field should have configurable edit permissions: | Field | Default Permission | Configurable? | |-------|-------------------|:---:| | Status | Issues write | Yes | | Priority | Issues write | Yes | | Labels | Issues write | Yes | | Milestone | Issues write | Yes | | Assignees | Issues write | Yes | | Custom Fields | Issues write | Per-field | | Close/Reopen | Issues write + poster | Yes | ### Permission Levels - **Anyone** - any authenticated user can edit - **Contributors** - users with any repo access - **Writers** - users with write permission (current default) - **Maintainers** - team maintainers only - **Admins** - org/repo admins only - **Team-based** - specific teams can edit (e.g. only "QA" team can set priority) ### Configuration Per-org settings page where admins define which roles can edit each field type. These cascade to all repos in the org. ### Closed Issue Behavior When an issue is closed: - Regular users and posters see only Reopen - Writers see full status dropdown with Reopen option - Field editing follows the same permission matrix but defaults to read-only for non-writers on closed issues ## Motivation Different team members have different responsibilities. A QA engineer should be able to set priority but not change milestones. A support agent should be able to update status but not reassign. Granular permissions prevent accidental changes and enforce workflow discipline. --- *Authored by Jonathan Miller (@jmiller)*

jmiller referenced this issue

2026-06-06 19:44:00 +00:00

feat: granular role-based permissions for all features #9

jmiller closed this issue

2026-06-06 19:44:00 +00:00

Sign in to join this conversation.