Custom Task Type Status Options Incorrect in iOS App

[Skyler]

There’s an issue / bug with the custom task type status options in the iOS app. The status options on mobile are incorrect and do not mirror what has been set in the web app.

• Asana app for iOS is using the current version (10.69.0)

Example

Below is a task on mobile. You can see a set of status options in the drawer.

And here is the same task and its set of status options via the web app.

The web app is correct. There should only be 4 status options available. The mobile app is, for some reason, displaying 3 options that shouldn’t be there. Here’s the custom task type’s settings as well:

Troubleshooting Attempts

• I checked the App Store to confirm I was using the latest version. I am.
• I forced the app to refresh multiple times. Issue persists.
• I forced closed the app and relaunched it multiple times. Issue persists.
• I restarted my phone and launched the app. Issue persists.

Background/Historical Context

• The erroneous statuses present on iOS were originally status options prior to last week when I modified the custom task type.
• I modified it by removing Triage and Backlog from the status options.
• I am unsure where the erroneous C status option derives from.

Issue Impacts Downstream Work Because It Breaks Logic in Rules

• I noticed this issue when some rules I have set failed to run when I changed the status of another custom task type on iOS.
• For context, I have another custom task type (which doesn’t have issues on mobile) that, when I set it to a certain status in a ︎ Backlog project, a rule runs that converts it into another task type, adds it to another project called ︎ Work (WIP) and removes it from the ︎ Backlog project.
  • e.g., I triage and manage tasks in a upstream Kanban board called ︎ Backlog and manage work I’m actively working on during the current cycle in a downstream Kanban board called ︎ Work.
• However, because there seems to be some issue with one of the task types, the rule never ran, never changed the task type, nor moved it how it does in the web app.
• Instead, I manually added it to the downstream board and converted it into the proper task type manually on iOS. I noticed the issue when I went to update the status right after that.

Note: I am not using a single task type to manage all of the statuses because I cannot collapse columns in the board view. Hiding empty columns is insufficient as I need some columns to show regardless of whether they’re empty or not.

---

Anyone have any idea what’s going on here or able to reproduce anything similar? I’ll keep testing to see what I can come up with, but if anyone has any recommendations, let me know.

[Jeremy_Long]

@Skyler, I notice the task is multi-homed. Is it possible that it’s picking up the default task type options from the other project?

[Jan-Rienk]

@Skyler I moved this from English Forum > Product Feedback to English Forum > Ask the Community as that is a better place to discuss bugs.

Best to contact support on this one, and would appreciate if you kept us posted in this thread.

[Liz_Carpio]

Hi @Skyler, Thanks for reaching out and sharing this!
This might be a bug, so to make sure it gets looked into properly, please follow the steps in this guide to contact our support team directly:
How to contact our Support Team
They’ll be able to take a closer look and assist you. Thanks again

[Skyler]

Thanks @Liz_Carpio. I’ve submitted a ticket about the issue.^[1]

Underlying Cause Hypothesis

I think this is definitely a bug. I made an API request to the Get a custom type endpoint for the specific custom_type_gid affected by this issue.

Each custom_type has an associated status_options list, where each status option includes an enabled boolean property that determines whether that status should be available for use with that custom type.

In both the web app and the desktop app, only status options with enabled = true are displayed, which is expected behavior. However, in the mobile app, status options with enabled = false are also being shown.

This suggests the mobile app is either not honoring the enabled flag on the status_options associated with the custom type when rendering available statuses or the logic used to determine which status_options are displayed is not set to exclude those where enabled = false.

---

1. The link in the first bullet point of that How to contact our Support Team post directs to a 404 page on my end btw. ↩︎