#1953 Feature Request: Create UI setting for board's default behaviour for subtasks' swimlane

[Anonymous]

Originally created by: BjoernLudwig

When creating subtasks from the according section inside an existing task, the subtask will be created in the upper most swimlane, where as usually the appropriate swimlane might be the same as the parent's task one, at least the way we structure our boards.

An option might be, to introduce another subtask related setting equivalent to the one for choosing a list for subtasks from other boards, to choose between:

• same as parent
• swimlane1
• swimlane2
• ...

where the actual swimlanes will be listed underneath the option 'same as parent'.

That might look like:

[Anonymous]

Originally posted by: Keelan

Good feature. Running into this right now. Anyway to at least copy to the same level swimlane by default without create an whole UI option

[Anonymous]

Originally posted by: xet7

@Keelan

Please add screenshot mockup about what do you mean, and how it should work.

[Anonymous]

Originally posted by: TOSCom-DanielEder

@xet7 I believe what Keelan is referring to, is making this default behaviour.
Right now a subtask will be created in the uppermost (or possible first/oldest) swimlane, ignoring where their parent is. It would probably make more sense for most use cases to have the subtask remain in the same lane as the parent task.

Example:
Red arrow is the current behavior, green arrow is the desired behavior.
A config option is naturally the best long term solution, but for the short-term this default behavior might be a lot easier to implement and go a long way in terms of usability.

EDIT: Time does not allow setting up a wekan dev environment just now, but this one line change should lead to the behaviour described above:

--- "a/client/components/cards/subtasks.js"
+++ "b/client/components/cards/subtasks.js"
@@ -20,7 +20,7 @@ BlazeComponent.extendComponent({
     const crtBoard = Boards.findOne(card.boardId);
     const targetBoard = crtBoard.getDefaultSubtasksBoard();
     const listId = targetBoard.getDefaultSubtasksListId();

-    const swimlaneId = targetBoard.getDefaultSwimline()._id;
+    const swimlaneId = card.swimlaneId;

     if (title) {
       const _id = Cards.insert({

If no one can test & PR this, I will set one up in the near future.

[Anonymous]

Originally posted by: Keelan

const swimlaneId = card.swimlaneId;
Wouldnt this set the subtask swimlane ID to that of the current card's swimlane ID (parent)?

Is swimlaneId persistent across boards? Or if you plan to drop subtasks on the same board as the parent. If so then this makes sense.

If not, wouldnt we have to do some some swimlane position lookup on the parent board and to drop the subtask into the nth swimlane on the sub board? Or try to match by Swimlane name

      getDefaultSwimline() {
        let result = Swimlanes.findOne({ boardId: this._id });
        if (result === undefined) {
          Swimlanes.insert({
            title: TAPi18n.__('default'),
            boardId: this._id,
          });
          result = Swimlanes.findOne({ boardId: this._id });
        }
        return result;
      },

Why is some items called swimlane and some called swimline?

[Anonymous]

Originally posted by: TOSCom-DanielEder

That is absolutely correct, I was basing this on a same-board scenario I had in mind, which obviously fails to handle two-board scenarios.

I should say a matching by name is probably the most logical approach, as boards might have different amounts of swimlanes, and the swimlane position therefore might be off. If the name matching fails, falling back to the board's default lane should be a solid approach.

EDIT: I updated PR #2976 to match by parent swimlane title first, and fall back to the default lane. This enables the desired behavior independent of the parent/child board settings.

[Anonymous]

Originally posted by: BjoernLudwig

It's awesome to see so much activity around this proposal and @Keelan's idea of creating a more intuitive default behaviour as a first step. Thanks @TOSCom-DanielEder and @Keelan !

[Anonymous]

Originally posted by: BjoernLudwig

We now have a more intuitive default behaviour resolved by [#2976] described in the according PR's comment. The UI setting described with a mock-up in the opening comment is still desirable.