Taxonomy CRUD API should compute active property based on ancestors' active property

[adamsachs]

Is your feature request related to a specific problem?

In #3784 we added an active property to taxonomy elements (in our API and DB models). The desired behavior of this functionality (generally covered in #3710) is such that we'd like descendants (i.e. children, granchildren, etc.) of a deactivated taxonomy element to also show up as effectively deactivated to the FE.

Describe the solution you'd like

We will need to compute on the BE the effective active property of a given taxonomy element whenever that element is returned by the API. The effective active value based on both its own active property value in the DB as well as its ancestors' active property values - all must be true for an elements' effective active property to also be true.

We should compute this at the API layer, and not at the DB level -- i.e. as "late" as possible -- to avoid:

• additional complexity related to propagating state across elements as ancestor taxonomy elements change state
  • relatedly: not computing the property at the DB level also helps us avoid more special-cased logic in our update operations - all the special-casing for the active property can just be done when elements are being retrieved/returned by the API.
• to maintain information about which taxonomy elements have been explicitly marked as active/inactive by users. i.e. if a parent element changes from active=false to active=true state, we need to know whether a child had been explicitly marked as active=false to know what its new effective active property should be.

credit to @allisonking for thinking thru the implementation! she suggested show_banner in our privacy experience API https://github.com/ethyca/fides/blob/main/src/fides/api/models/privacy_experience.py/#L212-L215 as an example for what this may look like.

Describe alternatives you've considered, if any

We also discussed computing the "effective" active state on the FE, which would be feasible. But we judged that to introduce more unneeded logic and complexity on the FE, so computing this on the BE was preferred.

Additional context

See related slack thread for some more context.

[rsilvery]

@adamsachs is this still an issue?

[adamsachs]

@adamsachs is this still an issue?

yup, assuming we still consider that the desired behavior here is to deactivate children/descendants of a parent taxonomy element when the parent is deactivated. that's not what currently happens, and this ticket is meant to cover that gap between current functionality and desired behavior, which still exists afaik.