Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developers.google.com/apps-script/guides/collaborating below:

Collaborate with other developers | Apps Script

Stay organized with collections Save and categorize content based on your preferences.

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

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 Apps Script 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. Placing your script project in a shared drive prevents this problem, since files in a shared drive don't have specific owners.

clasp lets you sync projects between script.google.com and your local file system. This lets you streamline and automate your code development if you and your collaborators are using source control management software such as git.

For more details, refer to Command Line Interface using clasp guide.

Shared drives (formerly known as "Team Drives") provide a shared space in a Google Drive where groups of Drive users can more effectively collaborate. Files placed in a shared drive are owned by the group as a whole, rather than individuals. This means that when a collaborator leaves the group they do not take file ownership and control with them.

Shared drives also let you move files across domains — a shared drive in one domain can have collaborators from another domain who can move files from that domain into the shared 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 shared drives to collaborate on Apps Script projects, keep the following in mind:

1. Collaborators with editor access to a shared drive are able to create or move new files into the shared drive. As script editors, they can view and edit scripts projects, run script code, create new script versions, publish add-ons.
2. To deploy scripts as web apps or executables for the Apps Script API, the account that creates the deployment must belong to the same domain as the shared drive that the script resides in.
3. Shared drives let you share specific files within the shared drive to others outside the group, 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 shared drive belongs to, you cannot reduce their access for specific files. For example, if a user has edit access to a shared drive, you can't change that to view-only access for a specific file within the shared drive.
4. Collaborators with full access to a shared drive can also delete files and Apps Script projects, and move files out of the shared drive.
5. 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 shared drive grants the shared drive's collaborators the same access to the script code as they have for the container itself.
6. When a script project resides in a shared drive, access to its Cloud Platform (GCP) project may be restricted. See the GCP projects and shared drives guide section for details.
7. Web apps deployed in one domain cease to function if their ownership changes to a shared drive or account in a different domain. This can be corrected by moving the script back to its original domain.
8. Similarly, script projects that are deployed as an Apps Script API executable cease to function when called by the API if moved via shared drive from one domain to another. This can be corrected by moving the script back to its original domain.

If you can't collaborate with a shared drive, you can use a shared folder, instead. When you create or move an Apps Script project to a Google Drive folder that other people can access, they inherit the same access to the Apps Script project that they have for the folder. For example:

• If someone has edit access to the folder, they can edit or delete the Apps Script project and run the script.
• If someone only has view access to the folder, they can view the Apps Script project and run the script.

You can 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 shared 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, share the parent container file. For example, if you have a script bound to a Google Sheets spreadsheet, you can make someone an editor of the script by making them an editor of the spreadsheet. Container-bound projects inherit the viewer and editor access settings of their container file.

All container-bound scripts use the same owner, viewer and editor access list defined for the container file. The container owner takes ownership of a new script project regardless of who created it.

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: its Cloud Platform project, triggers, libraries, and user properties.

Every Apps Script project has an associated Google Cloud project. Google Cloud projects have their own set of owners, editors, and other roles, which can be different from the set of users that can access the script project.

If your script project is meant to be published as an add-on, it must use a standard Google Cloud project. When you collaborate on an application that uses a standard Google Cloud project, we recommend that you configure the Google Cloud owners and roles to ensure all your collaborators have the proper levels of access. This helps prevent situations where you lose access to the project's Cloud settings because its owners are no longer with your organization. This is especially important for add-ons.

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.

Libraries included in your project are available to project collaborators. However, if they don't 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.

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.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-04 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-04 UTC."],[[["Apps Script enables collaborative development by allowing multiple users with editor access to work on the same project."],["Utilizing Shared Drives in Google Workspace is highly recommended for collaborative Apps Script projects, as it offers centralized ownership and avoids access disruptions if an individual leaves the team."],["The `clasp` command-line tool facilitates collaboration by enabling seamless synchronization of projects between the Apps Script online editor and local file systems for integration with version control systems."],["While Shared Folders can be used, caution is advised, as access permissions to the folder directly translate to permissions on the script project within it."],["Consider how shared resources like triggers, libraries, user properties and Google Cloud Project settings are impacted when collaborating and establish clear guidelines for managing them within your team."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4