Collaborating with Other Developers

Apps Script provides some features that help you and other developers to build and maintain scripts, add-ons, and web apps together.

Collaboration basics

In order to collaborate on a project, you and your collaborators must all have editor access to the Apps Script project file (and its container, if it is a bound script). This lets everyone on your team see and make changes to the Apps Script code. Editors can also create new code versions, publish add-ons, and deploy scripts as web apps or as executables for the Execution API.

You can help your team by planning beforehand how you handle the editing, reviewing, versioning, and (if applicable) the deployment and publishing of your project, add-on or web app. Standalone projects are usually the easiest to collaborate on, because they appear directly in Google Drive and are the recommended project type for add-on and web app development.

A common problem in collaboration occurs when a script project owner leaves the team without transferring ownership of the project to someone else on the team. This can leave you unable to maintain or update the project. One way of avoiding this is to create a new account (representing the team) to be the owner of the script project. However, Team Drives provides a cleaner, more natural method of collaborating on Apps Script projects and other types of files.

Collaborating with Team Drives

Team Drives provide a shared space in a Google Drive where teams can more effectively collaborate. Files placed in a Team Drive are owned by the team, rather than individuals. This means that when a team member leaves the team they do not take file ownership and control with them.

Team Drives also allow you to move files across domains — a Team Drive in one domain can have collaborators from another domain who can move files from that domain into the Team Drive. This can be very valuable to Apps Script developers, as it provides a means for a team to develop add-ons, web apps, or other code for customers in different domains.

When you use Team Drives to collaborate on Apps Script projects, keep the following in mind:

  1. Team members with editor access to a Team Drive are able to create or move new files into the Team Drive. As script editors, they can view and edit scripts projects, run script code, create new script versions, publish add-ons, and deploy scripts as web apps or executables for the Execution API.
  2. Team Drives also let you share specific files within the Team Drive to others outside the team, and update their edit and view permissions on those files like any other Drive file. However, if a user is part of the team the Team Drive belongs to, you cannot reduce their access for specific files. For example, if a user has edit access to a Team Drive, you can't change that to view-only access for a specific file within the Team Drive.
  3. Team members with full access to a Team Drive, in addition to the above, are able to delete files and Apps Script projects, and move files out of the Team Drive.
  4. All container-bound scripts use the same viewer and editor access lists defined for the container file. For example, if you have edit access to a Google Sheet you also have edit access to any Apps Script project code attached to it. Placing such a container file into a Team Drive grants the Team Drive's collaborators the same access to the script code as they have for the container itself.
  5. When a script project resides in a Team Drive, access to its Cloud Platform project may be restricted. See the Cloud projects and Team Drives guide section for details. When collaborating on script projects in Team Drives, you may need to switch to a standard Cloud Platform project.
  6. Web apps deployed in one domain cease to function if their ownership changes to a Team Drive or account in a different domain. This can be corrected by moving the script back to its original domain, or having a collaborator redeploy the script project in the new domain.
  7. Similarly, script projects that are deployed as a Execution API executable cease to function when called by the API if moved via Team Drives from one domain to another. This can be corrected by moving the script back to its original domain, or having a collaborator redeploy the script project in the new domain.

Collaborating with project sharing

You can also collaborate on a project by directly sharing the project with all the collaborators. You can directly share script projects that reside in regular Google Drive folders or in Team Drives. If you use this method, it is recommended that you carefully plan who owns and maintains the script over time.

Standalone projects show up in your Google Drive as a file and you can share them like any other file. For more information, see Sharing files and folders.

Container-bound projects are not visible from your Google Drive. To share a container-bound project, you simply share the parent container file. For example, if you have a script bound to a Google Sheet, you can make someone an editor of the script by making them an editor of the Google Sheet. The viewer and editor access settings of container file are inherited by all the projects within that container.

Collaborating and project resources

Resources are entities that are associated with your project but exist independently of its code. This section explains how collaborating on a project affects its resources, in particular: triggers, libraries, and user properties.

Collaborating and triggers

When you collaborate on a project, any installable triggers that you create are not shared with those who have access to your project. If you need to have a consistent trigger setup for all collaborators, you can use the Script service to create triggers programmatically, at run time. For more information, see Managing Triggers Programmatically.

Collaborating and libraries

Libraries included in your project are available to project collaborators. However, if they do not have at least read-level access to an included library they can't use those libraries — the script throws an error in this case. For more information about libraries, see Managing Libraries.

Collaborating and user properties

User properties are unique to the user that created them. This means that the project collaborators can't see or access your user properties and you can't see or access theirs. Use script properties if you want to share project specific properties with the collaborators. For more information, see the Properties guide.

Enviar comentarios sobre…