Ability to display Dependency relations between cards

[Porrumentzio]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
Sometimes there are dependency relations between some cards/tasks and it is difficult to manage those on Deck with its current implementations.

Describe the solution you'd like
Similar to #2103, but not related to hierarchy but dependency. This means that the cards are not a group of subtasks, but that they have a dependency relation.
The cards could be dragged to right below other card to show a dependency relation:

Not having such a feature, makes difficult to know which card is dependent to other and thus, unable to start doing until that other is finished. I would not know how to solve this with columns.

[stefan-niedermann]

Maybe i haven't understood it correctly yet: With "Dependency" - do you mean something like a "hard dependency" or just a relation? For example: Card A depends on Card B - Can one drag Card A to the next list while Card B is not there yet?

Because for a flat relation you could utilize Nextcloud Projects - You can link the cards to each other and even to Talk Rooms, Files etc.. If this is already enough, maybe the UI can be improved to highlight all cards which are in the same Project?

Of course, if you really want to define hard dependencies, this is not possible with Projects.

[Porrumentzio]

Card A depends on B, so A should not be moved to next list while B did not.
On my example, one should not update servers' software until Backups are done.

I think this could not be done with projects. Maybe this is a hard dependency :)

[dodedodo]

That would be neat. But I can imagine this is quite difficult to implement because it makes a lot of assumptions that are not necessarily true for every kanban board.

For example;
If A depends on B. Should A be unlocked if B is moved to in "Under Review"? Or if it reaches "Done"? Or when it's archived? What happens if someone wants to move A to the "To Discuss" list? That should be allowed, right?

How would you configure such a dependency while maintaining the agnostic nature of kanban?

[Porrumentzio]

That are important questions.
I don't think that this dependency should be entered into code so it is not possible to move a dependent card. I think that that is a human decision. I propose only to create such a visual dependency relation, but one could move any card to anywhere with no impediment.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jeffix2000]

I suggest it would be more versatile to start with a mere cross-linking functionality. Meaning, I can quote other cards from the one I'm currently editing, ideally with some autocompletion (cf. Git..b), and those cards will automatically be provided with the backlink to my source card.

How to interpret the dependency would be left a purely collective convention of the members in the particular context of any couple of cards or even boards.
This data wouldn't prevent or trigger any action besides backlink generation.

Maybe later we could add a selection of relationship semantics (see Kanboard implementation) but the generic source-target relationship would be a good starter, preferably from free text areas (card description or comments) where some context could be freely provided around the link.

We could thus already cover a wide range of cases like relating-to, duplicating, complementing, detail-planning, depending-on etc. relationships.

[jospoortvliet]

Relations are one way, but I do think that 'hard dependencies' are a good feature to have. Like, a simple input where you can pick any number of cards from the current board which would be dependencies:

I'd imagine you show small card icons there. Maybe, if they have a todo/list, change color based on that. You can't do more - you don't know when they are done or what their status is for sure, as not everybody uses the same columns of course.

[stefan-niedermann]

@jospoortvliet your proposal would require to have a defined finished state (as discussed since 4 years in #534).
Let me remind you also, that the current Project relations do not have a well defined REST API (if I recall correctly, you mentioned some time ago, that there will be changes in those terms) - in my opinion this should be discussed again when solving this issue as you proposed - not only for the Deck Android app, but also for a clean overall architecture of Nextcloud.

Edit: I am open for a call if you want to discuss this deeper 😉

[HammyHavoc]

Just chiming in to say this would be amazing. Currently beyond frustrated with Todoist, and mulled over jumping ship to Vikunja, but having this baked into Nextcloud would be a whole other level of excellence.

[DDriggs00]

Commenting to say that this would be a good idea. I personally like the Kanboard Implementation

[papadopouloskyriakos]

+1