v0.3.0

• @lowdefy/modules-mongodb-plugins: ### Minor Changes

• #34 cbe3d6d Thanks @JohannMoller! - Restructure the companies module's data shape so registration / contact / address / attribute fields move into opt-in section sub-objects instead of being hardcoded at the document root. Consumers wire any combination of shipped field-presets — or their own block arrays — through new fields.{registration,contact,address,attributes} slot vars.

  Companies module — breaking shape changes:

  • Document root: trading_name / registered_name / registration_number / vat_number / website removed from the document root. Display name is now name; the registration trio plus website / phone / email move under registration.* / address.* / contact.* sub-objects.
  • name_field default: flipped from trading_name to name. All read-side requests build display_name via $getField so the rename propagates without per-request edits. Apps whose collections genuinely use a different display field must set name_field explicitly.
  • New fields.X vars: fields.contact, fields.address, fields.registration (alongside existing fields.attributes). Each defaults to [] — apps that don't opt in render an empty section. Block ids inside each array must be prefixed with the section name (contact., address., etc.) so they bind to the matching state subtree.
  • Field-preset library: field-presets/{contact-default,address-text,address-places,registration-sa}.yaml ship under the module. address-places.yaml depends on a custom PlacesAutocomplete plugin that does not yet exist in this monorepo; consumers wiring it must supply the plugin themselves.
  • Excel export: fixed columns trimmed to the universal core (id, name, description, updated_at, created_at). Section columns move through the existing components.download_columns slot.

  Migration (data):

  trading_name              →  name
  registered_name           →  registration.registered_name
  registration_number       →  registration.registration_number
  vat_number                →  registration.vat_number
  website                   →  contact.website
  contact.primary_email     →  contact.primary_email   (unchanged)
  contact.primary_phone     →  contact.primary_phone   (unchanged)
  address.* (already nested)→  address.*               (unchanged)
  

  Run a one-off migration on the companies collection; update-company's $set does not unset the legacy keys, so old fields will coexist with the new shape until explicitly removed.

  Migration (apps wiring the module):

  Add fields.{contact,address,registration} to your module-entry vars to opt into the sections. Either _ref the shipped presets or supply your own block arrays:

  fields:
    contact:
      _ref: ../../modules/companies/field-presets/contact-default.yaml
    address:
      _ref: ../../modules/companies/field-presets/address-text.yaml
    registration:
      _ref: ../../modules/companies/field-presets/registration-sa.yaml

  _ref paths resolve from the consuming app's config root.

  Contacts module:

  get_contact_companies now projects name + company_id instead of the legacy trading_name. The contact view's linked-companies tile renders the new shape. Apps that rely on the old projection must update any custom consumers reading from this request.

  Plugins (SmartDescriptions):

  The company field-type detector signature changes from "trading_name" in value to ("name" in value && "company_id" in value), and the renderer reads value.name instead of value.trading_name. Any custom value shape that used to match on trading_name alone will now fall through to default rendering — pass company_id (or use the updated get_contact_companies projection) to keep the company link + icon.

• @lowdefy/modules-mongodb-companies: ### Minor Changes

• #34 cbe3d6d Thanks @JohannMoller! - Restructure the companies module's data shape so registration / contact / address / attribute fields move into opt-in section sub-objects instead of being hardcoded at the document root. Consumers wire any combination of shipped field-presets — or their own block arrays — through new fields.{registration,contact,address,attributes} slot vars.

  Companies module — breaking shape changes:

  • Document root: trading_name / registered_name / registration_number / vat_number / website removed from the document root. Display name is now name; the registration trio plus website / phone / email move under registration.* / address.* / contact.* sub-objects.
  • name_field default: flipped from trading_name to name. All read-side requests build display_name via $getField so the rename propagates without per-request edits. Apps whose collections genuinely use a different display field must set name_field explicitly.
  • New fields.X vars: fields.contact, fields.address, fields.registration (alongside existing fields.attributes). Each defaults to [] — apps that don't opt in render an empty section. Block ids inside each array must be prefixed with the section name (contact., address., etc.) so they bind to the matching state subtree.
  • Field-preset library: field-presets/{contact-default,address-text,address-places,registration-sa}.yaml ship under the module. address-places.yaml depends on a custom PlacesAutocomplete plugin that does not yet exist in this monorepo; consumers wiring it must supply the plugin themselves.
  • Excel export: fixed columns trimmed to the universal core (id, name, description, updated_at, created_at). Section columns move through the existing components.download_columns slot.

  Migration (data):

  trading_name              →  name
  registered_name           →  registration.registered_name
  registration_number       →  registration.registration_number
  vat_number                →  registration.vat_number
  website                   →  contact.website
  contact.primary_email     →  contact.primary_email   (unchanged)
  contact.primary_phone     →  contact.primary_phone   (unchanged)
  address.* (already nested)→  address.*               (unchanged)
  

  Run a one-off migration on the companies collection; update-company's $set does not unset the legacy keys, so old fields will coexist with the new shape until explicitly removed.

  Migration (apps wiring the module):

  Add fields.{contact,address,registration} to your module-entry vars to opt into the sections. Either _ref the shipped presets or supply your own block arrays:

  fields:
    contact:
      _ref: ../../modules/companies/field-presets/contact-default.yaml
    address:
      _ref: ../../modules/companies/field-presets/address-text.yaml
    registration:
      _ref: ../../modules/companies/field-presets/registration-sa.yaml

  _ref paths resolve from the consuming app's config root.

  Contacts module:

  get_contact_companies now projects name + company_id instead of the legacy trading_name. The contact view's linked-companies tile renders the new shape. Apps that rely on the old projection must update any custom consumers reading from this request.

  Plugins (SmartDescriptions):

  The company field-type detector signature changes from "trading_name" in value to ("name" in value && "company_id" in value), and the renderer reads value.name instead of value.trading_name. Any custom value shape that used to match on trading_name alone will now fall through to default rendering — pass company_id (or use the updated get_contact_companies projection) to keep the company link + icon.

• @lowdefy/modules-mongodb-contacts: ### Minor Changes

• #34 cbe3d6d Thanks @JohannMoller! - Restructure the companies module's data shape so registration / contact / address / attribute fields move into opt-in section sub-objects instead of being hardcoded at the document root. Consumers wire any combination of shipped field-presets — or their own block arrays — through new fields.{registration,contact,address,attributes} slot vars.

  Companies module — breaking shape changes:

  • Document root: trading_name / registered_name / registration_number / vat_number / website removed from the document root. Display name is now name; the registration trio plus website / phone / email move under registration.* / address.* / contact.* sub-objects.
  • name_field default: flipped from trading_name to name. All read-side requests build display_name via $getField so the rename propagates without per-request edits. Apps whose collections genuinely use a different display field must set name_field explicitly.
  • New fields.X vars: fields.contact, fields.address, fields.registration (alongside existing fields.attributes). Each defaults to [] — apps that don't opt in render an empty section. Block ids inside each array must be prefixed with the section name (contact., address., etc.) so they bind to the matching state subtree.
  • Field-preset library: field-presets/{contact-default,address-text,address-places,registration-sa}.yaml ship under the module. address-places.yaml depends on a custom PlacesAutocomplete plugin that does not yet exist in this monorepo; consumers wiring it must supply the plugin themselves.
  • Excel export: fixed columns trimmed to the universal core (id, name, description, updated_at, created_at). Section columns move through the existing components.download_columns slot.

  Migration (data):

  trading_name              →  name
  registered_name           →  registration.registered_name
  registration_number       →  registration.registration_number
  vat_number                →  registration.vat_number
  website                   →  contact.website
  contact.primary_email     →  contact.primary_email   (unchanged)
  contact.primary_phone     →  contact.primary_phone   (unchanged)
  address.* (already nested)→  address.*               (unchanged)
  

  Run a one-off migration on the companies collection; update-company's $set does not unset the legacy keys, so old fields will coexist with the new shape until explicitly removed.

  Migration (apps wiring the module):

  Add fields.{contact,address,registration} to your module-entry vars to opt into the sections. Either _ref the shipped presets or supply your own block arrays:

  fields:
    contact:
      _ref: ../../modules/companies/field-presets/contact-default.yaml
    address:
      _ref: ../../modules/companies/field-presets/address-text.yaml
    registration:
      _ref: ../../modules/companies/field-presets/registration-sa.yaml

  _ref paths resolve from the consuming app's config root.

  Contacts module:

  get_contact_companies now projects name + company_id instead of the legacy trading_name. The contact view's linked-companies tile renders the new shape. Apps that rely on the old projection must update any custom consumers reading from this request.

  Plugins (SmartDescriptions):

  The company field-type detector signature changes from "trading_name" in value to ("name" in value && "company_id" in value), and the renderer reads value.name instead of value.trading_name. Any custom value shape that used to match on trading_name alone will now fall through to default rendering — pass company_id (or use the updated get_contact_companies projection) to keep the company link + icon.

• @lowdefy/modules-mongodb-layout: ### Minor Changes

• #41 5d50cad Thanks @JohannMoller! - Layout module fixes — let the page block own logo and chrome styling instead of overriding it from this module.

  Logo: read from public/ folder by convention. Stop forcing properties.logo.src from _module.var: logo.primary_light in page.yaml; with no logo.src set, the page block falls back to ${basePath}/logo-{light,dark}-theme.png (and logo-square-{light,dark}-theme.png for mobile) and auto-swaps with dark mode at runtime via getDarkMode(). The previous wiring silently bypassed that swap whenever a consumer set the var.

  Header / sider style overrides removed. The .header divider is now owned by the page block via lowdefy/lowdefy#2158; .sider was already shipped as a default by PageSiderMenu and PageSidebarLayout. Consumers must be on a Lowdefy version that includes the upstream .header styling fix to get a header divider — older Lowdefy versions will render no header divider after this module bump (the previous override was visually broken on those versions anyway, drawing a partial line under the menu only).

  Bug fix as a side effect: logo.style now actually applies. The previous wiring went through properties.logo.style, which the v5 page-block schema rejects (logo has additionalProperties: false and no style property). Routing the override through the .logo cssKey makes the var functional on v5 for the first time.

  Removed vars (breaking for apps that set them):

  • logo.primary_light — page-header logo on light theme.
  • logo.icon — square mobile-header logo.

  Lowdefy's manifest validation does not reject unknown vars, so apps still passing these values won't error — but the values will be silently ignored and the public-folder logos will render instead.

  Migration:

  1. Drop logo.primary_light and logo.icon from your layout module-entry vars.
  2. Place the corresponding image files under the app's public/ folder using the conventional names:
     • public/logo-light-theme.png — desktop logo on light theme.
     • public/logo-dark-theme.png — desktop logo on dark theme.
     • public/logo-square-light-theme.png — mobile (square) logo on light theme.
     • public/logo-square-dark-theme.png — mobile (square) logo on dark theme.

  logo.primary_dark (auth-page cover) and logo.primary (auth-page brand panel / mobile auth view) are unchanged. logo.style is unchanged but is now wired through the page block's .logo cssKey instead of properties.logo.style, matching the v5 styling API.