Guest should only see the custom fields of the project(s) they have access to

Hi @Marie and @Emily_Roman

I have just done some tests to understand what a guest may or may not see in an organization.

For example, here my setup:

  • A project A that I keep visible internally, with custom fields that contain confidential information for certain tasks.
  • A project B is shared with the client, in which I make some tasks from project A appear.

Confidential custom fields are declared in the project A, but I didn’t add them to project B, but still the values of the confidential fields appear in the tasks shared with the customers.
This doesn’t look good from a security point of view? is this normal or a bug?

I add that projects A and B are both private.
If the confidential custom field is not added to the organization’s library, then not visible by the guests.
If the confidential custom field is added to the organization’s library, then it is visible in grey by the guests, and can be deleted by him (not changed).
So the solution could be to have the custom field not in the library, but if it needs to appear in many internal projects then this is not a solution.

Julien
(@Bastien_Siebman it will be in the categories of the weird tests of Bastien & Julien :wink: even if in this case it is rather surprising from a security point of view :thinking:)

Hi @Julien_RENAUD! I’ll need to test this and investigate further. I’ll confirm as soon as I have more details :raised_hands:

We knew that for a long time, I raised the issue couple of months ago and have been warning people ever since :scream: I recently learned that if the fields are not part of the library, you are fine though.

Hi @Julien_RENAUD, I investigated this further and I confirm this is currently working as expected. Marie had also a similar question before and she sent more information here:

4 Likes

Thank you @Emily_Roman for your answer.

I just read the post you are referring to, and it is now closed.
Will the security be improved soon by the development team ? because I totally agree with those who wrote in the post, that’s how it works today but it’s a big security flaw. And I thank @lpb for trying to propose alternatives, but it’s too complicated to implement at customers, it makes the use of Asana too subtle and counter intuitive.

Hi @Juan_Diego
I’m now facing the same difficulty you had with visible custom fields when I didn’t think it would be the case, as you explained in the following post:

I find it difficult to find a simple and intuitive solution to implement.
The post is more than a year old, what solution did you finally put in place?

Other @cpforumleader, feel free to jump in the conversation, and if you have a solution that can be used by a non-expert Asana customer, then you’ll make my day awesome :slight_smile: :tada:

Sorry no, I’m still trapped!

1 Like

The “simplest” solution I’ve found so far: define the field as local (not in the organization’s library).

Advantage: the customer doesn’t see the field, and it works the way we want it to.

Disadvantages:

  • the field must be local for each client, so there are as many different fields as there are clients.
  • the field can no longer be used in advanced searches

So there are a few drawbacks, but for the moment it is the least complicated.

2 Likes

@Julien_RENAUD any new workaround to list on 🔥 Hottest feature requests and their workarounds ?

Concerning this custom field access issue, I don’t have other solutions than the one I explained above :cry:

1 Like