Upcoming changes to project privacy settings

Hello!

We’re making changes to project privacy settings. This post outlines the Asana API changes coming to support this new functionality.

Who is Impacted

You might be impacted or interested in these updates if your application reads, creates, or modifies projects.

For example:

  • Fetching a project to determine if it is public
  • Creating a project
  • Creating a project from a template
  • Updating a project to be private or public

What’s new

Project privacy setting

Soon, projects will have a privacy_setting to determine whether they are public to a workspace, private to a team, or private. Here are the possible values (including a temporary value).

If not specified, a project’s default privacy_setting will be private_to_team or a default that the Asana admin has set.

privacy_setting Project visibility
public_to_workspace The project is visible to anyone in the Asana workspace
private_to_team (temporary) The project is visible only to members of the team. This will be deprecated once projects can be shared with teams (see note below).
private Project is visible only to project members

A note on private_to_team: When Asana introduces teams as project members (targeting: beginning of 2024), this setting will be deprecated in favor of private. A project can be marked private and shared with one or more teams.

Temporary Restrictions for Private Teams

To prevent a breaking API change, private teams will not be able to have projects with privacy_setting: public_to_workspace. In addition, if a team has a public_to_workspace project, it cannot be changed to a private team until all of its projects are also private or private_to_team. This is to prevent a project from having a null team value because the team is not visible to an API user. As a workaround, users may move a project into a public team.

These restrictions will be lifted once we’ve communicated and implemented the ability to create a project without a team association. More to come on this!

Deprecating the public field

Once this feature is rolled out out to all Asana customers in October, we will begin a deprecation cycle for the boolean public field on projects. This property will be removed in favor of privacy_setting.

During the opt-in period, you can use this flag to preview the change:

Asana-Enable: project_privacy_setting

This change will be made to any endpoint which exposes the project resource, including:

  • GET, POST /projects
  • GET, PUT /projects/{project_gid}
  • POST /teams/{team_gid}/projects
  • POST /workspaces/{workspace_gid}/projects
  • POST /project_templates/{project_template_gid}/instantiateProject
  • POST /projects/createFromAsanaTemplate

Reason for change

Today, projects that are public to private teams or membership by request teams cannot be private to org, and projects that are public to public teams must be public to org.

With these changes, users will be able to make their project private to members, private to team, or shared with their organization.

Timeline

Here is a rough timeline we are targeting for these changes which may be adjusted. We will post updates in this thread. You can subscribe to this thread for updates.

Updated: September 14, 2023

Beginning of November 2023

  • A gradual rollout begins for privacy_setting on projects in the Asana web app

End of November 2023

  • privacy_setting is fully released to all Asana customers
  • Use Asana-Enable: project_privacy_setting header to opt-in to preview projects without public over the the API

Beginning 2024

  • Temporary restrictions for private teams (mentioned above) will be removed.

March 2024

  • Use an Asana-Disable header to opt-out of projects without public over the the API

June 2024

  • public field is deprecated

Let us know if you have questions or thoughts! I will be unavailable for the next week, but you may get a reply from someone else, or I will respond when I return. Apologies in advance for the delay.

Thanks!
John Baldo
Asana API Team

1 Like

@John_Baldo, if I’m understanding this correctly, then if you do the above change, you’re going to find yourselves in the same problematic situation that Asana finds itself right now with the breaking change you just made that reduced the default project permissions (and without any warning).

Along with @lpb, @Bastien_Siebman and others, we’re hoping you reverse the current change and make admin the default for projects; and (again if I’m understanding this upcoming change, which I may not be), I think you’re going to repeat the same mistake by reducing the default access on a project and forcing users to visit each and every project that used to be private to team and invite the team as a member of every such project.

I realize both of these changes are at the core product level, not just the API; but please encourage the powers-that-be to think this through and don’t make the same mistake twice!

(But actually I hope I’m wrong in my interpretation of this upcoming change.)

Thanks, @Phil_Seeman . I’ve passed that on. Good point. Since I’ll be out for a bit, you may get a reply from someone else or a delayed follow up from me once I’m back.

One difference I can point out from the API perspective is that you’ll be able to set/modify this over the API whereas you’re not able to do that right now with membership access_level (though it’s coming!) or the default access level. But this could obviously still be disruptive.

Will follow up.

2 Likes

Thanks for documenting this concern @Phil_Seeman! I’m one of the folks who has been working on this change. To clarify, when we remove private_to_team as an option and replace it with private, we will add the team as a member so there will be no change to access (via the API or in the application).

2 Likes

Timeline Update

Previously, we shared that this update would be released to all Asana customers in October. Our revised target for 100% rollout is the end of November.

Beginning of November 2023

  • A gradual rollout begins for privacy_setting on projects in the Asana web app

End of November 2023

  • privacy_setting is fully released to all Asana customers
  • Use Asana-Enable: project_privacy_setting header to opt-in to preview projects without public over the the API

Beginning 2024

  • Temporary restrictions for private teams (mentioned above) will be removed.

March 2024

  • Use an Asana-Disable header to opt-out of projects without public over the the API

June 2024

  • public field is deprecated

Additional Changes

Temporary Restrictions for Private Teams

To prevent a breaking API change, private teams will not be able to have projects with privacy_setting: public_to_workspace. In addition, if a team has a public_to_workspace project, it cannot be changed to a private team until all of its projects are also private or private_to_team. This is to prevent a project from having a null team value because the team is not visible to an API user. As a workaround, users may move a project into a public team.

These restrictions will be lifted once we’ve communicated and implemented the ability to create a project without a team association. More to come on this!

The original post has been updated to reflect these changes and additions! Please let us know if you have questions or concerns.

Hi, I am having some difficulty following this (sorry) but after the recent roles changes that has created absolutely havoc across our small firm (still unraveling) I sort of get the drift (but not really), I would appreciate some guidance to avoid absolute chaos erupting.

  1. We have two people that have private teams and they will want it to stay that way. What should I tell them to do?
  2. If all of our teams are set to public to the organization, what should we do at the Team level? Project Level?
  3. In any teams were to be “by request”, what should we do to keep them that way.

Any guidance appreciated – I am overwhelmed with the amount of time it is taking to manage Asana changes and the impacts.

Hi @Jbir1 ! Thank you for documenting these questions. To clarify, we do not intend to change effective access for existing teams or projects with this change.

The “temporary restrictions” that @John_Baldo references above will apply only to a net-new configuration: we will prevent users from creating a public_to_workspace project in a private team or making a non-private team with public_to_workspace projects private. Let us know if anything remains unclear, of course!

1 Like

Thank you so much for helping me understand :slight_smile:

1 Like