@Marie this does seem odd that the user would be able to view the value, and even worse be able to delete that value, for a custom field that’s attached to a project the user doesn’t have access to, and is in a team that the user doesn’t belong to. Seems like a bug?
Prevent users to edit Custom Fields nested in Projects they don't have access to (multi-homed Tasks)
The greyed custom field and trash can is what you get when you remove a field from a project doesn’t it? Fields keep appearing for I don’t know how long.
@Juan_Diego am I right there?
Interesting - maybe so, personally I wasn’t aware that Asana did that.
Nonetheless, that’s not what’s going on in this scenario. In this case, the custom field was never removed from a project - it never existed in the project that the user had access to, only in the project he did not have access to; yet it shows up in the task in his My Tasks list. Still seems like a bug to me, unless I’m missing something.
@Bastien_Siebman no matter how long is shown, the problem is that a user without permissions it seeing it.
Besides the field hasn’t been deleted, it exists.
My point was: this is probably a bug, they forgot to apply “permissions-to-see” on the deleted fields. cc @Marie that seems like a serious bug
I’m not sure this is a bug - I was too able to reproduce but only when my project settings were set so tasks collaborators can edit the project, which includes custom fields (see screenshot below).
If I set permissions to “can comment” for tasks collaborators, they don’t have the option to delete or modify custom fields in this project.
@Juan_Diego, can you confirm what the permission settings are for this project?
@Marie I set both projects to Comment only for collaborators, but Jandieg was still able to read and remove the field.
I’m getting the same results as @Juan_Diego - I made the project “comment-only” - when I do that, some fields disappear from the task (like Description) but the custom field is still displayed.
Thank you both for the additional information; I’ve just filed a bug with our Team and will be in touch as soon as I get an update!
Thank you all for your patience!
I’ve worked closely with our support and dev team to investigate this behavior and I can confirm this is not a bug or the result of a recent change; this is in fact how custom fields in multi-homed tasks have behaved since their original launch; but let me give you more context to understand why this is happening:
In our guide article dedicated to custom fields, we mention that “Anyone with access to a task can modify the values of its custom fields.” This is because the data from custom fields “lives on the task”, so even if you don’t have access to the container project that bestowed the field definition on the task, you can still see any data set on the task.
In this specific case, you’re correct, Jandieg can indeed clear the data for the Estimation field. This does not remove the field from the Budget project, but does clear the field value for all users. And I see why this would be a concern; although it hasn’t been prioritized yet our team is planning to improve this workflow in the future; when they do, I’ll make sure to post in #community-forum-announcements or keep you posted on this thread. In the meantime, if someone clears one if this fields, note that they do appear in your task activity.
Again, we do recognize that there is room for improvement here and rest ensured that our team is aware of it and will look into a better solution for this; so stay tuned!
It might not technically be a bug, but in real life is allowing users/customers to see data they are not allowed to see.
The main reason we chose Asana was privacy, it seemed to handle privacy very well (except for this finding)
This is preventing team work across different areas, it is leaving the multi-homed tasks purpose ineffective for us.
I see you changed the original subject, it is a privacy leak as I originally defined it. Seems you are trying to minimize the problem but this is a big problem for us and I’m sure for many (yet haven’t noticed it)
This should be a priority to you, can you please prioritize this?
Thanks for the follow-up @Juan_Diego,
I completely understand where you’re coming from and why this is a pain for you! While I can’t promise our Development can prioritise it right away, this is definitely something they’re committed to look into! I’ll make sure to keep you in the loop as soon as I have an update on my end.
Agin, sincere apologies for the trouble here, and thank you so much for taking the time to share your thoughts with us!
All the best,
I don’t know how others are doing this, I mean how to work on a same project with a client or 3rd party but hiding its confidential information?
Which should be the temporary workaround for this?
I am re-reading this and I am confused. I always said that a user won’t see the fields from a project he does not have access to, so you can have two sets of people completing two sets of fields, without seeing the other ones… Was I incorrect and anyone with access to the task can see all fields?
From what I experience, fields are seen by anyone with access to the task, even if the fields come from a proyect on which the user has no access. For me this is a big privacy issue.
Agreed, I was certain it was not the case…
I just tried again with @lpb. Invited him as a guest on a task, he is not a member of the project, but he can see all the filled fields of the task with value…
Custom field values, like anything else in the task, is visible if the task is visible.
I too wish there was a way to have some task information project-related and visible only if you have visibility into that project, but nothing like that exists.
They are hacks but two workarounds exist:
One would be to add a link to a task in a private (to some) project as I mentioned here:
That link will appear as Private Link to those w/o access. For the rest, it could contain the set of “private” custom fields.
Another approach: Define private (to some) projects for each binary piece of data you want to privately attach to a task so that it’s seen by some people but not others. For example, instead of a custom field like Client Is In Arrears? (true/false), create a private project called Client Is In Arrears. Multi-home the task to that project if the client is in arrears; in the task, if it’s multi-homed there, those with access to that project will see that project link, anyone else will not see any such link. You could multi-home to multiple ones of these, though this could be more tedius than the first suggestion.
Hope one helps,
Thanks for the tips Larry. I usually advise to use #1. Not sure how I feel about #2 yet