Hierarchical issue tracking #6353

New Issue

GiteaMirror · 2025-11-02T06:53:25-06:00

GiteaMirror commented

2025-11-02 06:53:25 -06:00

Originally created by @h0lg on GitHub (Nov 19, 2020).

Are there any plans (or existing forks you know of) for supporting hierarchical issue tracking?

If not, is there a way to store information about issue hierarchy?
I want to migrate from redmine, which provides that feature (via a parent_id field on the issue model).

I've looked at the dependencies/"blocking issues" model, but

it seems to have a different purpose in that it is opinionated about allowing status changes on an issue with open dependencies.
In my experience, it is better to keep hierarchical information independent from that. Otherwise moving an open issue into a closed one invalidates the status of the parent or even forces you to reopen it. That introduces perpetually-open issues into your system, because top-level components/modules will always have open ancestors some levels deeper. Redmine for example started out un-opinionated about that and then introduced a rule enforcing that a closed issue could only have closed ancestors, which made the entire hierarchy system harder to manage.
Also, there doesn't seem to be a swagger API or migration model support for the dependencies/"blocking issues" model.

Acknowledging that hierarchical issue tracking may be somewhat of a personal preference/subjective topic and you may be reluctant to add official support for it:

How could I maybe use an existing model feature to store a parent id? It wouldn't even have to have UI support. Swagger API support would suffice.
And if there's no current model that I could abuse for storing custom data on an issue, what would be the easiest way to extend or customize the gitea issue model to store custom information? Is there a good example you have in mind, like a PR that was merged? Do you maybe have something like that in the pipeline?

Background

I came to Gitea for the easy setup of a self-hosted git server on Windows. (Great job there btw - love the simple setup approach!)
Then I looked into the Issue tracking and immediately recognized it from Github - which is a big plus, because most devs know how to use that. What got me excited (and seriously thinking about switching issue trackers as well as git servers) though, are the new Kanban task boards.

The only thing that keeps me from making the switch at this point is the question of how to preserve the hierarchical information when migrating my issues to Gitea.

Having used hierarchical issue trackers has probably spoiled me and taught me to expect more from my issue tracking these days :|
Either way, I don't like the "solve & forget" approach of unstructured issue trackers much any more. I feel like I'm losing to much information and have to repeat myself too often when I use them; the communication overhead increases and the pitfalls become more numerous.

The case for hierarchical issue tracking

(from my personal experience)

depending on the type of project, enables you to structure your issues either
- user-friendly by UI views/components/widgets
  - enabling reuse as specification, documentation/user manual & FAQ, as I'm trying in this project of mine backed by redmine for example
- or developer-friendly by module/class/functionality
allows you to look at all requirements/issues (whether open or closed) for a particular module or UI in context, making it easier to
- overview, reason about and model a problem
- avoid & spot conflicting requirements
- avoid & spot duplicates
- find related issues
- find closed issues again for reference

Originally created by @h0lg on GitHub (Nov 19, 2020). **Are there any plans** (or existing **forks** you know of) **for supporting hierarchical issue tracking**? If not, **is there a way to store information about issue hierarchy?** I want to migrate from redmine, which provides that feature (via a **parent_id** field on the **issue** model). I've looked at the **dependencies/"blocking issues"** model, but 1. it **seems to have a different purpose** in that it is **opinionated about** allowing **status changes** on an issue with open dependencies. In my experience, it is better to keep hierarchical information independent from that. Otherwise moving an open issue into a closed one invalidates the status of the parent or even forces you to reopen it. That introduces perpetually-open issues into your system, because top-level components/modules will always have open ancestors some levels deeper. Redmine for example started out un-opinionated about that and then introduced a rule enforcing that a closed issue could only have closed ancestors, which made the entire hierarchy system harder to manage. 2. Also, there doesn't seem to be a **swagger API** or **migration model support** for the dependencies/"blocking issues" model. Acknowledging that hierarchical issue tracking may be somewhat of a personal preference/subjective topic and you may be reluctant to add official support for it: - How could I maybe **use an existing model feature to store a parent id?** It wouldn't even have to have UI support. Swagger API support would suffice. - And if there's no current model that I could abuse for storing custom data on an issue, what would be the easiest way to **extend or customize the gitea issue model to store custom information**? Is there a good example you have in mind, like a PR that was merged? Do you maybe have something like that in the pipeline? ### Background I came to Gitea for the easy setup of a self-hosted git server on Windows. (Great job there btw - love the simple setup approach!) Then I looked into the Issue tracking and immediately recognized it from Github - which is a big plus, because most devs know how to use that. What got me excited (and seriously thinking about switching issue trackers as well as git servers) though, are the new Kanban task boards. The only thing that keeps me from making the switch at this point is the question of **how to preserve the hierarchical information when migrating my issues to Gitea**. Having used hierarchical issue trackers has probably spoiled me and taught me to expect more from my issue tracking these days :| Either way, I don't like the "solve & forget" approach of unstructured issue trackers much any more. I feel like I'm losing to much information and have to repeat myself too often when I use them; the communication overhead increases and the pitfalls become more numerous. ### The case for hierarchical issue tracking (from my personal experience) - depending on the type of project, enables you to **structure your issues** either - **user-friendly by UI views/components/widgets** - enabling reuse as specification, documentation/user manual & FAQ, as I'm trying in [this project of mine backed by redmine](https://trippin.space/issue/index?open=490172&pinned=528908) for example - or **developer-friendly by module/class/functionality** - allows you to **look at all requirements/issues** (whether open or closed) for a particular module or UI **in context**, making it easier to - **overview**, **reason about** and **model** a problem - avoid & spot **conflicting** requirements - avoid & spot **duplicates** - find **related** issues - find **closed** issues again for reference

GiteaMirror added the type/proposal label 2025-11-02 06:53:25 -06:00

GiteaMirror commented

2025-11-02 06:53:26 -06:00

@h0lg commented on GitHub (Oct 6, 2023):

A few years later and with some more experience working with hierarchical issue trackers I still like the option to organize part of my issues in a structured way (i.e. in trees instead of a flat list) that mimics the navigational and UI structure of my app.
It works well for big apps with many distinct components/pages.

But there's an issue with it that is hidden in the little word or in this section of the original proposal:

depending on the type of project, enables you to structure your issues either

user-friendly by UI views/components/widgets

enabling reuse as specification, documentation/user manual & FAQ, as I'm trying in this project of mine backed by redmine for example

or developer-friendly by module/class/functionality

What if I want that or to be an and? What if I want my issue to be associated with a UI component as well as with a module relevant only to devs? Or associated with multiple UI components because it relates to their interaction? That basically means I want different tree structures or have the issue in different parts of the same tree. Yet my issue can't have more than one parent. As an OO programmer, I realize that I've signed up for a single-inheritance scheme lacking the flexibility that I need.

I don't want one tree to rule them all.

And on the heels of that it came to me that I don't need a pre-defined structure either: The existing issue Labels (tags) do what I need to categorize issues. Giving the labels the correct structure (e.g. a tree by navigational structure down to UI component or a list by internal module) can really only be taken care of by the consumer of the issue data - because any pre-defined structure would hardly ever be right for everyone all the time.

Once I have the label structure right, I can use the API to list issues by label.

The only thing I can currently think of required to make categorizing new issues easier is the ability to pre-fill the Labels from the URL #27341. A host app could use this to enable creating issues for a specific page or UI component, improving issue tracker integration and reducing manual categorization efforts.

So unless anyone sees benefits in defining and rendering issue label structures in gitea itself (e.g. in a JSON "trees" with title: label pairs for nodes), I'd say this may be better implemented as optional functionality in a plugin or custom in the host app.

Feel free to close this proposal.

@h0lg commented on GitHub (Oct 6, 2023): A few years later and with some more experience working with hierarchical issue trackers I still like the option to organize part of my issues in a structured way (i.e. in trees instead of a flat list) that mimics the navigational and UI structure of my app. It works well for big apps with many distinct components/pages. But there's an issue with it that is hidden in the little word **or** in this section of the original proposal: > depending on the type of project, enables you to **structure your issues** either > * **user-friendly by UI views/components/widgets** > > * enabling reuse as specification, documentation/user manual & FAQ, as I'm trying in [this project of mine backed by redmine](https://trippin.space/issue/index?open=490172&pinned=528908) for example > * or **developer-friendly by module/class/functionality** What if I want that _**or**_ to be an _**and**_? What if I want my issue to be associated with a UI component as well as with a module relevant only to devs? Or associated with multiple UI components because it relates to their interaction? That basically means I want different tree structures or have the issue in different parts of the same tree. Yet my issue can't have more than one parent. As an OO programmer, I realize that I've signed up for a single-inheritance scheme lacking the flexibility that I need. **I don't want one tree to rule them all.** And on the heels of that it came to me that **I don't need a pre-defined structure** either: The existing **issue Labels** (tags) do what I need to **categorize issues**. Giving the labels the correct structure (e.g. a tree by navigational structure down to UI component or a list by internal module) can really only be taken care of by the consumer of the issue data - because any pre-defined structure would hardly ever be right for everyone all the time. Once I have the label structure right, I can [use the API to list issues by label](https://docs.gitea.com/api/1.20/#tag/issue/operation/issueListIssues). The only thing I can currently think of required to make categorizing new issues easier is the ability to **pre-fill the Labels from the URL** #27341. A host app could use this to enable creating issues for a specific page or UI component, improving issue tracker integration and reducing manual categorization efforts. So unless anyone sees benefits in defining and rendering issue label structures in gitea itself (e.g. in a JSON "trees" with `title: label` pairs for nodes), I'd say this may be better implemented as optional functionality in a plugin or custom in the host app. **Feel free to close this proposal.**

GiteaMirror commented

2025-11-02 06:53:26 -06:00

@lunny commented on GitHub (Oct 9, 2023):

I think Gitea Issues will not have a complicated features like Jira or Redmine int a short-term.

@lunny commented on GitHub (Oct 9, 2023): I think Gitea Issues will not have a complicated features like Jira or Redmine int a short-term.

GiteaMirror commented

2025-11-02 06:53:26 -06:00

@h0lg commented on GitHub (Oct 9, 2023):

I think Gitea Issues will not have a complicated features like Jira or Redmine int a short-term.

And that's not a problem - because if you want it, you can build it on top of gitea as a plugin or use its REST API to query and structure your issues according to your needs. That's the gist of what I wanted to get across above.

@h0lg commented on GitHub (Oct 9, 2023): > I think Gitea Issues will not have a complicated features like Jira or Redmine int a short-term. And that's not a problem - because if you want it, you can build it on top of gitea as a plugin or use its REST API to query and structure your issues according to your needs. That's the gist of what I wanted to get across above.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6353