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.
You can add text fields to your tasks BUT you can’t search them! For example, I have a text field called PO#, but I can’t use the search feature to find any individual POs.
You can search text fields. Have you tried Advanced Search > Add filter > Custom field?
I had attempted that, and I just did again. Using “Contains the words” did not work. However, I just now had success using “Is exactly” which is a little less convenient if I don’t know the entire PO, but at least workable.
Rules can be related to what is occurring to any task of that type in a project (a blocked task or one requiring approval) but rules can’t be associated with specific tags or tasks by name.
I am not entirely convinced that’s a BUT. It is expected that rules won’t cover every single use case and features, so for now we decided not to add this in the list. @lpb what do you think?
I agree with your call, @Bastien_Siebman! It can be a bit of a judgment call at times, but that seems reasonable.
B5.3 & B6.4 are no longer BUTs.
Maybe edit them to be in strikethrough font?
@Phil_Seeman they are, aren’t they?
Yeah, they are now - they weren’t when I looked before - screen refresh/cache issue in my browser, I guess.
fyi I was able to share this post with Asana’s Product team and they were very interested, they are going to deep dive and compare the content with what is on the roadmap.