What do you mean?
We use Jira and Asana, and I don’t think my team would use Asana without being able to identify the ticket for the task without a Ticket Number as they do in Jira. So we stick with Jira for daily tasks, which I keep the overview of the project in Asana, leading to an unintegrated system. If I could use Asana, it would like our waterfall plans to our daily scrums and I could just call out ticket numbers as shorthand during scrum.
I understand from reading others’ comments that there are numbers for each ticket, but it seems like they are long and/or hidden. I am a perpetual novice user without IT skills. If I ask for an add-on or have to pay for integration with another program, I will be questioned about paying for the add-on, or why I adopted a program that did not have what I needed in the first place. It would be ideal for us to have numbering for tasks as in a ticketing system.
In Jira, our tickets are created within each project so the ticket under our COVID project might be C19-148. Very easy to say to a colleague - “Hey, I sent you a ticket yesterday, deadline is today, can you take a look at C19-148.”
Thanks for your quick response - hope I explained it clearly enough.
There are several solutions to this, including Flowsana from @Phil_Seeman and astogi which has this auto-numbering feature.
Yes, I anticipate push-back if I ask for another program. But some department won’t adopt without ticket numbers, so I’ll have to wait until an opportune time to try to get Flowsana or Astogi. The reply seems to imply that Asana itself does not have plans to add ticket numbering to the feature set. Thanks for getting back to me and for providing resources to take the next step.
Asana does not communicate on their roadmap. My personal guess: they won’t, for 2 reasons: other 3rd party do it well, a tiny portion of users need it. (I don’t work for Asana)
For T3. Rules: You can apply rules based on any custom field, or all custom fields, BUT not only certain custom fields: Need “Contains only” option for multi-select fields in Rules
Thanks @Christina_Davies, I feel like for now this is not a BUT but just a missing feature. Feel free to challenge.
Today was my regular check, I believe the list is still correct, nothing to remove.
@Gerald_Thomas I created B6.9 and B6.10, does it make sense?
Also added B3.5 B8.1 B7.3 B7.4
Hi @Bastien_Siebman, I think B8.1 is no longer an issue (!)
I added B7.5 and B8.1 is indeed fixed!
@Bastien_Siebman: My biggest BUT at the moment: No DEV-Team would ever like to use Asana without that feature: Code snippets in Asana - #280 by Albert_Reiner
Even as product owner, I miss that feature.
Tables in task descriptions are already announced. But I think code blocks are much more important, because then Asana gets relevant for a whole new target group.
I understand. I don’t see it as a BUT but just a missing feature…
Added 2 BUTs:
B2.4 A template allows to define due dates relative to project start or due date BUT a task converted to a project using a template in a rule will use the trigger date.
B9.1 A task audit trail will show an incoming mention BUT it won’t show future mentions if the source task was recurring.
@Bastien_Siebman , a suggestion for B4.2:
When you add custom fields to a Portfolio, you can ‘Add or hide fields’ in the status update of all the projects that belong to that portfolio BUT if you add custom fields to a nested Portfolio, then these custom fields are not available in the ‘Add or hide fields’ part of the Portfolio’s status update (in the portfolios ‘Progress’ tab). Tricky to summarise
I’ll collect my brain on the floor and get back to you shortly
If I re-phrase, a status update at the portfolio level won’t let you hide or show fields? what’s the link with nested portfolios?
Correct, a status update of a portfolio (from its ‘Progress’ tab) cannot show/hide any custom fields.
The only way (that I know of) to add such custom fields to a portfolio is to nest that portfolio in a ‘master’ portfolio in which those custom fields are added to. So even by doing this, these fields cannot be shown/hidden in the status update of such portfolios that are nested within the master portfolio.
That seems like a very specific use case, I’ll put it aside for now if that’s ok with you.