-
Notifications
You must be signed in to change notification settings - Fork 16
saas request overrides #986
saas request overrides #986
Conversation
…e and test case. minor refactor of some of the saas request execution to enable smoother override
611f1a6
to
bc0f741
Compare
…gration tests caused by rebase
src/fidesops/service/saas_request/saas_request_override_factory.py
Outdated
Show resolved
Hide resolved
|
||
@classmethod | ||
def register( | ||
cls, name: str, request_types: List[SaaSRequestType] |
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.
Is request_types
a list for flexibility? I can't think of a use-case for this right now but it's better to have this just in case right?
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.
yup. the use case i could imagine was potentially around update/delete? probably wouldn't make sense at this point, but just thought i'd keep things flexible.
src/fidesops/service/saas_request/saas_request_override_factory.py
Outdated
Show resolved
Hide resolved
tests/ops/integration_tests/saas/request_override/test_mailchimp_override_task.py
Show resolved
Hide resolved
"mailchimp_member_update", [SaaSRequestType.UPDATE] | ||
) | ||
def mailchimp_member_update( | ||
update_param_values: List[Dict[str, Any]], |
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.
The name update_param_values
is a bit confusing since we have the concept of param_values
. At first glance the for update_params in update_param_values
part makes me think that we're iterating through each param_value. I think we need something that better describes this input as a list of param_values per row to update. Maybe param_values_list, or something along those lines?
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.
hmm, i agree the current name is confusing. i'm not sure param_values_list
clears things up that much though. maybe just being very explicit and param_values_per_row
?
raise InvalidSaaSRequestOverrideException( | ||
"Provided SaaS request override function must return a List[Row]" | ||
) | ||
if len(sig.parameters) < 6: |
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.
What are your thoughts around validating the kwarg names and types? I imagine the signature should be consistent since we're calling the function with fixed inputs. What is some of the flexibility you're referring to in the comment?
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 thought back and forth on this a bit, and am definitely not convinced on what is the best approach.
i guess i just don't really see the benefit of preventing an implementer from naming or type-annotating the args however they want in their implementation. whatever we do here in this validation, it's not going to really give them the IDE/static support to automatically generate their methods, or to inform them of what the arguments are, etc. - to get that understanding, they're going to need to refer to examples and/or documentation. so at that point, if they want to for whatever reason adjust the argument names from the example that they're referring to, or e.g. provide a more generic type annotation, i don't really see why we (the framework) should care at runtime.
i guess what i mean is, with the way things are set up now, you still really have to know what you're doing in order to be able to implement an override here. so it just seems unlikely that they'd end up in a scenario where having their function fail to register because of arg names or type annotations would really help them debug a problem. but maybe i'm not thinking creatively enough.
perhaps extending that argument further would suggest we shouldn't do any sort of validation. i thought these validations made sense because they're really what the framework cares about -- i.e. that it's going to be able to invoke the function successfully, and that it's going to get back from the function what it expects. besides that, we try to just treat the override function as a black box.
in any case, i'd definitely like to talk/think through this one more. i'll leave it unaddressed for the moment.
src/fidesops/service/saas_request/override_implementations/mailchimp_request_overrides.py
Outdated
Show resolved
Hide resolved
src/fidesops/service/saas_request/override_implementations/mailchimp_request_overrides.py
Show resolved
Hide resolved
with the given name. | ||
""" | ||
|
||
if isinstance(request_types, SaaSRequestType): |
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.
What are lines 53-54 doing?
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.
ah it's just handling the case where the user passes in a single SaaSRequestType
by converting it to a list behind the scenes for them. do you know of a more idiomatic way of doing that? is that a bad thing to do in your opinion? it seemed convenient and harmless to me, and also seemed like the sorta thing that people do in python, but i wouldn't take my word for it 😅
noting here that unsafe CI checks succeeded after 2 failed attempts, without any code changes, so there's something fishy going on with the unsafe CI test. in this case, both failures were on the same assertion in the hubspot test erasure task -- the assertion that confirms the results of the access request that is accessing the erasure seed data. The same assertion failure occurred on this workflow run yesterday. i split out #992 |
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.
Thanks for making the changes and making the time to discuss some of the other points, this looks good to me!
* initial cut of saas request overrides. include mailchimp as an example and test case. minor refactor of some of the saas request execution to enable smoother override * fix rebase issue by moving saas override tests into ops subdir * import path updates to resolve conflicts caused by rebase * add session parameter into graph task calls to fix saas override integration tests caused by rebase * update changelog * tweaks to saas connector overrides and associated tests * expose override factory register as module variable for clenaer decorator calls Co-authored-by: Adam Sachs <[email protected]>
Purpose
Enables user (developer) to provide custom python extensions/overrides of saas request execution.
Changes
Checklist
CHANGELOG.md
fileCHANGELOG.md
file is being appended toUnreleased
section in an appropriate category. Add a new category from the list at the top of the file if the needed one isn't already there.Run Unsafe PR Checks
label has been applied, and checks have passed, if this PR touches any external servicesTicket
Fixes #815