Hey guys,
We submitted the form to backfill the read_publications scope on Oct 23 (Wednesday) and the process is supposed to take place every Friday according to this AMA: https://community.shopify.com/c/community-amas-ask-me-anything/shopify-community-ama-with-shopify-developers-the-new-graphql/m-p/2817779/highlight/true#M1463
However, I checked today and not seeing this access scope for tokens of merchants who haven’t opened out app since we added this scope.
I’m curious if anyone else who submitted the request before Friday got their token scopes updated?
Hey @Jonathan-HA - we ran into an unrelated issue last Friday that prevented us from running this job. We ran it today for read_product requests, but haven’t yet for any write_products. We hope from here to make our Friday timelines. Thanks!
1 Like
Thanks so much for the update Tim!
I just checked a bunch of them and I do see the read_publications scope has been added now. 
By any chance, is there a similar form submission for “read_locations”?
Basically the same reason where we have users who rarely open our apps as they use them mainly for backend automation.
This is related to this change in the 2024-10 version of the REST API where read_locations is now a separate required scope: 2024-10 release notes
Thank you!
Hi @Jonathan-HA shared your message with the relevant team
1 Like
Hey Asaf,
Just wondering if there’s any update on whether we can submit a request to also backfill the read_locations access scope?
Thanks!
Hi @Jonathan-HA ,
Sorry for the delayed response.
Could you provide more details regarding your specific use cases in REST that requires the Location scope in GraphQL.
Hey Asaf,
No worries at all!
So one use case is with our data export app where we still use REST for most endpoints and many of our users have automated scheduled exports.
In the REST Order API, the fulfillments field only provides the location_id and not the location_name. But our customers need to be able to export the location name and not just the ID.
So what our app does in this case is make a call to the Locations endpoint to grab a list of all current locations in the store and do a lookup against the location_id to return the current location_name.
Another REST endpoint that doesn’t return the location name is InventoryLevel.
I understand REST is already considered legacy and we’re migrating to GraphQL slowly and very carefully. We’re prioritizing the Products and Variants endpoints of course because of the Feb 1 deadline. But since many of the REST endpoints are still supported, it would be good to have that backfill option for read_locations (or even better is if that scope requirement change on 2024-10 REST could be reverted).
Thank you!
Ok so sounds like this is not blocking the migration just forward thinking.
one thing that isnt clear to me, where do you get the location name today in REST without a location scope?
Hey Asaf,
So that’s actually the problem, starting from 2024-10 REST, the read_locations scope became required in order to retrieve the Location info. It wasn’t required before, so we didn’t request it:
So the issue is similar to the read_publications where we have users that need to export the location name but haven’t opened the app since we added the read_locations scope in the oauth flow (as they just have scheduled jobs that run in the background). So for those users, the API requests will break once we upgrade to the 2024-10 REST and later.
We could of course send them emails before we upgrade the API version to simply open the app. But still not ideal as some merchants may miss the emails, so it would be better if their access tokens are just automatically backfilled without them having to take any action.
Let me know in case you need any additional info!
Hi @Jonathan-HA ,
Thanks for the detailed info.
WRT to the products and variants migration to graphQL, i would suggest you continue using location pre 2024-07.
The team that has added the permission to 2024-10 has been informed and they will follow up on how they will facilitate this breaking change.
That said, If you havent already, I would suggest adding the scope to new installed as soon as possible
Thanks for doing that Asaf. We’ve already added the read_locations scope to the oauth flow a while back when we saw the changelog.
Will wait for the follow up from the other team, thanks again!
