[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-09 (世界標準時間)。"],[],[],null,["An *access proposal* is a proposal from a requester to an approver to grant a\nrecipient access to a Google Drive item.\n\nAn approver can review and act on all unresolved access proposals across\nDrive files. This means you can speed up the approval process by\nprogrammatically querying for access proposals and then resolving them. It also\nallows proposals to be viewed in aggregate by an approver.\n\nThe Google Drive API provides the\n[`accessproposals`](/workspace/drive/api/reference/rest/v3/accessproposals) resource so you can view\nand resolve pending access proposals. The methods of the `accessproposals`\nresource work on files, folders, the files within a shared drive but *not* on\nthe shared drive.\n\nThe following terms are specific to access proposals:\n\n- **Requester**: The user initiating the access proposal to a Drive item.\n- **Recipient**: The user receiving the additional permissions on a file if the access proposal is granted. Many times the recipient is the same as the requester but not always.\n- **Approver**: The user responsible for approving (or denying) the access proposal. This is typically because they're an owner on the document or they have the ability to share the document.\n\n| **Important:** Access proposals can't be created using the Drive API. Users must request access using the Drive UI. For more information, see [Get permission to open a file or\n| folder](https://support.google.com/docs/answer/6211862).\n\nUse the fields parameter\n\nIf you want to specify the fields to return in the response, you can set the\n`fields` [system\nparameter](https://cloud.google.com/apis/docs/system-parameters#definitions)\nwith any method of the `accessproposals` resource. If you omit the `fields`\nparameter, the server returns a default set of fields specific to the method. To\nreturn different fields, see [Return specific\nfields](/workspace/drive/api/guides/fields-parameter).\n\nGet a pending access proposal\n\nTo get an access proposal, use the [`get`](/workspace/drive/api/reference/rest/v3/accessproposals/get) method on the [`accessproposals`](/workspace/drive/api/reference/rest/v3/accessproposals) resource with the `fileId` and `proposalId`\npath parameters. If you don't know the proposal ID, you can [list pending access\nproposals](#list-access-proposals) using the `list` method.\n\nList pending access proposals\n\nTo list all pending access proposals on a Drive item, call the\n[`list`](/workspace/drive/api/reference/rest/v3/accessproposals/list) method on the\n[`accessproposals`](/workspace/drive/api/reference/rest/v3/accessproposals) resource and include the\n`fileId` path parameter.\n\nOnly approvers on a file can list the pending proposals on a file. An approver\nis a user with the `can_approve_access_proposals` capability on the file. If the\nrequester isn't an approver, an empty list is returned. For more information\nabout `capabilities`, see [Understand file\ncapabilities](/workspace/drive/api/guides/manage-sharing#capabilities).\n\nThe [response body](/workspace/drive/api/reference/rest/v3/accessproposals/list#response-body)\nconsists of an `accessproposals` object representing a list of unresolved access\nproposals on the file.\n\nThe `accessproposals` object includes info about each proposal such as the\nrequester, the recipient, and the message that the requester added. It also\nincludes a [`RoleAndView`](/workspace/drive/api/reference/rest/v3/accessproposals#roleandview)\nobject that groups the requester's proposed `role` with a `view`. Since `role`\nis a repeated field, multiples could exist for each proposal. For example, a\nproposal might have an `RoleAndView` object of `role=reader` and\n`view=published`, plus an additional `RoleAndView` object with only the\n`role=writer` value. For more information, see\n[Views](/workspace/drive/api/guides/ref-roles#views).\n\nPass the following query parameters to customize pagination of, or filter,\naccess proposals:\n\n- `pageToken`: A page token, received from a previous list call. Provide this\n token to retrieve the subsequent page.\n\n- `pageSize`: The maximum number of access proposals to return per page.\n\nResolve pending access proposals\n\nTo resolve all pending access proposals on a Drive\nitem, call the [`resolve`](/workspace/drive/api/reference/rest/v3/accessproposals/resolve) method on\nthe [`accessproposals`](/workspace/drive/api/reference/rest/v3/accessproposals) resource and include\nthe `fileId` and `proposalId` path parameters.\n\nThe `resolve` method includes an `action` query parameter that denotes the\naction to take on the proposal. The\n[`Action`](/workspace/drive/api/reference/rest/v3/accessproposals/resolve#action) object tracks the\nstate change of the proposal so we know if it's being accepted or denied.\n\nThe `resolve` method also includes the optional query parameters of `role` and\n`view`. The only supported roles are `writer`, `commenter`, and `reader`. If the\nrole isn't specified, it defaults to `reader`. For more information, see [Roles\nand permissions](/workspace/drive/api/guides/ref-roles). An additional optional query\nparameter of `sendNotification` lets you send an email notification to the\nrequester when the proposal is accepted or denied.\n\nJust as with the `list` method, users resolving the proposal must have the\n`can_approve_access_proposals` capability on the file. For more information\nabout `capabilities`, see [Understand file\ncapabilities](/workspace/drive/api/guides/manage-sharing#capabilities).\n\nProposals are resolved using the same patterns listed under [Scenarios for\nsharing Drive\nresources](/workspace/drive/api/guides/manage-sharing#sharing-drive-resources). If there are\nmultiple proposals for the same user, but with different roles, the following\napplies:\n\n- If one proposal is accepted and one is denied, the accepted role applies to the Drive item.\n- If both proposals are accepted at the same time, the proposal with the higher permission (for example, `role=writer` versus `role=reader`) is applied. The other access proposal is removed from the item.\n\nAfter sending a proposal to the `resolve` method, the sharing action is\ncomplete. The resolved access proposal is no longer returned through the `list`\nmethod. Once the proposal is accepted, the user must use the [`permissions`](/workspace/drive/api/reference/rest/v3/permissions) resource to update permissions on a file or\nfolder. For more information, see [Update\npermissions](/workspace/drive/api/guides/manage-sharing#update-permissions).\n\nRelated topics\n\n- [Share files, folders, and drives](/workspace/drive/api/guides/manage-sharing)"]]