Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OAuth BigQuery Connections #16191

Conversation

jgoizueta
Copy link
Contributor

@shortcut-integration
Copy link

This pull request has been linked to Clubhouse Story #136326: Implement OAuth connection for BigQuery.

@jgoizueta jgoizueta force-pushed the feature/ch136326/implement-oauth-connection-for-bigquery branch from 73b231a to 56613ad Compare March 4, 2021 13:30
…ent-with-tileset-list

Fix invalid query for listing no tilesets
…y' of github.com:CartoDB/cartodb into feature/ch136326/implement-oauth-connection-for-bigquery
For some reason (some middleware?) responses
with status 401 are altered to content-type jaon with empty body
@rafatower
Copy link
Contributor

@jgoizueta do you mind updating your branch with master? chances are it fixes some things related to broker behavior and it helps me test without kidnapping staging :)

Copy link
Contributor

@simon-contreras-deel simon-contreras-deel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see it fine, just a detail

@@ -35,6 +36,21 @@ def errors
errors << 'Parameter access_token not supported through connections; use import API'
end
end
if @connection.connection_type == Carto::Connection::TYPE_OAUTH_SERVICE
unless incomplete? || @connection.parameters['billing_project'].present?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should check if incomplete? right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's an unless incomplete? because we don't wan't to validate the presence of the billing project if the connection is incomplete: and incomplete connection must be saved without errors in an incomplete state when the refresh token is saved in it by the oauth callback.
🤔 I guess that unless ... || ... doesn't help to understand this at first sight, maybe it should be rewritten as

if complete? && @connection.parameters['billing_project'].blank?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh oki doki. I think that no change is needed, I was my fault understanding the case

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'd rather use the straight if rather than the negative logic version, turns out more readable and less prone to misinterpretation... unless you don't agree with me)
(No puedo negar que no esté en desacuerdo contigo -- Groucho)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😂

Copy link
Contributor

@simon-contreras-deel simon-contreras-deel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

…n-for-bigquery

# Conflicts:
#	NEWS.md
#	spec/models/carto/connection_spec.rb
complete? validates, so checks for error, so it shouldn't be used in errors!
To make evident the former incomplete? method is not the negation of compliete?
Otherwise they won't appear in the Dashboard and the user won't be able to delete them.
@jgoizueta
Copy link
Contributor Author

This has been merged into master through #16218

@jgoizueta jgoizueta closed this Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants