feat: let issue templates set MokoGitea first-class fields (priority / status / type / custom fields) #744

New Issue

2026-07-05T20:59:50Z

jmiller commented

2026-07-05 20:59:50 +00:00

Summary

MokoGitea adds several first-class issue attributes that vanilla Gitea doesn't have — Priority, Status, Type, and org-level custom fields. But the issue-template system still only understands upstream Gitea's front-matter keys (name, about, title, labels, assignees, ref). So a template can't pre-populate any of the fork's first-class fields — they have to be set by hand on every new issue.

Request: expand the issue-template schema so templates can set the new first-class fields at creation time.

Proposed template keys

Extend both the Markdown-template front matter (.mokogitea/ISSUE_TEMPLATE/*.md) and the YAML issue-form schema to accept:

Key	Sets	Resolves against
`priority`	first-class Priority	org issue priorities (`/orgs/{org}/issue_priorities`)
`status`	first-class Status	org issue statuses (`/orgs/{org}/issue_statuses`)
`type`	first-class Type (Bug/Feature/…)	org issue types
`fields:` / `custom_fields:`	org custom fields	org custom-field definitions (`/orgs/{org}/custom_fields`)

Example:

---
name: Bug Report
about: Report a bug
title: '[BUG] '
labels: 'bug'
priority: Medium
status: Triage
type: Bug
fields:
  component: engine
  environment: production
---

Behavior / requirements

Resolve by name → id at issue-create time (like labels), against the org's definitions; unknown value → ignore + warn (don't fail the create).
Apply for both template kinds: legacy Markdown templates and the structured YAML issue forms.
Respect existing permissions — a template can't set a field the creator couldn't set manually.
Backward compatible: templates without these keys behave exactly as today.
Surface in the issue-form UI so the preselected values are visible/editable before submit.

Why

Consuming repos rely heavily on Priority/Status/Type/custom-fields for triage (see the MokoConsulting issue workflow). Being able to bake sensible defaults into each template (e.g. a security template → priority: High, type: Vulnerability) removes a manual step and keeps triage consistent.

Related: the issue-template dedup/standardization effort in Template-Generic#65 — first-class-field support would let the shared templates carry correct defaults org-wide.

## Summary MokoGitea adds several **first-class issue attributes** that vanilla Gitea doesn't have — Priority, Status, Type, and org-level custom fields. But the issue-template system still only understands upstream Gitea's front-matter keys (`name`, `about`, `title`, `labels`, `assignees`, `ref`). So a template can't pre-populate any of the fork's first-class fields — they have to be set by hand on every new issue. Request: **expand the issue-template schema so templates can set the new first-class fields** at creation time. ## Proposed template keys Extend both the Markdown-template front matter (`.mokogitea/ISSUE_TEMPLATE/*.md`) and the YAML issue-form schema to accept: | Key | Sets | Resolves against | |---|---|---| | `priority` | first-class Priority | org issue priorities (`/orgs/{org}/issue_priorities`) | | `status` | first-class Status | org issue statuses (`/orgs/{org}/issue_statuses`) | | `type` | first-class Type (Bug/Feature/…) | org issue types | | `fields:` / `custom_fields:` | org custom fields | org custom-field definitions (`/orgs/{org}/custom_fields`) | Example: ```yaml --- name: Bug Report about: Report a bug title: '[BUG] ' labels: 'bug' priority: Medium status: Triage type: Bug fields: component: engine environment: production --- ``` ## Behavior / requirements - Resolve by **name → id** at issue-create time (like labels), against the org's definitions; unknown value → ignore + warn (don't fail the create). - Apply for **both** template kinds: legacy Markdown templates and the structured YAML issue forms. - Respect existing permissions — a template can't set a field the creator couldn't set manually. - Backward compatible: templates without these keys behave exactly as today. - Surface in the issue-form UI so the preselected values are visible/editable before submit. ## Why Consuming repos rely heavily on Priority/Status/Type/custom-fields for triage (see the MokoConsulting issue workflow). Being able to bake sensible defaults into each template (e.g. a security template → `priority: High`, `type: Vulnerability`) removes a manual step and keeps triage consistent. Related: the issue-template dedup/standardization effort in Template-Generic#65 — first-class-field support would let the shared templates carry correct defaults org-wide.

jmiller commented

2026-07-05 20:59:54 +00:00

Branch created: feature/744-feat-let-issue-templates-set-mokogitea-f

git fetch origin
git checkout feature/744-feat-let-issue-templates-set-mokogitea-f

Branch created: [`feature/744-feat-let-issue-templates-set-mokogitea-f`](https://git.mokoconsulting.tech/MokoConsulting/MokoGitea-Fork/src/branch/feature/744-feat-let-issue-templates-set-mokogitea-f) ```bash git fetch origin git checkout feature/744-feat-let-issue-templates-set-mokogitea-f ```

Sign in to join this conversation.

Priority Medium

Type Feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea-Fork#744