Problem
When refugee centers (Agents) fill out their address in forms, the address cannot be reliably retrieved through the Person entity. This is a known deep issue.
Current Data Model
The relevant relationships are:
Agent ──→ Address (optional, ManyToOne)
──→ AgentPerson[] ──→ Person
└──→ Address (optional, ManyToOne)
Address ──→ Postcode (required)
Postcode.value is validated for Berlin/Potsdam postcodes only
Address.title has a UNIQUE constraint (100 chars)
Suspected Root Causes (need investigation)
1. Two separate address fields — Agent.address vs Person.address
Agent has its own address field
- Each
Person linked to that Agent via AgentPerson also has a separate address field
- When a form saves an address, it may be going to
Person.address but the query reads Agent.address (or vice versa), so the address appears missing
2. Postcode validation constraint
Postcode.value is validated to Berlin/Potsdam postcodes only
- If the agent's address is outside that range (or the postcode record doesn't exist yet),
Address creation fails silently or throws
- This means the address save succeeds at the form level but the related
Address record was never persisted
3. Address.title UNIQUE constraint
Address.title has a 100-char UNIQUE constraint
- If two agents share a building/address, the second insert fails with a unique constraint violation
4. Person.address is optional but never populated for agent contacts
- Agents are represented as organizations, not persons
- The form may be filling in
Person fields thinking it populates the agent's address, but the Agent.address field is never set
Investigation Checklist
Expected Behavior
When a refugee center fills in their address through the form, that address should be:
- Saved correctly (no silent failures from postcode validation or uniqueness constraints)
- Retrievable via the agent entity in API responses
Notes
- This is a deep structural issue — do not change the schema before the investigation is complete
- Related: the
Agent.representative computed getter finds the VOLUNTEER_COORDINATOR AgentPerson, which may be the intended contact whose address should surface
Problem
When refugee centers (Agents) fill out their address in forms, the address cannot be reliably retrieved through the Person entity. This is a known deep issue.
Current Data Model
The relevant relationships are:
Suspected Root Causes (need investigation)
1. Two separate address fields — Agent.address vs Person.address
Agenthas its ownaddressfieldPersonlinked to that Agent viaAgentPersonalso has a separateaddressfieldPerson.addressbut the query readsAgent.address(or vice versa), so the address appears missing2. Postcode validation constraint
Postcode.valueis validated to Berlin/Potsdam postcodes onlyAddresscreation fails silently or throwsAddressrecord was never persisted3. Address.title UNIQUE constraint
Address.titlehas a 100-char UNIQUE constraint4. Person.address is optional but never populated for agent contacts
Personfields thinking it populates the agent's address, but theAgent.addressfield is never setInvestigation Checklist
AgentPersonjoin has a role that should determine which Person's address is "the agent's address"Expected Behavior
When a refugee center fills in their address through the form, that address should be:
Notes
Agent.representativecomputed getter finds theVOLUNTEER_COORDINATORAgentPerson, which may be the intended contact whose address should surface