Data model and permissions of the contract master lists
Tables of the immediate termination reasons, registration rejection reasons and brokerage activities, the related snapshots, endpoints and function keys.
The three lists are shared installation data: they have no content scope, but their use (contract, registration, termination) happens under the contract's content permission. Each uses a description table per language.
Data model
Table names carry the installation's own prefix in the database.
| Table | Main fields | Used by |
|---|---|---|
contract_term_reason + _description | code, main_type, sub_type (comma list, empty = all), default_clause, is_starter, sort_order, status; description: name, legal_text | contract_term_reason_link (unique: contract + reason; clause_ref, custom_text, sort_order), on termination a snapshot in contract_event_reason |
registration_reject_reason + _description | code, sort_order, status; description: name | contract_registration_advert.reject_reason_id and reject_reason_name (snapshot) |
brokerage_activity + _description | code, sort_order, status; description: name | contract_registration_activity (activity_name snapshot, language_id) |
Rules
- Only active items can be chosen as new references; for termination reasons only those valid for the contract's main type and sub-type.
- The contract's own clause number (
clause_ref) is at most 32 characters; the default is the master'sdefault_clause. - Termination reasons (
contract_event_reason), the rejection reason and registration activities are stored as snapshots, so later master changes do not alter them. - Starter items are loaded by migration (
is_starteron termination reasons).
Endpoints and permissions
All three routes (contract/termreason, contract/rejectreason, contract/brokeractivity) share the same structure: index, list, form, save, enable, disable, statusdelete, delete. Function keys: list, add, edit, statusdelete, delete, debug (BASE). statusdelete moves to the bin (status = 9), delete deletes permanently.