SET · Settings

Each organization has one settings row. A pool may override a few of its values; an empty pool value means the organization's applies. app.setting(pool, key) returns the value that applies. Code SET.

Answered questions

• DOC-Q10, SET open 1 (is there always an organization row to fall back to): yes. A new rule, R-SET-06: the settings row is created with the organization.

Rules

R-SET-01 · A pool's setting, when set, overrides the organization's; when empty, the organization's applies

• Status: planned
• Example: given the organization's checkpoint_interval_days is 14 and pool SBY sets 10, when app.setting(SBY, 'checkpoint_interval_days') is read, then it returns 10; for pool PML, with no value of its own, it returns 14.
• Refusal: none.
• Who: every reader of a setting: the gate, the checkpoint list, the queue.
• Source: D9 (P10, S2); the M0 acceptance checks.

R-SET-02 · Only queue opening, queue hours, tickets per phone and the checkpoint interval can be set per pool

• Status: planned
• Example: given pool SBY, when its overdue_limit_days is set, then there is no such column in pool_settings; queue_open, queue_opens_at, queue_closes_at, max_tickets_per_phone and checkpoint_interval_days are the only ones.
• Refusal: none: this describes the schema.
• Who: every pool.
• Source: [Ref] Data model V13: pool_settings.

R-SET-03 · A new organization's settings start at the defaults listed in [Ref] Database rules

• Status: planned
• Example: given a new organization, when its settings are read, then checkpoint_interval_days is 14, overdue_limit_days is 3, panel_fee is 300000, allow_cross_entity_payments is true and require_visit_before_booking is false, as the table lists.
• Refusal: none.
• Who: every new organization.
• Source: [Ref] Database rules and conventions, Settings; [Ref] Data model V13: organization_settings.

R-SET-04 · Organization and pool settings are readable by every member of the organization

• Status: planned
• Example: given a satpam, when he reads organization_settings, then his organization's row comes back.
• Refusal: none.
• Who: every member, whatever their roles.
• Source: [Ref] Roles, policy matrix.

R-SET-05 · Changing organization or pool settings needs master_data:write

• Status: planned
• Example: given a checker, when she sets pool PML's checkpoint interval to 10, then nothing changes; an admin's change goes through.
• Refusal: none: insufficient_privilege (42501) on insert; no effect on update.
• Who: super_admin, admin, maintenance and asuransi hold master_data:write.
• Source: [Ref] Roles, policy matrix.

R-SET-06 · Every organization has a settings row, created with the organization

• Status: planned
• Example: given a new organization is saved, when organization_settings is read in the same transaction, then its row is there with the defaults, so app.setting() always has an organization value to fall back to.
• Refusal: none.
• Who: every new organization.
• Source: D9 (P10: app.setting falls back to the organization); [Ref] Data model V13: organization_settings, keyed by organization with every column defaulted. Added for DOC-Q10 (SET open 1).