Set default OAuth scope to READ

[andregasser]

I have set the default Oauth scope to "read" where it was used. It would be nice, if we could test this somehow. Any ideas?

[codecov[bot]]

Codecov Report

Merging #119 (ec0993d) into master (95aad6b) will increase coverage by 0.05%. The diff coverage is 62.50%.

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #119      +/-   ##
============================================
+ Coverage     44.97%   45.02%   +0.05%     
  Complexity      174      174              
============================================
  Files            67       67              
  Lines          1452     1457       +5     
  Branches         83       83              
============================================
+ Hits            653      656       +3     
- Misses          777      779       +2     
  Partials         22       22              

Impacted Files	Coverage Δ
.../src/main/kotlin/social/bigbone/rx/RxAppMethods.kt	0.00% <0.00%> (ø)
...ain/kotlin/social/bigbone/api/method/AppMethods.kt	82.35% <0.00%> (ø)
...n/kotlin/social/bigbone/api/method/OAuthMethods.kt	96.15% <83.33%> (-3.85%)	:arrow_down:

[bocops]

I'm not sure we really can unit test this. We can't even check (outside of tests) whether the matching scope is granted before performing a request, because scopes are not returned by any of the OAuth endpoints. We could store whatever scope value our client is built with and then use that before attempting any requests - but then we would need to duplicate the whole logic of what individual scope is sufficient for what operation. That's probably not worth it?

This might be worth an integration test, though, after #100 is done: Set up two clients with different scopes, then perform the same operation with both and expect one to fail and one to go through.

[bocops]

Regarding the actual change - Mastodon documentation reads as if Scope.READ is implied if no scope is defined in the request. If that's the case, we could alternatively not define any specific default values ourselves, and in fact make the parameter nullable (with a null default?). Not sure if that would be better than what we currently do, just mentioning the option. :)

[andregasser]

Yes, making the parameter nullable with a default value makes sense to me :-)

[bocops]

@andregasser are you still going to merge this? If so, I will wait before attempting #143 (which should go in before 2.0.0). If not, I can do this in combination with #143.

[andregasser]

@bocops What do you mean exactly? I am not working on this atm 😊 Feel free to continue with your work. 👍🏻

[bocops]

#116 is currently assigned to you, and this draft PR is linked to it. If you unassign youself from 116, I can do it in combination with some other issues.

[andregasser]

Hello @bocops Ah, got it. Sure, I have reassigned #116 to you. Thank you 👍