Fix inconsistent rule trigger behavior between list and board view

[Skyler]

@Richard_Sather, @lpb - Do either of you folks think this is a bug?

Quick Overview

• “Custom task type is changed” triggers behave differently between board and list views when the views are grouped by that custom task type.
• Moving a task up or down within the same group in list view DOES NOT trip the “Custom task type is changed” trigger. This makes sense and is expected behavior.
• Moving a task up or down within the same group (column) in a board view DOES trip the “Custom task type is changed” trigger. This does not make sense, is inconsistent with the list view, and is not expected behavior.
• Moving a task up or down within a board view that is grouped by a custom task type should only trip a "Custom Type is changed` trigger when that task is moved from one column to another—not when it is manually reordered within the same column.

---

Further Breakdown with Screenshots

I’ll establish how I understand the trigger to work first so you folks can tell me if I’m crazy.

Premise: the trigger for when {custom_task_type} is changed falls under the Status is changed group of triggers as show in the image below.

Therefore, this trigger should only fire when the “status value” of the custom_task_type changes. Would anyone disagree with that?

For example, consider the rule depicted in the image below. If working correctly, this rule should only set the value of the Updated field to the date the rule was triggered when the status value of the “Work” custom task type changes.

Now, let’s say you have a Board view set to group by the “Work” custom_task_type our rule’s trigger uses as shown in the image below.

Next, let’s say you manually sort things by moving one card above or below another but keep it in the same column.

Since the columns represent the custom task type’s status and the moved card never changed columns, would you agree that this should NOT trigger our rule because the custom task’s status never changed?

Because as of now, this behavior causes the rule to trigger. For some reason, reordering a task in a board grouped by the custom task status makes the system somehow think the custom task’s status has changed…when it clearly hasn’t.

---

And lastly, another reason I think this is a bug is because manually moving a task up/down within its group does not trigger the rule if I do it in a List view. But it does in the Board view. How does that make any sense?

[lpb]

I 100% agree, @Skyler.

I believe this is a bug (or I’d really have to be convinced why not!).

I wonder if it might be caused by an unintended side effect of the move-within-column in list view and just went uncaught before release?

@Forum-team, please escalate!

Thanks,

Larry

[Skyler]

Yeah, it definitely seems like it’s something that must’ve just slipped through when doing QA Boards.

I can’t test if using the Move selected task(s) up/down keyboard shortcuts ⌘ ↑ / ⌘ ↓ will also trigger it because those are broken in the Board view too.

However, thankfully @Phil_Seeman made Flowsana. I built the same logic in there and can confirm Flowsana handles it correctly and isn’t triggering the same way things are in Asana.

So, it seems like whatever event the Rule logic uses isn’t based on a custom_task.status_option.change() event but something else.

Example: Working Flowsana Rule

[Phil_Seeman]

Definitely a bug.

Visually moving it within a column on a Board when configured like you illustrate should not trigger the rule. Only a change in value should trigger it (which is the way we do it in Flowsana).

(If @Forum-team confirms it as a bug, it should get moved to English Forum > Ask the Community and tagged accordingly.)

[Joanna_Colgan]

Hey @Skyler , thanks for spotting and flagging this!

I have reported the bug internally and will be in touch whenever updates are available.

Thanks, @Phil_Seeman and @lpb, for looking into this and for your insights.

[Skyler]

Thanks @Joanna_Colgan!