ores.iam.seed_profile

1. Flags
2. Columns
3. SQL
- 3.1. Flags
- 3.2. Checks
4. Insert trigger
- 4.1. Validations
5. C++
6. See also

A seed profile is the data set that provisioning gives a new tenant. One row orders step kinds from the catalogue in code, declares the parameters its form takes, carries the tenant details it prefills, and carries the card the person choosing a starting point reads.

A new profile is a row, so an operator adds one with no code change. A new step kind is code. The accepted seed profile contract fixes both lists, and the first two rows are:

empty_operational: the production starting point. It publishes the base bundle, takes a counterparty count and a GLEIF root LEI to import, and creates no test data.
acme_demo: the Acme Corporation holding group, with its staff, books and market data. Every test datum lives here.

A profile is system-owned registered data. The system_scope flag states that the table stores it under the system tenant and that the insert trigger forces that tenant. Provisioning reads a profile before the tenant it creates exists, so a profile cannot belong to the tenant being made.

The profile the model binds is uuid-identified-lookup, the one its sibling ores.iam.tenant binds, because that profile leaves system_scope to the model. uuid-surrogate-lookup fixes it to false, which a row the platform owns cannot be.

The ordered steps are rows of ores.iam.seed_profile_step, and the form schema is rows of ores.iam.seed_profile_parameter. Both are children of this entity.

1. Flags

2. Columns

2.1. id

Surrogate identifier for the profile. Provisioning names a profile by its code, so the surrogate exists for referential stability only.

2.2. code

Stable code the request names the profile by. The unique index states the code once, because a profile is one row per deployment and not one row per tenant.

Examples: 'empty_operational', 'acme_demo'.

// no_generator_suffix: the "-<idx>" the template appends is a process counter
// that starts again with every run, so a second run against the same database
// would ask for the code it asked for the first time and the index that keeps
// this one unique per deployment would refuse it. The synthetic row carries a
// uuid instead.
std::string(faker::word::noun()) + "_profile-" + std::string(faker::string::uuidV4())

2.3. name

Name shown on the starting-point card.

std::string(faker::word::adjective()) + " Profile"

2.4. summary

The card's tagline: one line saying what the profile sets up, for example "Production-ready setup".

std::string(faker::lorem::sentence())

2.5. audience

Who the profile is for, as the line beside its name on the card, for example "For real use" or "For demos and testing".

std::string("For ") + std::string(faker::word::noun())

2.6. bullets_json

The card's bullets, in the order it shows them, as a serialised JSON array of short lines. The card shows at most three. A profile that states none shows none, which is not the same as stating an empty line.

std::string("[]")

2.7. tenant_type

Classification of the tenant this profile creates, validated against ores_iam_tenant_types_tbl. A profile for real use makes a production tenant; a demonstration profile makes an evaluation one. The form does not ask for it, because the starting point the person chose already states it.

std::string("production")

2.8. tenant_name

Tenant display name the profile prefills. An empty value states that the form starts blank and the administrator supplies the name.

std::string(faker::company::companyName())

2.9. tenant_code

Tenant code the profile prefills. Together with the hostname it is what a later sign-in principal names.

faker::word::noun()

2.10. tenant_hostname

Hostname the profile prefills. A principal of the form username@hostname resolves its tenant through this value, so a profile that prefills one makes the tenant reachable without further input.

faker::internet::domainName()

2.11. admin_username

Username the profile prefills for the tenant administrator.

std::string("tenant_admin_") + std::to_string(idx)

2.12. admin_email

Email the profile prefills for the tenant administrator.

std::string("admin@") + faker::internet::domainName()

2.13. inherits_admin_password

Whether the tenant administrator starts with the password of the administrator who runs the provisioning. A demonstration profile sets it, so its journey asks for no password; a production profile does not.

faker::datatype::boolean()

2.14. force_password_change

Whether the tenant administrator must set a password of their own at first sign-in.

faker::datatype::boolean()

2.15. display_order

Order the cards are offered in. Lower numbers appear first.

faker::number::integer(0, 100)

3. SQL

3.1. Flags

3.2. Checks

expression
"code" <> ''
"name" <> ''

4. Insert trigger

4.1. Validations

column	validation_function
tenant_type	ores_iam_validate_tenant_type_fn

5. C++

5.1. Flags

5.2. Repository

5.3. Domain includes

#include <string>
#include <boost/uuid/uuid.hpp>

5.4. Entity includes

#include <string>

5.5. Conventions

5.6. Table display

column	header
code	Code
name	Name
audience	Audience
display_order	Order
modified_by	Modified By
version	Version

5.7. Paste blocks

6. See also

ores.iam — component group overview.
Task: Decide the seed profile contract — the accepted contract these rows implement.
Identity and Access Management — the tenant lifecycle, and the seed profile term.