Projects now have admin, editor, and commenter access levels that you can assign to collaborators by project. Individual user project permissions by access level are:
Admins who typically lay the framework for projects.
Editors who can add content to projects, such as adding tasks and messaging. They cannot make changes to the project’s architecture, such as deleting projects or changing a project’s name.
Commenters who have comment access along with limited capabilities.
Project admin and editor access levels are available for all plans, and commenter access level is available in Premium tier or higher.
Enterprise customers gain additional project admin permissions including the ability to restrict editors from modifying a project’s workflow and appearance.
These features are rolling out over the week.
Stay tuned for more project and centralized admin permissions coming soon, including the ability to restrict who can share projects and manage members!
Though, I’m confused by the change of the default configuration.
I have the feeling that before, the default was “Project Admin” and somehow it now has changed to “Editor” being the default for team members, as well as new members that you invite.
As @Arthur_BEGOU mentioned, it seems that with this rollout, all of the Team and Task Collaborators (if not already directly assigned to the project) are now set as Editor. When before they would have been considered “Project admin”.
While this seems ideal in theory, it actually is more restrictive (obviously) for those who previously had abilities (even though they weren’t directly added to the Project). Basically, we had team members that would “Archive” a project when we were done with it, even though they weren’t directly added to the project. But now, because the bulk of our team is now considered “Editor” (since they were never directly added), there are 100s of projects where they no longer have the same abilities as before.
Surely we can’t be expected to manually go into 100s of projects and add a bunch of team members to them, just so they can archive the project?
On a separate (but similar note), when/how is this functionality built into Project Templates? We’d like to have any team and Task Collaborators be a “Project Admin” access level by default, for any new project created from a specific Project Template. I assume it’s at the top-right of the Task Template, where you can choose “Project Members”, but if so, I only see an option for “Members”, and not an option for the Team itself.
Adding the access level “Editor” with limited rights is a great and exciting feature.
BUT, the problem is, this was not an additional functionality, it is changing the existing functionality.
We have project leads, that own a project and they are administrators. Then we have the whole design team as a member, who is able to edit.
Now, in the new set up the team is assigned editor, which prohibits editing the Overview tab. What is the rational behind that?
Every team member needs to be able to edit the Overview. In our case this has general information about the client (contact and services info) and their payment plans. Now this can’t be updated anymore and every tiny change has to be escalated to the project manager.
Echoing FreshyJon: surely we can’t be expected to manually go into 100s of projects and edit permissions. Especially as only the director has the right permission in the first place to do so.
This also means for me as Ops manager, I can’t manage the projects anymore in an operational way. Being part of the Design team, there was no need for me to be a project admin in every project and get all the noise of daily work. All the Ops around a project could be done. Now, I’m cut off, sitting there without hands and arms.
Hello -adding another point of frustration caused by this new feature: I’m a super admin in our Asana instance (and also the program manager, so I oversee the majority of projects keep asana “clean”), and now I can’t edit any of the public projects, as I’m an “editor” by default. Practical use case: someone created inadvertently a project under the wrong team and left, now I can’t move that project because I’m not a project admin there. Thoughts on how to resolve this (except waiting for the only “project admin” to come back and fix it?)
I’m the uber admin, and I can’t move projects??? What is happening?
I created a project, left it and when I added myself back, I cant be admin again, just editor! So nobody is the owner of the project and nobody can be!
This really is an awful change for obvious and already mentioned reasons. We had some annoying (breaking and unannounced) changes before, but this tops it all and is the last straw!
We will be migrating away soon.
This feature needs to be rolled back immediately. We now have the “Editor” role but ever team member in ALL of our projects have been converted to Project Admin. This needs to be fixed in our environment immediately.
Is there an opt out for this update? This is incredibly restrictive as others have mentioned and I am hoping this is an optional change and not forced upon all users.
@John_Baldo@Jeff_Schneider I also want to mention that this breaking change in project permissions also broke Flowsana.
When there is a Flowsana Dynamic Duration workflow built into a project template, and a project is created from that template, Flowsana automatically adds that workflow to the new project. As part of that process, it blanks out the project’s Start and Due dates (sets them to null). But suddenly with this change, that write is failing, because the default access for the new project is editor and it seems Editors aren’t allowed to update the project start/date date. (Also note that it isn’t even documented what that permission is.)
The worst “update” ever.
We cannot change anymore the owner of the project, and we are cut off, since in our organization the projects are created automatically by a “shared user” (via an automation).
I hope that they fix it soon, because this situation is unmanageable…
If your automation is creating projects based on a template, make sure that in the templates’ settings, in step 1, Project Content, in the upper right corner, select the project members and adjust the settings of ‘Members’ to Project admin so anyone who joins the project will default to that setting.
Hi everyone, thanks for taking the time to share your feedback with us. I wanted to clarify some details about this update and how project permissions were migrated:
If you were a member with edit access to the project, you should now have Project Admin rights and should be able to edit the project as usual.
If you were a Project member but didn’t have full access to the team the project was part of, after this rollout you were made Project Editor and have limited access now.
As @Richard_Sather mentioned in the comment above, to gain the level of access you had before, Project Admins can update the default access level of the project to “Project Admin”. This will give anyone the ability to take admin-level actions on the project.
If there aren’t any project admins on a project, there’s an in-product flow that lets any editor become the first project admin. That new admin can designate other users as admins as well.
We are planning to implement the capability to make this update via the Asana API in the near future as well.
I hope this clarifies some of the confusion around how permissions were set after this roll out. We will continue monitoring feedback and sending your suggestions to our Product Team for consideration in the future!
All we have been asking for is a way for project managers/admins ONLY to be able to change due dates, unsure of what this update even was and now the page to editor access “cannot be found”.
I also wanted to mention that with this change, when a team member creates a new project under the wrong team, and that project needs to be moved, an Asana Administrators cannot move these new projects to the proper team. For example, upon joining the new project, even an Administrator is automatically made an Editor, and does not have permissions to be a Project admin, and therefore, cannot move the project.
There is a similar problem with not being able to archive projects to which an Administrator has only Editor access.
Additionally, being stuck with only Editor access for new projects removes an Administrator’s ability to adjust the permissions settings or notification settings for these projects. This makes it impossible for an Administrator to maintain such standards in the organization or division that he/she is responsible for.
I would think that an organizational or divisional Administrator would have control at this level to move any project to another team, archive any project, adjust permissions and notification settings, or at least to manually gain admin access to a given project.
Issues like this were not present under the previous permissions structure. Thank you for considering these factors.
