Jamil

Resurrectable: - actor_groups - actors - auth_identities - policies - clients | table | resurrection side effects | | --- | --- | | actor_groups | clear `deleted_at` | |...

Update - now that we have a circuit breaker in place to prevent erroneous mass deletion of groups (and therefore policies), only groups, identities, and actors need to be resurrectable.

I believe this is because we don't shape the params properly on the first change event handler call, leaving the field in a truthy state.

Another possibility is that the field's value is converted to a string from an atom after change. Hit this with another input recently.

We could, but consider we already have these ~~five~~ six identifiers for clients in the portal ``` database_id (primary key) external_id (file-based device_id) device_serial (desktop only) device_uuid (desktop only) identifier_for_vendor...

That would break all existing client verifications though which customers are using.

Hm yeah we would need the additional ID field still and then a conditional codepath to either sha the new `device_id` or use the existing `external_id` as-is. This code is...

> Hm yeah we would need the additional ID field still This is needed to be able to cross-reference these to analytics tools because we wouldn't be able to compare...

> surely adding a sha to the analytics reporters is simpler overall? It also adds a bit of privacy between the metadata that lives on the organization's devices and the...

We can revisit when we do MDM-based verifications as we'll need massive changes in the portal anyhow. Related: #8369