fides
fides copied to clipboard
ethyca
Move default_organization from default_taxonomy to fidesctl init
Is your feature request related to a specific problem?
As part of the data map work, the organization object now contains numerous attributes containing custom data.
When a change occurs, it appears to refresh the default_taxonomy on the server and overwrite the existing custom organization. Additionally, the documentation around an organization should reflect the workflow around maintaining the organization resource.
Describe the solution you'd like
Have the creation of a basic organization occur as part of the fidesctl init command and be removed from the default_taxonomy. Update the docs for the organization resource to no longer suggest ignoring this resource.
Describe alternatives you've considered, if any
We could possibly protect the default_organization fides key and require users to have a different one if we need to preserve the behavior for some reason. This could be a decent impact for some of our testing so am open to any alternatives
Another option would be to use on_conflict_do_nothing as part of the upsert that occurs when loading the default taxonomy.
Additional context
This could be an issue that does not occur in normal usage but more of an impact to how the server is handled during development. In my case, it appeared that something mysterious was overwriting values on the server so wanted to open an issue to potentially address that.
Wider scope, I feel that the organization has grown from something where it made perfect sense to be treated as a default object to now being a richer object deserving of some extra support to manage
I'm currently exploring a temporary workaround in #350 by altering the upsert method used, but will plan to try and get some conversations started around the merits of modifying how we assign organizations in the near future
@SteveDMurphy good call here. The upserting for default resources is definitely inelegant but was the best solution at the time. let's collaborate to figure out a more elegant alternative now that some of those "default" objects are getting richer (data uses included, yeah?)
Great, thanks @ThomasLaPiana ! Yes, data uses are in the same boat, but in general the separate fides key should keep issues lower than the organization. I think changing the default upsert behavior to on_conflict_do_nothing is a decent interim state for now until we have some more use cases / stories and time to be thoughtful around what is best long term
So the target behaviour here is that we still need to seed the db with a default organization, but we also want to let people update that default organization without rewriting it every time a server spins up....
also, if we think about this in the case of someone spinning up multiple servers, they don't all need to load the default taxonomy right? maybe that behavior needs to change in general to something a little more robust
Totally agree, based on what you mention there it feels like something load_default_taxonomy could be handled as part of the fidesctl init workflow instead of being somewhat implicit as part of the configure_db or init_db world that runs as part of spinning up infrastructure.
After some more thought, I'm not entirely sure if the workaround I put in the export PR is valid or negates the upsert functionality we want so am leaning towards removing it for now
Need to see if the work from #421 by @PSalant726 means we can close this or if we still want to review making a change here
@SteveDMurphy this got changed to specifically not mess with the org if it already exists as a special case
https://github.com/ethyca/fides/blob/main/fidesctl/src/fidesapi/database/database.py#L71-L79
and the docstring: https://github.com/ethyca/fides/blob/main/fidesctl/src/fidesapi/database/database.py#L59-L61
so i think we're safe here