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

Adding support for configuring enabled actions #4374

Merged
merged 21 commits into from
Nov 10, 2023

Conversation

galvana
Copy link
Contributor

@galvana galvana commented Nov 2, 2023

Description Of Changes

⚠️ Requires the corresponding branch in fidesplus to test https://github.com/ethyca/fidesplus/pull/1205

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

  • Updated the ConnectorParamaters component to call the fidesplus versions of the system integration endpoints if fidesplus is available
  • Updated the ConnectorParameterForm to conditionally render the Enabled 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.
  • Added fidesplus versions of patchSystemConnectionConfigs and createSaasConnectionConfig to plus.slice.ts
  • Updated select models with supported_actions and enabled_actions fields
  • Refactored the has_access, has_erasure, has_consent logic in connection_type.py and moved it to saas_config.py
  • Minor cleanup of the connector_registry_service.py
  • Minor field name fixes (SSH required)

Steps to Confirm

  • Start fidesplus
  • Start the Admin UI
  • Create a new system
  • Select a new integration from the integration search
  • Note the default values for the Enabled actions
    • Database connectors should have access and erasure
    • SaaS connectors will vary based on the supported actions
    • Not available for email connectors since they only support one action, either erasure or consent
    • Manual connectors should have access and erasure
  • For the integrations with the Enabled actions field enabled, make a change and verify the change persists
  • Shut down fidesplus and start fides, verify the field is not available for any of the broad connector types (DB, SaaS, email, manual)

Pre-Merge Checklist

  • All CI Pipelines Succeeded
  • Documentation:
  • Issue Requirements are Met
  • Update CHANGELOG.md

Comment on lines -73 to +78
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
Copy link
Contributor Author

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.

Copy link
Contributor

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)
Copy link
Contributor Author

@galvana galvana Nov 2, 2023

Choose a reason for hiding this comment

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

Copy link
Contributor

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],
Copy link
Contributor Author

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",
Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

how dare you!

Comment on lines 344 to 346
enabled_actions = getattr(template_values, "enabled_actions", None)
if enabled_actions is not None:
data["enabled_actions"] = enabled_actions
Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link

cypress bot commented Nov 2, 2023

Passing run #5175 ↗︎

0 4 0 0 Flakiness 0
⚠️ You've recorded test results over your free plan limit.
Upgrade your plan to view test results.

Details:

Merge 796bf00 into 1e6d9fb...
Project: fides Commit: cfc8d136ef ℹ️
Status: Passed Duration: 00:54 💡
Started: Nov 10, 2023 3:38 AM Ended: Nov 10, 2023 3:38 AM

Review all test suite changes for PR #4374 ↗︎

@galvana galvana marked this pull request as ready for review November 3, 2023 03:43
Copy link
Contributor

@adamsachs adamsachs left a 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

Comment on lines 344 to 346
enabled_actions = getattr(template_values, "enabled_actions", None)
if enabled_actions is not None:
data["enabled_actions"] = enabled_actions
Copy link
Contributor

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",
Copy link
Contributor

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)
Copy link
Contributor

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 👍

Comment on lines -73 to +78
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
Copy link
Contributor

Choose a reason for hiding this comment

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

that seems good 👍

Copy link

vercel bot commented Nov 6, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
fides-plus-nightly ⬜️ Ignored (Inspect) Visit Preview Nov 10, 2023 3:23am

Copy link

codecov bot commented Nov 6, 2023

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (1e6d9fb) 87.08% compared to head (796bf00) 87.09%.

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     
Files Coverage Δ
src/fides/api/common_exceptions.py 91.48% <100.00%> (+0.09%) ⬆️
src/fides/api/models/manual_webhook.py 100.00% <100.00%> (ø)
...emas/connection_configuration/connection_config.py 100.00% <100.00%> (ø)
...nnection_configuration/connection_secrets_mysql.py 100.00% <ø> (ø)
...ction_configuration/connection_secrets_postgres.py 100.00% <ø> (ø)
...ction_configuration/connection_secrets_redshift.py 100.00% <ø> (ø)
...ection_configuration/connection_type_system_map.py 100.00% <100.00%> (ø)
...ction_configuration/saas_config_template_values.py 100.00% <100.00%> (ø)
src/fides/api/schemas/saas/connector_template.py 84.61% <100.00%> (+1.28%) ⬆️
src/fides/api/schemas/saas/saas_config.py 95.88% <100.00%> (+0.19%) ⬆️
... and 5 more

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@adamsachs adamsachs left a 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?

@allisonking
Copy link
Contributor

taking a look! getting an error once I select an integration:
image

@allisonking
Copy link
Contributor

taking a look! getting an error once I select an integration: image

Never mind, I think I needed to run fidesplus with dev_prerelease to get this working!

Copy link
Contributor

@allisonking allisonking left a 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");
});
});
Copy link
Contributor

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[]) => {
Copy link
Contributor

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!

@galvana
Copy link
Contributor Author

galvana commented Nov 9, 2023

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?

Yes @allisonking, that's expected, enabled_actions was moved to the fidesplus model CreateConnectionConfigurationWithSecretsExtended

@galvana galvana merged commit 22614a5 into main Nov 10, 2023
47 of 48 checks passed
@galvana galvana deleted the PROD-1249-configure-enabled-actions branch November 10, 2023 04:04
galvana added a commit that referenced this pull request Nov 10, 2023
@adamsachs
Copy link
Contributor

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 👍

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