and the same thing collapsed appears like this, showing that the rollup of subtask value to parent task appears in the parent’s cell:
Shouldn’t a rollup of that field in a portfolio formula field see that subtask’s value as part of the rollup? I’m using this formula for that portfolio custom field:
Hi @lpb, thank you for the additional information. Since this is a separate issue, I’ve moved it to a new topic in the English Forum > Tips and Tricks category. I’ll report this to our Developers and will let you know once I have updates from them.
Hi @lpb, just following up here: I’ve escalated the issue with the subtasks rollup to our Developers and hope to hear back soon. However, I wasn’t able to replicate the error message when adding the additional field.
To provide our Developers with as much detail as possible, could you confirm if this is happening in your legacy space? Just a guess, since the initial bug seemed to affect legacy spaces only.
Per @Vanessa_N’s offline instructions, I’ve asked my client to report to Support. The problems are still happening as of right now in their environments.
Hi @Tetsuo_Kawakami, thanks for testing this on your end! I’m sorry, I just noticed that I had added that field in the portfolio, but with the column hidden, so I didn’t see it was there. That’s why it was working on my end. When I removed it from the portfolio I did get the same error message.
@lpb, apologies if I’m missing something here, but I’m wondering if you could share more about the issue to help me escalate it. I’m testing with fake data, and the rollup issue with incorrect values is making it tricky to verify the results:
What I understood (and could replicate now) is that a portfolio formula works when using a project’s formula field (field 1) as an input, even if that field isn’t in the portfolio.
However, if you try to use that same field in the additional formula step (+ field 1 [to include main task values]), it doesn’t work unless the field is explicitly added to the portfolio.
Before I pass this along to the developers, I just want to make sure I’m understanding the core issue.
Is the concern that the non-portfolio field works in one case but not the other?
And if adding the field to the portfolio would solve the issue, is there a reason that can’t be done in your case, aside from it not being intuitive or requiring extra steps (for example, it affects the formula results, or it impacts the portfolio)? Of course, I’ll still report and investigate this as a potential bug. I just want to understand the full picture as much as possible to help our Developers.
Thank you so much for your patience with me . This is a kind of issue that normally should go through our Support team, but since I’m already working with the Developers on the rollup issues, I’m doing my best to sort this out here in the Forum.
the field in rollup() refers to one in a project.
the field after + refers to one in a portfolio.
– that’s why I couldn’t add the field after + when the field doesn’t exist in a portfolio.
and that above makes sense for me.Because rollup() refer to its first lower level fields as the description of rollup() says below,
when formula fields of rollup() exist in projects of portfolios, they refer to tasks’(top level) fields of projects.
when formula fields of rollup() exist in tasks of projects, they refer to subtasks’ fields of tasks.
when formula fields of rollup() exist in subtasks of tasks, they refer to subtasks’ fields of the subtasks.
– but the value would be always empty except subtasks are multihomed to projects because subtasks don’t have the field.
My client did write Support and cc me so we’re awaiting reply.
I won’t have time to work on this today, but yesterday I briefly determined that I actually didn’t have the custom field in the portfolio when I tried the + custom field form of the rollup() and when I added it to the portfolio I was able to save without seeing the syntax error; my bad.
However, Tetsuo’s approach which works for top-level tasks gave me unpredictable results when used for a subtask. I’m not sure if I did something wrong or if it’s just not working. And I’m afraid I didn’t quite understand your last post above, Tetsuo, but I didn’t have enough time to spend on it.
Apparently the bug would gone away. I confirmed the workaround works well for task/subtask. I assume that rollup() would sum up both fields of tasks and subtasks now. That is @lpb 's thought.
I don’t know whether there is anyone who want to sum up only tasks’ field. But if there is someone who want to do it,there is no way, I think. Anyway this solution provides easier way in major use cases.
I reconfirm that. Unfortunately it seems that the behavior of rollup() returned to its previous one.
I think the root cause is the following.
When values of subtasks are changed, rollup() does NOT refresh itself.
Sounds like you’re saying you think that’s the reason why it’s not working for me. That would be a possibility since to clarify I’m no longer getting an error but I’m getting unexpected rollup results.
Did you find any way to get rollup to refresh, even if not practical, just to see it working temporarily at least?
But @Vanessa_N, this sounds like something the developers should check out.
By the way, my client and I got a reply from Support:
It would appear that Vanessa and Tetsuo have been assisting you via the link provided:
https://forum.asana.com/t/1-shouldn-t-a-rollup-of-a-number-in-a-portfolio-formula-custom-field-see-that-subtask-s-value-as-part-of-the-rollup-2-one-form-of-rollup-syntax-seems-to-generate-error/1041226
Please kindly continue following up with Vanessa and Tetsuo via the forum.
It normally doesn’t make sense. But in this case, it seems to force Asana to refresh rollup(due date - dummy date) in No.1. Therefore it’s so important😏.
I hope rollup() refreshes itself without doing this.
Go for it, Asana develpers!
Thanks for the workaround, @Tetsuo_Kawakami, but I will wait for the developers because the client has many projects to update so I’d like to know the final resolution on Asana’s side because it seems the you’ve identified a refresh problem on their end and that would be the sustainable way to address the problem without workarounds, if possible.
Hi @lpb, I’m sorry the Support agent redirected you back here. I’ll follow up with the Support team to have the case reviewed internally.
Since we now understand this isn’t an account-specific issue, I’m happy to continue troubleshooting here.
Our Developers are still investigating, but so far, they haven’t identified any bugs. Based on these additional tests, it looks like we just need confirmation on the rollup refresh behavior, and the possibility to have this work without using workarounds. Does that sound right?
. This is a kind of issue that normally should go through our Support team, but since I’m already working with the Developers on the rollup issues, I’m doing my best to sort this out here in the Forum.
