[feature]: Improve issue hierarchy experience

[Igorgro]

Is there an existing issue for this?

• [X] I have searched the existing issues

Summary

(It's hard to describe, I can provide mode details if it is needed). First of all, thanks for development such great tool! I see that there is such powerful feature like parent-child issues. Meanwhile it has some drawbacks. While parent and sub issues are grouped in a manner, they are still feels too separated. For example I can add parent issue to a cycle, but the sub issues won't be added there. Moreover, when I see cycle board, all issues are disaplayed "flat" (i.e. without hierarchy) and I can move issues between states like if they are totaly separated. To be more precise, let's imagine thet we have the following issues hierarchy:

• Implement feature A
  • Backed for feature A
  • Frontend for feature A It is strange that I can move the parent issue to a cycle (i.e plan it for a specific period of time) without moving child issues to that cycle (i.e. they are required to implement feature A, but still not planned) or I can change state of child issue to "In progress" but the feature itself will still be in backlog (i.e. I have started working on part of feature, but not woring on feature itself O_o). For reference: another open-source task tracking software, Taiga, solved this using another approach: they have three types of work items: Epics, Userstories and Tasks. Only Userstories can be added to the sprints (equivalent of cycles), while Tasks are just child items of Userstories, and Epics are the equivalent of Planes's modules).

Why should this be worked on?

.

[aaryan610]

Hello @Igorgro, thank you for your feedback on the issue hierarchy in Plane. We appreciate your input and will prioritize improving it. Our team will carefully evaluate and enhance the hierarchy to provide a better user experience. We value your support and look forward to delivering an improved solution.

[SaudBako]

@aaryan610 @Igorgro My proposal:

Properties of Issues and sub-issues have to sync. Syncing them gives hierarchies semantic meaning.

Defaults

Childrens' properties should be derived from the parent, which means:

• They are set to equal the parent's once created.
• They are updated when the parent changes.
• Their values can be overriden per child, and can be reset (unoverriden).

This applies to all properties except for Duplicate, Relates to, and Start date.

Removal from hierarchy

Once a child is detatched from parent:

• if a property is overriden, it retains its value.
• if not, it is unset.

Dates

If dates are set, a parent should bound its children's date span. A parent's Start date cannot be later than any of children's start date, and vice versa for End date.

Date conflict resolution

If the user sets a date so that this rule is violated, they must confirm changing both the parent and affected children to this new date.

For example, if the parent's Due date is the 24th, and I set the Due date for a child to be on the 25th, I must confirm setting the parent as well to the 25th, or cancel. Another example is if I change the parent's Start date to be ahead of 5 childrens' Start date, I must confirm changing all those children as well.

Remarks

I might have spent too much time thinking about this.

[mmospanenko]

Yes, Taiga, Jira, OpenProject - all they have issue types. I hope Plane will have this to :) I created issue https://github.com/makeplane/plane/issues/5060

But will be great to see something like Notion - nocode database with fully customizable views. Even just for properties :)

Thanks