The enum values on MetaobjectAccess - GraphQL Admin do not translate to values in MetaobjectAccessInput - GraphQL Admin
MERCHANT_READ,MERCHANT_READ_WRITE,PRIVATE,PUBLIC_READ,PUBLIC_READ_WRITE on query vs just MERCHANT_READ,MERCHANT_READ_WRITE available in MetaobjectAdminAccessInput - GraphQL Admin
This also raises a question on how to set a metaobject to PUBLIC_READ_WRITE?
Or is it not possible?
Hey @Taksh_Shah - good question! The access model splits permissions into separate dimensions, and the extra enum values on the query side represent read-only states.
The MetaobjectAccessInput takes admin and storefront as separate fields. The admin field uses MetaobjectAdminAccessInput which only has MERCHANT_READ and MERCHANT_READ_WRITE because those control what the merchant can do on app-owned definitions. The owning app always has full access regardless. The values you see on the query side like PRIVATE, PUBLIC_READ, and PUBLIC_READ_WRITE describe the access state from the perspective of other apps and the merchant, but aren’t settable through the mutation.
If you’re looking for full read/write access for the merchant and all apps, use a merchant-owned metaobject definition (no $app: prefix on the type). Merchant-owned definitions are always effectively PUBLIC_READ_WRITE on the admin side with no configuration needed. For storefront access, set storefront: PUBLIC_READ on the input. There’s no PUBLIC_READ_WRITE for storefront as it’s read-only by design. The About metaobjects permissions section covers the full breakdown of both ownership models.
Let me know if you’re working with app-owned or merchant-owned definitions and I can get more specific, cheers!
That is the confirmation I was looking for, I just wanted to import metaobjects through app without them being locked to the app or merchant. This confirms that behaviour, thank you!
1 Like