Practice migration: remove duplicate contacts

[BCerki]

card: https://github.com/orgs/bcgov/projects/123/views/16?pane=issue&itemId=98643893&issue=bcgov%7Ccas-registration%7C2878

This PR:

• 1 migration to replace Operation Registration Lead business_role with Operation Representative (this is necessary because one of our duplicate contacts uses this old role)
• 1 migration to remove duplicate contacts

[Sepehr-Sobhani]

Awesome! 🤩
Quick question for @andrea-williams: Do we need to add a unique constraint to prevent duplicate emails in the operator?
something like:

constraints = [
            models.UniqueConstraint(
                fields=['email', 'operator'],
                name='unique_email_per_operator',
                condition=models.Q(operator__isnull=False)
            )
        ]

[andrea-williams]

Awesome! 🤩 Quick question for @andrea-williams: Do we need to add a unique constraint to prevent duplicate emails in the operator? something like:

constraints = [
            models.UniqueConstraint(
                fields=['email', 'operator'],
                name='unique_email_per_operator',
                condition=models.Q(operator__isnull=False)
            )
        ]

I don't actually know. Going to loop in @patriciarussellCAS to get her opinion on this.

My first question is whether there's a risk to having multiple contacts within the same operator that have the same email? We don't have any restrictions on names, so it's technically possible for industry users to create duplicate contact records for the same person within the same operator. Is that something that we need to be concerned about? I'm not sure.

A secondary question is this: if an operator has some sort of generic inbox (e.g., [email protected]) is there a need for us to prevent industry users from creating multiple contacts (e.g., Bill Blue and Brenda Brown) that both use that generic inbox? And building on top of that, we don't actually have any way of preventing industry users from creating a generic contact like (first_name=Reporting, last_name=Department, [email protected], phone_number=604-111-1111).

IMO unless there's a solid reason for enforcing unique emails, it's better to leave it as-is and not introduce additional constraints/complexity without reason.

[Sepehr-Sobhani]

Awesome! 🤩 Quick question for @andrea-williams: Do we need to add a unique constraint to prevent duplicate emails in the operator? something like:

constraints = [
            models.UniqueConstraint(
                fields=['email', 'operator'],
                name='unique_email_per_operator',
                condition=models.Q(operator__isnull=False)
            )
        ]

I don't actually know. Going to loop in @patriciarussellCAS to get her opinion on this.

My first question is whether there's a risk to having multiple contacts within the same operator that have the same email? We don't have any restrictions on names, so it's technically possible for industry users to create duplicate contact records for the same person within the same operator. Is that something that we need to be concerned about? I'm not sure.

A secondary question is this: if an operator has some sort of generic inbox (e.g., [email protected]) is there a need for us to prevent industry users from creating multiple contacts (e.g., Bill Blue and Brenda Brown) that both use that generic inbox? And building on top of that, we don't actually have any way of preventing industry users from creating a generic contact like (first_name=Reporting, last_name=Department, [email protected], phone_number=604-111-1111).

IMO unless there's a solid reason for enforcing unique emails, it's better to leave it as-is and not introduce additional constraints/complexity without reason.

If we don't enforce a unique email constraint now, we may end up having to clean up duplicate contacts again later. I assume that each email represents a unique point of contact, and by limiting duplicates within the same operator, we allow that email to be used in other operators (in case a user is a consultant or moves from one operator to another).

[andrea-williams]

Awesome! 🤩 Quick question for @andrea-williams: Do we need to add a unique constraint to prevent duplicate emails in the operator? something like:

constraints = [
            models.UniqueConstraint(
                fields=['email', 'operator'],
                name='unique_email_per_operator',
                condition=models.Q(operator__isnull=False)
            )
        ]

I don't actually know. Going to loop in @patriciarussellCAS to get her opinion on this.
My first question is whether there's a risk to having multiple contacts within the same operator that have the same email? We don't have any restrictions on names, so it's technically possible for industry users to create duplicate contact records for the same person within the same operator. Is that something that we need to be concerned about? I'm not sure.
A secondary question is this: if an operator has some sort of generic inbox (e.g., [email protected]) is there a need for us to prevent industry users from creating multiple contacts (e.g., Bill Blue and Brenda Brown) that both use that generic inbox? And building on top of that, we don't actually have any way of preventing industry users from creating a generic contact like (first_name=Reporting, last_name=Department, [email protected], phone_number=604-111-1111).
IMO unless there's a solid reason for enforcing unique emails, it's better to leave it as-is and not introduce additional constraints/complexity without reason.

If we don't enforce a unique email constraint now, we may end up having to clean up duplicate contacts again later. I assume that each email represents a unique point of contact, and by limiting duplicates within the same operator, we allow that email to be used in other operators (in case a user is a consultant or moves from one operator to another).

right. You've successfully convinced me @Sepehr-Sobhani ! Yes please, let's add in that unique constraint on email per operator!

[BCerki]

I've added the constraint to real ticket (the migration numbers will be out of order by now and this will have to be redone anyway when we go to apply things for real)