SourceSystem name is only unique per type, but code assumes global uniqueness

[lunkwill42]

SourceSystem.name is enforced unique only per SourceSystemType, via the composite constraint on (name, type) (models.py:180-183). The name field itself is a plain TextField with no global uniqueness (models.py:162).

This means two source systems can share the same name as long as they belong to different types — e.g. a "prod" of type nav and a "prod" of type zabbix can coexist.

That contradicts code that treats the name as a global identifier. create_fake_incident resolves a source system by name alone with SourceSystem.objects.get(name=source) (models.py:57). Once two source systems share a name across types, that call raises MultipleObjectsReturned instead of returning a deterministic result.

Expected

A source system name should be unique across the whole installation, so that a name unambiguously identifies one source system regardless of type.

Actual

Uniqueness is scoped per type, so name collisions across types are permitted at the database level and code that looks up by name alone is not guaranteed a single result.

Suggested fix

Replace the (name, type) composite constraint with global uniqueness on name (either unique=True on the field or a single-column UniqueConstraint). A data migration will be needed to detect and resolve any existing cross-type name collisions before the new constraint can be applied.

Open questions

• Is per-type uniqueness relied upon anywhere intentionally? The constraint has existed since the initial migration, so this is a behavior change, not a regression fix.

[hmpf]

I think it would be better to change create_fake_incident. If a host runs two different glue services it might make sense for the sources to have the hostname as source-name.