| | 97 | Sometimes it may be necessary to move fields out of the master table into a component in order to have better control over access permissions to these fields, or to hold the same fields for multiple master tables in a single table. In these cases the a record in the master table can only have exactly one corresponding record in the component. |
| | 98 | |
| | 99 | This requirement is often called "singe-record component" or "subtable", and can be defined in the join dict: |
| | 100 | |
| | 101 | {{{ |
| | 102 | s3db.add_component("org_office", org_organisation={ |
| | 103 | "name": "headquarter", # the component alias |
| | 104 | "joinby": "organisation_id" # the foreign key |
| | 105 | "filterby": "office_type_id", # the name of the field in the component table to filter by |
| | 106 | "filterfor": 4, # the value(s) to filter for |
| | 107 | "multiple": False # there can be only one component record per master record |
| | 108 | }) |
| | 109 | }}} |
| | 110 | |
| | 111 | Most Eden modules respect the multiple-setting and enforce a single component record per master record. |
| | 112 | |
| | 113 | IMPORTANT: Note that it is possible, but '''not recommendable''', to change the multiple-setting dynamically in the controller environment: setting multiple=False does not allow to choose a particular component record, but simply selects the first (by ID) that matches the query. Thus, where the query can change (e.g. due to different authorization levels), then it is difficult to predict which record that would be, and different users may see different records despite multiple=False (which can be deliberate at times, though). |
