Address master — system description
Data model of the address master and the partner–address link, normalisation and duplicate check, address parsing, reference-protected deletion and permission keys.
Overview
Address master (postcode, town, public place, house number etc.) used by partners through a link table. There is no content (company) scope: a global master.
Data model
Table names carry the installation's own prefix in the database.
| Table | Purpose | Relation |
|---|---|---|
address | the address (owner: masterdata/address model) | postcode, town, public place name and type, house number, staircase, building, floor, door, lot number, country, status |
company_address | partner–address link | source of the delete protection and of the partner list on the form (read together with the company table) |
Process
- List: free-text and status filter, sort by postcode or town; per row a one-line address (public place + type + house number), country, status. Without permission a warning box replaces the list.
- Save: normalisation (trimming, collapsing dots and spaces), required postcode and town, duplicate check on the full address line, then insert or update; log entry; the answer returns the address identifier, there is no redirect.
- Parsing: splits a free-text address line into components.
- On/off: the status field.
- Delete: checks the selected addresses one by one; if any has a partner reference, it stops and lists up to five referring partners; otherwise physical deletion; logged.
Permissions
- Layer 2:
list;edit(form, parsing, on/off, the Add button in the header); saving a new record asksaddif the key is in the catalogue — as it is not,editdecides in practice;delete;debug(last SQL of the list). - Layer 3: none — global master.
Known limitations
- Opening the page itself checks no permission; the checks are on the list and the operations.
- The catalogue key
statusdelete(trash) is not implemented by the controller; the list does not filter for trash either.