feat: /users/:address/permissions endpoint returning all lands permissions of a given user#440
feat: /users/:address/permissions endpoint returning all lands permissions of a given user#440
Conversation
…cludesAll query-param is provided
aleortega
force-pushed
the
feat/all-lands-permissions-from-users
branch
3 times, most recently
from
2987f9b to
cd8194e
Compare
aleortega
force-pushed
the
feat/all-lands-permissions-from-users
branch
from
cd8194e to
ffe6dad
Compare
aleortega
changed the title
| query GetAllUserPermissions($address: String!) { | ||
| # 1. Direct parcel and estate ownership | ||
| user: wallet(id: $address) { | ||
| parcels { |
There was a problem hiding this comment.
Just to have this into mind, users with more than the maximum amount of retrievable entries might have less results returned.
| } | ||
|
|
||
| # 4. Address-level UpdateManager permissions | ||
| updateManagerAuthorizations: authorizations( |
There was a problem hiding this comment.
The authorizations graph has a history of the authorizations given to the user. It records each authorization action, either to give the authorization or to remove it. In order to know which parcels or estates are authorized, we need to go through the authorization's list and compute it. Would you mind changing that?
| first: 1000 | ||
| ) { | ||
| owner { | ||
| parcels { |
There was a problem hiding this comment.
Parcels and estates returned here are parcels and estates the user owns. These come from the Wallet entity which is linked to the Parcel and Estate entities via the owner property.
What we would like to return from this query is the complete list of authorizations to compute both the updateManager and approvedForAll authorizations. Would you mind changing that?
|
|
||
| # 3. Estate-level UpdateOperator permissions | ||
| updateOperatorEstates: estates( | ||
| where: { updateOperator: $address } |
There was a problem hiding this comment.
There's the updateOperator and the operator for estates, we should retrieve all estates that match any of these properties, would you mind changing the query to match that?
| } | ||
|
|
||
| # 3. Estate-level UpdateOperator permissions | ||
| updateOperatorEstates: estates( |
There was a problem hiding this comment.
We can create queries to get the parcels for uses that own, are update operators or operators of the asset:
query ($address: String) {
parcels(first: 100, where: { or: [{ owner: $address }, { updateOperator:$address }, { operator: $address }] }) {
x
y
owner {
id
}
updateOperator
operator
}
}
The same can be done for parcels belonging to estates.
| x: acc.x, | ||
| y: acc.y, | ||
| permissions: Array.from(acc.permissions).sort(), // Sort for consistent ordering | ||
| estate: acc.estate |
There was a problem hiding this comment.
If I'm not wrong, parcels from the same estate will have the estate object replicated, which has the id and the size of the estate. Should we only return its id to avoid replicating the size?
| id | ||
| size | ||
| owner { id } | ||
| parcels { |
There was a problem hiding this comment.
As this is a derived parameter, I'm not sure if it's going to return are parcels that belong to this estate. Do we know if that's possible?
3 participants
Introduced a comprehensive permissions endpoint
/users/:address/permissionsthat returns all five permission types (owner, estateOwner, updateOperator, estateUpdateOperator, updateManager) for a given user. This consolidates ownership and operator data into a single response, with each parcel showing all applicable permission types and optional estate information.Deprecated:
/users/:address/lands-permissionsnow returns a Deprecation header and only provides the legacy updateOperator permissions format.