My app currently works with the products REST api endpoint. In the response, for each product variant there is a “grams” field with the weight of that product variant.
I’m migrating my app to use the new GraphQL products API and I noticed there is no more grams field (or weight field as of 2024-07 version). Instead, I now need to query for the inventoryItem → measurement → weight under the product variant to get that information. This is listed here under changes of 2024-07 version - Product Variant Field Cleanup — Shopify developer changelog
I had no need for inventory item information until now so my app doesn’t require that scope and when I try to get it now using the new API I get the following error “Access denied for inventoryItem field. Required access: read_inventory access scope.”
How do I go about fixing this ? I can add the scope going forward but I have many previous installs that don’t have it
Or am I missing anything and I can get the weight information in a different way
If you update your scopes to include read_inventory access scope with OAuth (or use your app’s toml file if you have a Shopify managed installation) Shopify will prompt the store owners to grant access for this new scope.
We are listed on the Shopify App Store.
As far as I know I would need to update the scope to include read_inventory and send the users again to “/admin/oauth/authorize” with the new scope for them grant it. Only then I can request the inventoryItem.
Are you referring to something else ? is there another way ?
By moving the weight under inventoryItem and requiring a new scope Shopify is “breaking” the behavior and I was hoping for a simpler solution than sending each user to the authorize url again.
I was hoping Shopify would supply a solution for backwards compatibility on requiring new scopes when migrating to GraphQL like they did with write_publications on publishablePublish GraphQL mutation using this form Shopify Publishing Permissions Request
Can you please better explain what you suggested or say if Shopify did supply a solution like I mentioned
+1 for a way to automatically backfill access scopes due to breaking changes like this where fields are moved to a different resource that requires a separate access scope.
As we do these migrations from REST and also as the GraphQL schema changes, it’s really not ideal to keep notifying merchants to make sure to open the app to approve the new scopes so their background jobs don’t fail (and some of them may miss the email). Would be great if there’s a way to handle this without requiring the merchants to take any action.
Totally understand this is not an ideal approach and has risks in terms of ensuring merchants read emails. I’ve connected with the product team in this area to see what they’re recommendation is and how we could improve this.
We are exactly in the same boat, we had no need of read_inventory scope previously and I just found out that we need read_invntory scope, we have over 1.2k merchants for whom things will likely fail
@Asaf_Gitai For read_locations, any plans to at least provide a form to request backfilling the scope (similar to how read_publications was handled) for those migrating from REST?
The use case is for retrieving inventory levels by location. The REST API only requires read_inventory to retrieve InventoryLevels with the location_id in the response: InventoryLevel - REST
I would expect that any app using the InventoryLevel query would probably want the location information also, but for GraphQL this requires a separate access scope.
@Asaf_Gitai thanks for adding this, but without read_inventory and read_location, it’s not really useful for my usecase (export inventory levels by location), like @Jonathan-HA said.
No response yet, they’re probably very busy right now.
I really do hope they consider a backfill option or even better is to allow either read_locations or read_inventory to access the Location resource (just like how InventoryItem can now be accessed with either read_products or read_inventory).
I received the reply, and confirmed the breaking change. Can you please also send email to support asking them to do something? To me this is unacceptable. I already replied and asking them to automatically apply this scope if inventory scope is in.
Updated the api version and a private app stopped working cause all of a sudden I needed the read location scope which I didnt need in the previous api verison. Quite frustrating, I don’t recall seeing this in the breaking changes.
They don’t mention this breaking change at all - because they don’t use the apis themselves. I remember I saw it on shopify that they claimed it is a one to one mapping, it is not! So far I have realized that
read_locations is a new scope that I need to add to my app
unable to get fulfillment_service and inventory_management by productvariant id
Now sure what else.
Deadline is Feb 1 and they still have not provided a answer to my question 2.
