[spaceship] Add get app availabilities v2 request

[lucgrabowski]

Checklist

• I've run bundle exec rspec from the root directory to see all new and existing tests pass
• I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
• I see several green ci/circleci builds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)
• I've read the Contribution Guidelines
• I've updated the documentation if necessary.
• I've added or updated relevant unit tests.

Motivation and Context

As written in #21890, there is a need to implement a new request for app availabilities. It will allow for checking if app is available or removed from distribution.
PR should be considered after #21900 is handled.

Description

In this PR a request for app availabilities (https://developer.apple.com/documentation/appstoreconnectapi/read_app_availablity_territories) is implemented. It's a first request to v2 version in path.
Request is used in Pricing and Availability on AppStoreConnect.

Testing Steps

I added unit tests for models.
I also tested the request in spaceship playground.

[shernade]

question: how are you going to know which territory corresponds to a territoryAvailability?

[lucgrabowski]

@shernade I took a look at the fixtures and I think that when you fetch appAvailabilities you can get territoryAvailabilities and as far as I remember ids are meaningful for them. If you want to know exactly how it works, you could login to AppstoreConnect in web browser with developer tools open and check network requests on "Pricing and Availability".

[shernade]

i see that doing a call like this:
client.tunes_request_client.get("v2/appAvailabilities/6497953632/territoryAvailabilities", client.tunes_request_client.build_params(filter: {}, includes: "territory", limit: 200 , sort: nil)) including territory the json data has territory info:

 =>
#<Spaceship::ConnectAPI::Response:0x00007f9abe72a2f8
 @body=
  {"data"=>
    [{"type"=>"territoryAvailabilities",
      "id"=>"eyJzIjoiNjQ5Nzk1MzYzMiIsInQiOiJEWkEifQ",
      "attributes"=>{"available"=>false, "availableInPast"=>false, "preOrderAvailableInPast"=>false, "releaseDate"=>nil, "preOrderEnabled"=>false, "preOrderPublishDate"=>nil, "contentStatuses"=>["CANNOT_SELL"]},
      "relationships"=>{"territory"=>{"data"=>{"type"=>"territories", "id"=>"DZA"}}},
      "links"=>{"self"=>"https://appstoreconnect.apple.com/iris/v1/territoryAvailabilities/eyJzIjoiNjQ5Nzk1MzYzMiIsInQiOiJEWkEifQ"}},
     {"type"=>"territoryAvailabilities",
      "id"=>"eyJzIjoiNjQ5Nzk1MzYzMiIsInQiOiJWRU4ifQ",
      "attributes"=>{"available"=>false, "availableInPast"=>false, "preOrderAvailableInPast"=>false, "releaseDate"=>nil, "preOrderEnabled"=>false, "preOrderPublishDate"=>nil, "contentStatuses"=>["CANNOT_SELL"]},
      "relationships"=>{"territory"=>{"data"=>{"type"=>"territories", "id"=>"VEN"}}},
      "links"=>{"self"=>"https://appstoreconnect.apple.com/iris/v1/territoryAvailabilities/eyJzIjoiNjQ5Nzk1MzYzMiIsInQiOiJWRU4ifQ"}},
     {"type"=>"territoryAvailabilities",

that model data seems a bit complicated to me,
thanks

[max-ott]

@lucgrabowski Let's get #21900 through the door first. I hope tests are passing now. Then there should be less changes here, and hopefully less warnings.

Could you provide me/us with some basic steps to test/reproduce this with the Spaceship playground? More than happy to review that so we can get this PR here over the finish lines as well! Thanks for your work in the meantime :)

[jakub-przy]

#21900
Has been merged 🥇

[lucgrabowski]

@max-ott Thanks for reviewing and merging other PRs. I don’t have an access to computer this weekend, but I have tried merging master through web interface, I hope it will be fine.

About testing steps in Spaceship playground. I logged in to developer account, fetched ConnectAPI::App and called get_app_availabitilites for this app. It’s also good to later check territory_availabilities for app availability. I used it in #21902

Also, using a network proxy may be useful and running playground with SPACESHIP_DEBUG=1 enabled, https://github.com/fastlane/fastlane/blob/master/spaceship/docs/Debugging.md)

[jakub-przy]

I have created my own fork with all the latest commits from master and then also applied the changes introduced in this PR - when running a test App Store deployment workflow - i'm still getting pretty much the same error:

> ************************/vendor/bundle/ruby/2.7.0/bundler/gems/fastlane_fork-e8fe2a941102/spaceship/lib/spaceship/connect_api/api_client.rb:223:in `handle_response': \e[31m[!] The provided entity includes an unknown attribute - 'availableInNewTerritories' is not an attribute on the resource 'apps' - /data/attributes/availableInNewTerritories (Spaceship::UnexpectedResponse)
> The provided entity includes an unknown relationship - 'prices' is not a relationship on the resource 'apps' - /data/relationships/prices
> The provided entity includes an unknown relationship - 'availableTerritories' is not a relationship on the resource 'apps' - /data/relationships/availableTerritories\e[0m

I just thought you'd like to know

[max-ott]

I think the problem is that you can only retrieve (get) the availabilities if they are already set. If they are empty, e.g. for a new app, there will be an error. I'm not 100% sure how other spaceship methods handle this. Ideally we would be able to get but also set / update the availabilities.

My test:

// login first
app = Spaceship::ConnectAPI::App.get(app_id: "123456789")
app.get_app_availabilities

Results

.../fastlane-2f8d1a77ff58/spaceship/lib/spaceship/connect_api/api_client.rb:223:in `handle_response': The specified resource does not exist - There is no resource of type 'appAvailabilities' with id '123456789' (Spaceship::UnexpectedResponse)
	from .../fastlane-2f8d1a77ff58/spaceship/lib/spaceship/connect_api/api_client.rb:114:in `get'
	from .../fastlane-2f8d1a77ff58/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:425:in `get_app_availabilities'
	from .../forwardable.rb:240:in `get_app_availabilities'
	from .../fastlane-2f8d1a77ff58/spaceship/lib/spaceship/connect_api/models/app.rb:157:in `get_app_availabilities'
	from (irb):7:in `<main>'
...
	```

It works just fine for apps that already have set availabilities.

[jakub-przy]

@max-ott
You were absolutely right - it works! I guess we're gonna have to set those capabilities manually until a proper fix is in place. Still, this is great, cheers!