In-project dependency dropdowns need to be clearer

[Bobby_Goldstein]

I see this from several years ago and it looks like the feature was supposed to have been implemented. But… it’s not working for me!

What’s more, a lot of projects are created from templates, which means a bunch of tasks have the exact same name

• It’s silly that there’s not a way to narrow the task search to tasks within the project
• It’s sillier that I can’t see the full name of the project
• It’s far worse that I can’t scroll down through all the tasks that match; sometimes the blocking task I want, which, again, is in the same project, is not even on the list

[Bobby_Goldstein]

I have found a couple of workarounds:

• I can often go from the blocked task to the blocking task, and set up the dependency that way
• I can temporarily rename the blocking task to something unique (I have to wait a minute or two before I can find it though)
• I understand that in timeline view I can draw a line from one task to another to set up dependencies

[Phil_Seeman]

@Bobby_Goldstein

It’s silly that there’s not a way to narrow the task search to tasks within the project

Here’s a topic on that which you can vote for (if you haven’t already):

Allow task dependencies to be restricted to current project

When using the dropdown list for task dependency selection, tasks from all projects meeting the “type ahead” criteria are displayed. When the task name is too long to show the Project name in the selection box, it is impossible to identify the correct task. Restricting the selection list to the current project would be helpful. Alternatively, expanding the hover function to include the Project name would help as well. Note that the functionality works as desired in Templates

[Bobby_Goldstein]

Yep, thanks, that’s exactly what I want. But also, it sticks in my craw that we’re being asked to vote for something like this. This feels much less like asking for a new feature and much more like a bug fix, which we shouldn’t have to be asking for

[Phil_Seeman]

@Bobby_Goldstein

and much more like a bug fix,

A bug is where the product is not working as designed. In this case, for better or worse - OK, here I totally agree it’s for worse! - it’s working as designed.

[Bobby_Goldstein]

I did say it feels more like a bug fix, which I don’t think you can seriously argue against

And also, I disagree that it’s working as designed. IMO there’s far more robust evidence that it just… wasn’t designed. I seriously doubt that someone thought, “let’s intentionally set this up so that the user can’t use it”

[Jan-Rienk]

@Bobby_Goldstein @Phil_Seeman The favourite expression I’ve found describing this is:

“Some bugs aren’t in the software, but in understanding”

[Irene_Adler]

If this is working as designed, then it is a bad design.

[Garrett_Knoll]

Thank you all for the great feedback! I’m passing along this feedback to our new dependencies PM @Connie_Fan who is passionate about getting details like this right.