ores.variability.operations

1. Physical space
2. Includes
3. Messages
4. See also

Four operations act on settings without being entity verbs, so they live in the component's reserved ops namespace rather than in the resource grammar NATS entity protocol specification § "Domain operations" defines for entities.

clear_bootstrap_mode ends a tenant's bootstrap window. It is not a write of one setting: it clears system.bootstrap_mode and sets onboarding.tenant, and it must succeed for the tenant that is activating whether or not the activating account holds the permission an ordinary setting write needs.

complete_party_onboarding marks one party's onboarding complete. The party it names is the party being onboarded, not the caller's own, so it cannot be an ordinary write: a write record's party comes from the authenticated context, and the two are different parties here. The tenant is still derived from the validated token, so the operation can only ever affect a party inside the caller's own tenant.

complete_system_onboarding records that the system provisioner wizard finished for the caller's own tenant. That tenant is the one the validated token states, so the operation carries no field of its own: unlike a party, which is not the caller's own, the subject of the write is already known. It is an operation rather than an ordinary setting write because it marks a platform milestone – a first-run installation holding only the system tenant has no other deployed fact that says the wizard finished – and it must succeed whether or not the activating account holds the permission an ordinary setting write needs.

get_setting reads one setting by the name it is known by. The entity's own read is addressed by identifier, which no caller outside this component holds, and a setting is always spoken of by name. It is the read a component makes of the installation's configuration – how often a sweep runs, how long a token lives – so it is deliberately narrow: one name in, one value out, and no way to list or write anything.

A component that needs a setting reads it over the wire rather than reaching into this component's tables. The alternative would put one component's schema in another's query, and the point of a service boundary is that it does not matter which.

1. Physical space

The shell commands are switched off. Three of these messages change platform state rather than read or write a row: one clears bootstrap mode once the first administrator exists, one completes a party's onboarding, and one records that the system provisioner wizard finished. The shell renders the system_setting entity's unit, and nothing in the shell sends these four.

2. Includes

#include "ores.utility/domain/protocol.hpp"
#include <boost/uuid/uuid.hpp>

3. Messages

3.1. clear_bootstrap_mode_request

3.2. clear_bootstrap_mode_response

3.2.1. result

Outcome of the operation, in the same shape every entity operation answers with, so a caller reads one result convention across the component.

3.3. complete_system_onboarding_request

The caller's tenant is the subject of the write, and the validated token already states it, so the request carries no field. A party being onboarded belongs to somebody else and is named; the tenant a caller works in is not.

3.4. complete_system_onboarding_response

3.4.1. result

3.5. complete_party_onboarding_request

3.5.1. party_id

The party whose onboarding is complete. This is the party being onboarded, not the caller's own party, which is why the value is carried here rather than derived from the token.

/*
 * The party being onboarded, which is not the caller's own party.
 */

3.6. complete_party_onboarding_response

3.6.1. result

3.7. get_setting_request

3.7.1. name

/**
 * @brief The setting's name, which is its natural key.
 *
 * A setting is addressed by its name everywhere it is spoken about --
 * =iam.token.access_lifetime_seconds= is the setting, and nobody knows its
 * identifier -- so a caller that holds a name asks for it by name rather than
 * by looking it up in a list first.
 */

3.8. get_setting_response

3.8.1. result

3.8.2. value

/**
 * @brief The setting's value as text, meaningful when the outcome is ok.
 *
 * The value is text whatever the type: =data_type= says how to read it, and a
 * caller that asked for a cron expression reads it as one.
 */

3.8.3. data_type

/**
 * @brief The setting's declared type, an empty string when it does not exist.
 */

4. See also

ores.variability — component group overview.