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?
@Marie for info the conversation we have here is similar as this one:
@lpb
I totally agree with you that making a custom field local is the best way to lead to duplicates, so thatās an issue.
Nevertheless, I still think the behavior is not intuitive.
For instance, you have 2 projects: Project #1 and Project #2
If I multi-home a task then:
In Project #1: I have 2 custom fields: 1 Global + 1 Local
I have chosen to have them, so I see them
In project #2, I donāt add those custom fields (as you can see on the ācustomizeā panel) because I donāt need them. But despite everything I find the values of the fields in the task
So finally, even without talking about security, I find it illogical.
So if in the end it would only display what you want to display in a given project, then it would also solve the security problem.
@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!
