-
Notifications
You must be signed in to change notification settings - Fork 74
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
Adding support for configuring enabled actions #4374
Conversation
config_file = os.path.join("data/saas/config", file) | ||
config_dict = load_config(config_file) | ||
connector_type = config_dict["type"] | ||
human_readable = config_dict["name"] | ||
user_guide = config_dict.get("user_guide") | ||
authentication = config_dict["client_config"].get("authentication") | ||
config_path = os.path.join("data/saas/config", file) | ||
config = SaaSConfig(**load_config(config_path)) | ||
|
||
connector_type = config.type | ||
|
||
authentication = config.client_config.authentication |
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.
Refactoring to use a SaaSConfig
instead of a Dict
this way it's more consistent with the way it's done in other places in this file.
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.
that seems good 👍
return bool( | ||
(ActionType.consent in action_types and has_consent) | ||
or (ActionType.access in action_types and has_access) | ||
or (ActionType.erasure in action_types and has_erasure) |
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 logic was simplified and moved to the SaaSConfig
https://github.com/ethyca/fides/pull/4374/files#diff-e02882cee5e6ee2325e4d613abed561b386e3e15064d0a1cbb41785a5d3f6d1aR483
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! like the refactor here 👍
@@ -157,6 +128,7 @@ def saas_request_type_filter(connection_type: str) -> bool: | |||
identifier=item, | |||
type=SystemType.database, | |||
human_readable=ConnectionType(item).human_readable, | |||
supported_actions=[ActionType.access, ActionType.erasure], |
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.
DB connectors will support access and erasure by default
@@ -1005,7 +1005,7 @@ def test_get_connection_secret_schema_mysql( | |||
"type": "string", | |||
}, | |||
"ssh_required": { | |||
"title": "SSH Required", | |||
"title": "SSH required", |
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.
Changing SSH required
to use sentence-case to be consistent with the other field labels.
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.
how dare you!
enabled_actions = getattr(template_values, "enabled_actions", None) | ||
if enabled_actions is not None: | ||
data["enabled_actions"] = enabled_actions |
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 function is used by both fides and fidesplus endpoints so we need to perform this attribute check to map the enabled_actions
attribute which is only found in fidesplus.
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, this is an interesting pattern. i can't say i love it, it feels like a development footgun moving forward - we're implying (in a pretty cryptic manner) that someone developing here in fides knows about something defined over in fidesplus. i'm wouldn't be surprised if we do that in some other places already, but my gut-instinct tells me it's something we should try to avoid if possible.
i'll make a broader comment on the PR at this point, since i think this is a holistic concern - not tied to this particular code block, even though this is where it's manifested
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.
These two model changes were generated by openapi:generate
but I didn't keep the other changes to avoid a huge diff.
Passing run #5175 ↗︎
Details:
Review all test suite changes for PR #4374 ↗︎ |
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.
@galvana broadly this looks good, i just get concerned with any sort of reverse dependency of OSS on plus. i know it's not a hard dependency, but see my inline comment for the concern - basically it's a maintainability/development concern. having an expectation within the BE OSS codebase that we need to be aware of things defined in plus sets a bad precedent. we may do it in other places, but i don't think it should be encouraged.
i know we're trying to layer in a plus-only feature on top of a lot of OSS plumbing that i'm sure needs to stay in OSS, or at least can't be quickly moved out. so if we need to do this here, i'm not going to totally hold this up. i know we're not purists on this, nor should we be - i just want to see if there's anything we can think of to untangle this.
what's first popping into my head - how about some sort of override/extension of create_connection_config_from_template_no_save
in plus that has the enabled action handling tacked on top of the rest of the function defined in OSS? basically just keeping all enabled_action
logic in plus...
happy to talk this one over. maybe my concern's misplaced/overblown. in any case, i don't think this path forward is totally unviable -- if we need to do it, we can. it just adds some tech debt and feels to me like an antipattern we should strive to avoid, if we can.
edit: i've got a tweak that would address the main point of my concern, and i think it'd be cleaner code generally. still untested though! let me know what you think... #4386 and https://github.com/ethyca/fidesplus/pull/1210
enabled_actions = getattr(template_values, "enabled_actions", None) | ||
if enabled_actions is not None: | ||
data["enabled_actions"] = enabled_actions |
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, this is an interesting pattern. i can't say i love it, it feels like a development footgun moving forward - we're implying (in a pretty cryptic manner) that someone developing here in fides knows about something defined over in fidesplus. i'm wouldn't be surprised if we do that in some other places already, but my gut-instinct tells me it's something we should try to avoid if possible.
i'll make a broader comment on the PR at this point, since i think this is a holistic concern - not tied to this particular code block, even though this is where it's manifested
@@ -1005,7 +1005,7 @@ def test_get_connection_secret_schema_mysql( | |||
"type": "string", | |||
}, | |||
"ssh_required": { | |||
"title": "SSH Required", | |||
"title": "SSH required", |
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.
how dare you!
return bool( | ||
(ActionType.consent in action_types and has_consent) | ||
or (ActionType.access in action_types and has_access) | ||
or (ActionType.erasure in action_types and has_erasure) |
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! like the refactor here 👍
config_file = os.path.join("data/saas/config", file) | ||
config_dict = load_config(config_file) | ||
connector_type = config_dict["type"] | ||
human_readable = config_dict["name"] | ||
user_guide = config_dict.get("user_guide") | ||
authentication = config_dict["client_config"].get("authentication") | ||
config_path = os.path.join("data/saas/config", file) | ||
config = SaaSConfig(**load_config(config_path)) | ||
|
||
connector_type = config.type | ||
|
||
authentication = config.client_config.authentication |
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.
that seems good 👍
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #4374 +/- ##
=======================================
Coverage 87.08% 87.09%
=======================================
Files 329 329
Lines 20309 20354 +45
Branches 2610 2621 +11
=======================================
+ Hits 17687 17728 +41
- Misses 2160 2163 +3
- Partials 462 463 +1
☔ View full report in Codecov by Sentry. |
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.
ok from a BE perspective this is looking good to me! i had a few comments on the plus PR of things you may look to tweak, but i don't think any of those would require updates here.
a couple of notes that we just need to consider before merging:
- reminder to update the readme :)
- i haven't done any code review on the FE pieces, so it may be good to have a FE dev specifically review those?
- i haven't gotten a chance to perform any UAT on this - and that feels like that'd probably be a good idea, particularly if there hasn't been any FE code review! i can get to that tomorrow if that's OK?
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 looking good! the only thing that might be odd is when I try to autogenerate TS types off of your fidesplus branch, the enabled_actions
field gets deleted from CreateConnectionConfigurationWithSecrets
—is that expected?
it("should not display disabled actions field", () => { | ||
cy.getByTestId("enabled-actions").should("not.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.
thanks for adding these tests! 💯
<Field | ||
id="enabled_actions" | ||
name="enabled_actions" | ||
validate={(value: string[]) => { |
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.
normally it'd be better to do this as part of a validation schema, but I don't think this form has one... it does validation pretty oddly, so this is in line with the component, just making a note!
Yes @allisonking, that's expected, |
Co-authored-by: Adam Sachs <adam@ethyca.com>
UAT tested this piece on RC, looks good! still haven't yet confirmed the effect of enabled actions but the form functionality (including saving/persisting changes) looks good 👍 |
Description Of Changes
Adding the ability to specify which privacy actions (access, erasure, consent) to enable for a system integration. The new
Enabled actions
field is a multi-select with the options being the actions supported by the integration.Code Changes
ConnectorParamaters
component to call the fidesplus versions of the system integration endpoints if fidesplus is availableConnectorParameterForm
to conditionally render theEnabled actions
field if fidesplus is enabled AND there is more than one action to choose from. The option to disable an action won't be available if it's the only action.patchSystemConnectionConfigs
andcreateSaasConnectionConfig
toplus.slice.ts
supported_actions
andenabled_actions
fieldshas_access
,has_erasure
,has_consent
logic inconnection_type.py
and moved it tosaas_config.py
connector_registry_service.py
SSH required
)Steps to Confirm
Enabled actions
access
anderasure
erasure
orconsent
access
anderasure
Enabled actions
field enabled, make a change and verify the change persistsPre-Merge Checklist
CHANGELOG.md