Data model and rules of the client registration
The header and row structure of the registration, the per-row decision endpoints, the rejection document, duplicate detection and the interested party's data room access.
The registration is the registration kind of the contract/contractaction module. The header is one document, one PDF and one date; the row per advert is the independent business unit with its own decision.
Data model
Table names carry the installation's own prefix in the database.
| Table | Role | Main fields |
|---|---|---|
contract_registration | header | registration_no (contractno/REG-n), company_id, person_id, contact references, agent name and tax number (snapshot), dates, activity_text, att_* flags, decision (pending, accepted, rejected, partial), template_id, language_id, body, doc_id, status |
contract_registration_advert | row (unique: registration + advert) | contract_property_id, deal_type (sale, rent, share_sale), decision, reject_reason_id, reject_reason_name, reject_doc_id, duplicate_of |
contract_registration_activity | activities (unique: registration + activity) | activity_name snapshot in the document language |
The interested party's data (name, address, tax number, registration number, representative, contact) is resolved live from master data into the document; the legacy text client columns remain for old forms. The selectable adverts are the active adverts of the contract's properties, within content scope. A decided row or one linked to a deal cannot be removed by re-saving.
Decision
contract/contractaction.acceptor.reject(accept,rejectpermission),row_id= one registration row. The header decision is a summary; on a legacy registration without rows the header decides.- On rejection the reason comes from the active master; if active reasons exist, it is required.
- The one-sided rejection document is created at once from the
reg_rejectiontemplate; a failure does not revert the decision (warning, can be regenerated later). - The data room access of a rejected row ends through the shared path, with a timeline entry.
- Cannot be rejected: a row linked to a deal and a row with an accepted offer.
Duplicate detection
After saving, per row: an earlier, non-rejected, non-deleted row for the same interested party (same company OR person) and the same advert or any advert of the same property, in any contract. On a match the row gets duplicate_of; the person saving gets a warning (without details for a foreign client scope); the admins who see the client company get a system message (notification), and the details of the earlier registration are shown only to those who also have access to it.
Data room access of the interested party
On an accepted row (permission: contract/contractaction + roomaccess) the shared folder endpoint (user/user.shareadd, ctx=registration) creates a user from the registration's person and grants the offering folder from today until the earlier of the contract end and the brokerage row end (doc_share_user.source = registration, source_ref = the registration row). Revoking (user/user.shareremove) only removes the row's own folder rows.
Permissions
contract/contractaction: list, add, edit, statusdelete, delete, accept, reject, generate, debug, roomaccess. Content scope: access to a registration filters on the client of the row's contract. List filter: contract, kind, name, decision, status.