A few months ago, I learned that there is a small “gap” in #asana’s security regarding custom fields: if someone can see a task, they can see all its custom fields, even if originating from a project they don’t have the rights to see!
Today, I learned that the situation is actually a bit more “secure”: users will only see values for custom fields within the library of the organization, and not custom fields restrained at the project level. So if you want to store sensitive information, make sure to not include the field in the organization library.
Great tip, @Bastien_Siebman. That’s precisely the question we should be asking ourselves when building custom fields. "Is this something someone else could use throughout the organization or data that I feel would be impactful in other projects? Typically, the answer to that question also addresses the sensitive of the information. Data that is helpful elsewhere, and to others, is likely to be public knowledge.
That said, perhaps not save to the organization library by default if you are unsure. Why? Because it is incredibly simply to go back to any previously built custom field and enable it to appear within the organization library. This isn’t a single pass decision like identifying what type of custom field to use (text, dropdown, etc)
Update: As pointed out in later posts, you do lose the ability to search across custom fields if they are project-specific. So again, it is important to know how sensitive the information is that you will be placing within custom fields!
The common use case is: I have sensitive data in a task so I’ll make sure that task is not visible to those who shouldn’t see any of its sensitive data, and I’ll freely use global custom fields where I 1) expect to use the custom field in more than one project, and/or 2) I want to be able to use the advanced search feature to find it.
The problem you’re warning against is rare and usually addressed as above; just don’t allow access to the task, rather than throwing the baby out with the bathwater (Bastien, I hope you know that expression or else it will appear quite odd to you unless it’s found in French too!)
Recognize that multi-homing will share the task as a whole, including all but local project custom fields.
Of course, if the custom field definition itself has sensitive captions or values, you’d never want to make that a global custom field.
I also disagree with:
While it’s true it’s easy to convert the custom field itself from a single-project-only custom field to a global one, not anticipating and putting it on the org-wide library of global custom fields hides its existence and leads against reuse and toward multiple similar custom fields. And the instantiation of those fields in projects (as opposed to the field itself) are not convertible. You must go through the tedious steps, in each project, of adding the new global custom field, showing All tasks (not just completed ones), sorting by local custom field, batch-selecting groups of 50 tasks, replicating the value of the local custom field in the new global custom field, then removing the local custom field.
With @Julien_RENAUD we have seen cases of clients who, for example, store the time it took to do the task in a field, but they don’t want the client to see it. Working your way around this could be cumbersome
What I get from the discussion is that there no idea situation, and benefit/losses for all of them!
I didn’t consider this. You mean you lose the ability to search for it when creating a Custom Field? I assume you can still use the Advanced Search to locate any Custom Fields that are project specific?
@lpb I completely see your point and holistically agree. I don’t think there is a need to persuade as there is to clarify. When I said the following…
… I’m simply insinuating that it is important to be mindful of how you are using custom fields with a high level of confidence in how public the information should be. While it is easy to convert a field, it is certainly more difficult to consolidate any redundant global fields… as you pointed out.
I’m suggesting to not make stuff global if the information is potentially private. Rarely would I expect a custom field would have to be made global if the intent is understood upfront. However, when necessary, so be it. It’s a risk vs reward scenario, IMO
I tried to summarize in my post above, but it’s pretty hard to convey. For example, I really didn’t understand @Julien_RENAUD’s most recent post above?! And I don’t know if mind was fully understood based on the subsequent posts. Maybe Forum is not the ideal place for such nuanced takes?
@Julien_RENAUD I’ve always seen the custom fields you show as columns from List or Board to be a different consideration from what is represented in the tasks. A couple questions to make sure I am understanding this correctly.
Guests can enable any custom fields that aren’t show on a project, correct? They just can’t edit the criteria. If that is the case, it doesn’t really solve the security issue, right?
Are you suggesting that you disable (from the “customize” panel) projects that you don’t need? Why have them on the project then? As stated before, I’ve always looked at what is shown on the project level different from what is shown in the task. To keep the project view clean, I don’t always show all custom fields they they still might be necessary for the project.
Personally, I live that the customize field doesn’t control what is shown from both the project view and the task view. I will say, I would prefer that from the task view, all the custom fields that are mapped through multi-homing exist within a clickable link to “show more” rather than showing an extensive list by default.
@Julien_RENAUD, I appreciate the clarification. But you’re now asking for feature changes whereas the thread had previously been debating how best to use the app (as it operates now). I think it would be better to discuss that elsewhere. You’re also calling for eliminating what @Bastien_Siebman has called “cherry-picking” custom fields; I’d be against that!
I was surprised to see this being called a “gap” in security, and I feel that’s unfair on Asana. To me, it’s just how Asana works, and makes sense. Custom field details are part of the task information, so if a user chooses to share the task with someone new (eg by multi-homing the task to a project the new person can see), it makes sense for the new person to see the custom fields as well. It would seem to make less sense to restrict this by default, because the new person may not have the information they need to deal with the task. If people want more control than what Asana currently offers concerning who can see what, it could be achieved with more detailed sharing permission settings rather than changing the default way custom fields are displayed.
Another interesting tidbit I learned in this process too — forms are totally public links. We used to have a form with a custom field dropdown list of “future campaigns” for requesting briefs. Well, that form link is public so literally anyone could see it!
We’ve since amended that form to remove the custom field. But we did suggest to the Asana team that restricting forms to logged-in users (and then capturing the user data) would be beneficial for a number of reasons!