Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Move default_organization from default_taxonomy to fidesctl init

See original GitHub issue

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