Skip to content

Refactor data structures in spar related to user-identifying information#3563

Draft
fisx wants to merge 100 commits intowireapp:developfrom
lepsa:WPB-1583
Draft

Refactor data structures in spar related to user-identifying information#3563
fisx wants to merge 100 commits intowireapp:developfrom
lepsa:WPB-1583

Conversation

@fisx
Copy link
Contributor

@fisx fisx commented Sep 5, 2023

https://wearezeta.atlassian.net/browse/WPB-1583
https://wearezeta.atlassian.net/browse/WPB-3530

Checklist

  • Add a new entry in an appropriate subdirectory of changelog.d
  • Read and follow the PR guidelines

lepsa and others added 19 commits August 25, 2023 18:21
…esentations

Creating a new generic data structure for holding valid combinations of
identifiers. It is intended to be used with `Const ()` and `Identity` to
represent existence and non-existence of a given identity option.

A tag and type family, modeled after `ConversationAction` is used to
limit the options of the above data structure to only those that are
deemed valid in some sense.
Added my thoughts and questions for fisx.
the way this works is as follows: we have a few fields in record types
like User, NewUser, NewUserRaw that contribute to the `UserIdentity`
type.  all those fields are collected here as-is, and then parsed
further to make sure that they do not contain any logic errors (like
uauth_id, but on team_id).  my earlier change to this type was based
on the inlining of the fields from UAuthId into the User record.  but
i realized i don't like inlining.  i think it makes things complicated
to parse both for machines and humans for no measurable benefit.

so, there are 4 components: phone, email, the legacy sso_id field, and
the new uauth_id field.
@fisx fisx added the ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist label Sep 26, 2023
@echoes-hq echoes-hq bot added echoes: product-roadmap Work aligned with the customer-announced roadmap, targeting a specific release date. echoes: technical-roadmap/technical-debt More specific category, to highlight Technical Debt being tackled. labels Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

echoes: product-roadmap Work aligned with the customer-announced roadmap, targeting a specific release date. echoes: technical-roadmap/technical-debt More specific category, to highlight Technical Debt being tackled. ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants