Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate account slack alerts #388

Open
goztrk opened this issue Sep 25, 2023 · 1 comment
Open

Duplicate account slack alerts #388

goztrk opened this issue Sep 25, 2023 · 1 comment

Comments

@goztrk
Copy link
Contributor

goztrk commented Sep 25, 2023

Problem

accounts app has ability to have multiple e-mail addresses for UserModels.
When there are multiple servers doing transactions there might be times that records get duplicated.

Solution

This cannot be fixed automatically because it might be really hard to determine which one to
keep and which one to delete. Any wrong behavior will result with bad user experience.

As first step is to create a celery task that will search through user accounts and find duplicate email.

Flow

  1. Query all User records that have more than 1 UserEmail records.
  2. If there are records returned go to step 3. If there are no records go to step 4
  3. If there are records, alert them in #alerts-p2-danger listing out email addresses and user IDs. Goto step 5
    a. It might be useful to also include a link for admin tools
  4. Alert in #alerts-p4-info that there are no problematic tools.
  5. End Task

Important variables to be determined

  • Task schedule time
  • Should it have an enabled setting?
  • Slack alert channel names should be in settings?
  • Record item string should be a setting to change project specific?
@jontsai
Copy link
Member

jontsai commented Sep 26, 2023

I think this will be valuable to have, for sure.

Some thoughts:

  • We should probably decompose this into smaller components that can be used piece-meal. For example, instead of making it a Celery task, could we just make it a util function that can be invoked from multiple various entry points (Celery task being one of them; but also an Admin Tools webpage / triggered by an event; a cronjob; etc)
  • Separate schedule vs work performed vs data vs UI

Some principles:

  • Provide an opinionated approach/solution with "default combination of setup/settings" for things that are standalone / do not have a major impact on infrastructure/architectural decisions (e.g. microwavable Mac-n-Cheese, just add cheese sauce mix and water and heat)
  • For things that do require additional architecture/infrastructure, provide call sites or hooks to easily invoke, but not not pre-mix, do not prescribe a specific solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants