Skip to main content

Configure user attributes

Define the attributes your site users can have, such as a department or plan. This is done in the Console, in the target site.

Understand the attribute schema​

TaruviBase validates user attributes with JSON Schema Draft 2020-12. The root type must be object, properties defines the named attributes, and every entry in required must also exist in properties.

The backend accepts an attribute name only when it starts with a lowercase letter and contains lowercase letters, numbers, and underscores. Names that collide with user fields are reserved, including id, uuid, username, email, password, status fields such as is_active, relationship fields such as groups, and attributes itself. The Console may accept other names while you type, but saving rejects them.

TaruviBase also accepts attributes that aren't listed in properties, so the schema doesn't block other attributes. Access policies should check the specific attributes they rely on.

Only the hosted tenant sign-up form applies schema defaults automatically:

  • A required property with a default is filled from that default.
  • A required property without a default is shown to the new site user for input.

Console, SDK, and REST site-user create or update operations do not use that hosted-sign-up defaulting behavior. Existing users that have no value report the required property as missing until their attributes are updated.

For a nullable Console field, Allow Null Value produces a JSON Schema type union such as ["string", "null"]. If that field is also in required, the key must exist, and null can pass JSON Schema validation. User detail processing still treats null or an empty string as missing, so a required nullable value may validate yet continue to be reported as missing. Use a real value or remove the field from required when null is an acceptable completed state.

Create or update the definition​

  1. In TaruviBase Console, select the target site, open Authentication, and select User Attributes.
  2. Copy the current definition from JSON Source and keep it as the recovery copy for this change.
  3. Use Builder to add or edit fields, mark required fields, and configure their types and validation. Use JSON Source to review the resulting type, properties, and required values as one complete definition.
  4. Select Save Changes. Saving replaces the complete definition; omitted properties are not merged back from the previous version.
  5. Create or update a non-production site user, then confirm valid values save, wrong types are rejected, and required values are reported as missing. Test automatic defaults separately by signing up through the hosted sign-up page; creating a user in the Console, SDK, or REST API doesn't apply them the same way.

Change an attribute safely​

Treat a rename, type change, or removal as a data migration:

  1. Add the replacement property as optional while retaining the current one.
  2. Update application forms and access policies, then migrate or re-enter existing values.
  3. Verify users no longer report the replacement as missing. Make it required only after every existing user has a valid value or an approved default.
  4. Remove the old property in a later change after confirming no application or policy reads it.

For a direct type change, first convert every stored value or introduce a new property with the new type. Removing or changing the old definition first can make subsequent user updates fail validation.

If verification fails, recover by restoring the copied complete definition in JSON Source, selecting Save Changes, and restoring any values or dependent form and policy changes before retrying.

Use record-backed attribute mappings when a value must resolve from application data rather than be stored on the user.

For unresolved schema failures, see troubleshooting.

Attributes are separate from roles. Use roles, not attributes, to grant access.