Update permission delegation docs for PermissionDelegationV1_1

- Point amendment disclaimers at PermissionDelegationV1_1 (concept page, account_tx)
- Add account_tx delegate filter parameter (#6126)
- Note pseudo-account delegate rejection in DelegateSet error cases (#7597)
- Document that delegated transactions cannot be queued (#7640)

Author: rachelflynn

docs/concepts/accounts/permission-delegation.md

@@ -10,7 +10,7 @@ status: not_enabled
 
 Permission delegation is the function of granting various permissions to another account to send permissions on behalf of your account. You can use permission delegation to enable flexible security paradigms such as role-based access control, instead of or alongside techniques such as [multi-signing](./multi-signing.md).
 
-{% amendment-disclaimer name="PermissionDelegation" /%}
+{% amendment-disclaimer name="PermissionDelegationV1_1" /%}
 
 
 ## Background: The Need for Permission Delegation
@@ -43,13 +43,12 @@ For a complete list of transaction types that can or cannot be delegated as well
 
 ### Limitations of Permission Delegation
 
-The main limiting factor on how many delegates you can have is that you must hold enough XRP to meet the [reserve requirement](./reserves.md). Each delegate's permissions are tracked with a [Delegate ledger entry][], which counts as one item towards the delegator's owner reserve.
-
-Each delegate can be granted up to 10 permissions.
-
-Some permissions cannot be delegated, especially permissions that would allow the delegate to change cryptographic keys or grant additional permissions.
-
-The available set of granular permissions is hard-coded, and the permissions cannot be customized. For example, you cannot grant permission to send only certain currencies and not others.
+- The number of delegates you can have is limited by the [reserve requirement](./reserves.md). Each delegate's permissions are tracked with a [Delegate ledger entry][], which counts as one item towards the delegator's owner reserve.
+- Each delegate can be granted up to 10 permissions.
+- Some permissions cannot be delegated, especially permissions that would allow the delegate to change cryptographic keys or grant additional permissions.
+- The set of granular permissions is hard-coded and cannot be customized. For example, you cannot grant permission to send only certain currencies and not others.
+- You cannot delegate permissions to a [pseudo-account](/docs/concepts/accounts/pseudo-accounts.md) (such as an AMM or a Single Asset Vault).
+- Delegated transactions cannot be held in the [transaction queue](/docs/concepts/transactions/transaction-queue.md). A delegated transaction that can't apply to the open ledger immediately fails with `telCAN_NOT_QUEUE` instead of being queued.
 
 ## Comparison with Multi-Signing
 

docs/concepts/transactions/transaction-queue.md

@@ -39,6 +39,7 @@ The `xrpld` server uses a variety of heuristics to estimate which transactions a
 - Transactions must be properly-formed and [authorized](index.md#authorizing-transactions) with valid signatures.
 - Transactions with an `AccountTxnID` field cannot be queued.
 - Fee-sponsored transactions (using the `spfSponsorFee` flag) cannot be queued. {% amendment-disclaimer name="Sponsor" /%}
+- [Delegated transactions](../accounts/permission-delegation.md) (those with a `Delegate` field) cannot be queued. {% amendment-disclaimer name="PermissionDelegationV1_1" /%}
 - A single sending address can have at most 10 transactions queued at the same time.
 - To queue a transaction, the sender must have enough XRP for all of the following:
     - Destroying the XRP [transaction cost](transaction-cost.md) as specified in the `Fee` fields of all the sender's queued transactions. The total amount among queued transactions cannot be more than the base account reserve (currently {% $env.PUBLIC_BASE_RESERVE %}). (Transactions paying significantly more than the minimum transaction cost of 0.00001 XRP typically skip the queue and go straight into the open ledger.)

docs/references/http-websocket-apis/public-api-methods/account-methods/account_tx.md

@@ -77,9 +77,19 @@ The request includes the following parameters:
 | `forward`          | Boolean                                    | _(Optional)_ Defaults to `false`. If set to `true`, returns values indexed with the oldest ledger first. Otherwise, the results are indexed with the newest ledger first. (Each page of results may not be internally ordered, but the pages are overall ordered.) |
 | `limit`            | Positive Integer                           | _(Optional)_ Default varies. Limit the number of transactions to retrieve. The server is not required to honor this value. |
 | `marker`           | [Marker][] | Value from a previous paginated response. Resume retrieving data where that response left off. This value is stable even if there is a change in the server's range of available ledgers. |
+| `delegate`         | Object                                     | _(Optional)_ Filter the results by [transaction delegation](../../../../concepts/accounts/permission-delegation.md) relationship. See [`delegate` filter](#delegate-filter) for the object's fields. {% amendment-disclaimer name="PermissionDelegationV1_1" /%} |
 
 - [API v2]: If you specify either `ledger_index` or `ledger_hash`, including `ledger_index_min` and `ledger_index_max` returns an `invalidParams` error.
 
+#### `delegate` filter
+
+The `delegate` object filters results to transactions where one account (the delegatee) signed and submitted a transaction on behalf of another account (the delegator). It has the following fields:
+
+| `Field`           | Type   | Description |
+|:------------------|:-------|:------------|
+| `delegate_filter` | String | _(Required)_ The relationship to filter by. `actor` returns transactions others signed on behalf of the `account` (the account holder's view). `authorizer` returns transactions the `account` signed on behalf of others (the delegatee's view). |
+| `counter_party`   | String | _(Optional)_ An [address][] to filter by. Use with `delegate_filter`:`actor` to limit results to transactions signed by this delegatee. Use with `delegate_filter`:`authorizer` to limit results to transactions signed on behalf of this delegator. |
+
 
 ### Iterating over queried data
 

docs/references/protocol/transactions/types/delegateset.md

@@ -70,7 +70,7 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
 | `tecDIR_FULL`             | The sender owns too many items in the ledger already.<br>This error is effectively impossible to receive if {% amendment-disclaimer name="fixDirectoryLimit" compact=true /%} is enabled. |
 | `tecINSUFFICIENT_RESERVE` | The sender does not have enough XRP to meet the [reserve requirement](/docs/concepts/accounts/reserves.md) of creating a new Delegate ledger entry. |
 | `tecNO_ENTRY`             | The `Permissions` list is empty but no [Delegate ledger entry][] exists for the delegate. An empty list is only valid for deleting an existing entry. |
-| `tecNO_PERMISSION`        | At least one permission in the `Permissions` list is not delegatable. See [Permission Values](../../data-types/permission-values.md) for which permissions are not delegatable. |
+| `tecNO_PERMISSION`        | At least one permission in the `Permissions` list is not delegatable (see [Permission Values](../../data-types/permission-values.md) for which permissions are not delegatable), or the `Authorize` account is a [pseudo-account](/docs/concepts/accounts/pseudo-accounts.md). |
 | `tecNO_TARGET`            | The account specified in the `Authorize` field does not exist in the ledger. |
 | `temARRAY_TOO_LARGE`      | The `Permissions` list is too large. It cannot contain more than 10 entries. |
 | `temDISABLED`             | The [PermissionDelegation amendment][] is not enabled. |