-
-
Notifications
You must be signed in to change notification settings - Fork 729
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
Add "Affiliate Sales Data" connected app option #12676
Add "Affiliate Sales Data" connected app option #12676
Conversation
5a4de04
to
c5c2f8f
Compare
To make way for a new type of connected app. If only we could use [relative partial paths](rails/rails#1143)
Then subtypes can override as needed.
Best viewed with whitespac ignored.
Because there's going to be a new section with the same button label
Using namespace subfolder to help organise it and show the inheritance. Hmm, instead of scopes, we could have different has_many relationships on the Enterprise. Maybe it should be in a concern. We can refactor later I guess.
37afae9
to
a6d70d9
Compare
Example usage: rake ofn:enterprises:activate_connected_app_type[affiliate_sales_data]
a6d70d9
to
df81e8e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, easy to follow !
def connect(api_key:, channel:) | ||
ConnectAppJob.perform_later(self, api_key, channel:) | ||
end | ||
|
||
def disconnect | ||
WebhookDeliveryJob.perform_later( | ||
data["destroy"], | ||
"disconnect-app", | ||
nil | ||
) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't that be better in a service ?
It made more sense now that I have seen the rest of the commits. I am still not a fan but right now I can't really think of another solution without bringing more complexity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it feels wrong sending the websocket channel to the model. But with a service, I guess the controller has to know about the subtypes, and make the decision what to do with them, which doesn't seem any better.
I'm curious what Maikel thinks too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean you could have a service that knows how to connect/disconnect each type of connected app, but that would add some indirection.
It could make sense if the connect/disconnect was a setting not stored with the model.
desc "Activate connected app type for ALL enterprises" | ||
task :activate_connected_app_type, [:type] => :environment do |_task, args| | ||
Enterprise.find_each do |enterprise| | ||
next if enterprise.connected_apps.public_send(args.type.underscore).exists? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering if we should whitelist the type param here ? Probably not necessary as it will blow up if you are trying to use a scope that doesn't exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I figured for a rake task that requires system access to execute, we don't need to add much protection.
Maybe I should have hardcoded the type (there's only one type after all!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! Nice pull request. I had one suggestion but it's not important enough to delay this pull request. Let's go ahead.
@@ -20,7 +20,7 @@ def perform(app, token, channel: nil) | |||
selector = "#connected-app-discover-regen.enterprise_#{enterprise.id}" | |||
html = ApplicationController.render( | |||
partial: "admin/enterprises/form/connected_apps/discover_regen", | |||
locals: { enterprise:, connected_app: enterprise.connected_apps.first}, | |||
locals: { enterprise:, connected_app: enterprise.connected_apps.discover_regen.first }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that the more generic alternative would be ConnectedApp.of(enterprise).first
. We'll see with more usage what will be better.
def connect(_opts) | ||
update! data: true # not-nil value indicates it is ready | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we set this value in the constructor so that we don't have to update the record again? Doesn't really matter though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good thinking
Funded feature code is #12543 [DFC] Anonymized orders endpoint
What? Why?
Creates a second type of connected app, called "Affiliate Sales Data" in the backend (named after the work-in-progress
affiliate_sales_data
endpoint), and translated for specific use case.I'm not 100% sure about the naming and how the scopes are set up. And it looks like the Discover Regen connected app should have its own subtype. But I didn't think it was worth trying to guess on my own how this might be expanded in the future, so just did the minimum necessary.
What should we test?
connected_apps
is enabledThis option doesn't have any effect until #12544 is completed.
Rake task
This can tested by logging into the staging server and running something like:
Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.
Dependencies
Not dependent on, but related to: