[null,null,["最后更新时间 (UTC):2025-08-29。"],[],[],null,["# Manage pending access proposals\n\nAn *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\n### List 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\n[`AccessProposal`](/workspace/drive/api/reference/rest/v3/accessproposals/list#accessproposal)\nobject representing a list of unresolved access proposals on the file.\n\nThe `AccessProposal` object includes info about each proposal such as the\nrequester, the recipient, and the message that the requester added. It also\nincludes an\n[`AccessProposalRoleAndView`](/workspace/drive/api/reference/rest/v3/accessproposals/list#accessproposalroleandview)\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 `AccessProposalRoleAndView` object of `role=reader` and\n`view=published`, plus an additional `AccessProposalRoleAndView` object with\nonly the `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\n### Resolve 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\non the [`accessproposals`](/workspace/drive/api/reference/rest/v3/accessproposals) resource and\ninclude the `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`. An additional optional query\nparameter of `send_notification` 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 `AccessProposal` 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) collection 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\n- [Share files, folders, and drives](/workspace/drive/api/guides/manage-sharing)"]]