|

Store configuration

Configure the identity and shared settings used by the current Openfront Ecommerce application.

The current dashboard and storefront read the first Store record as shared application configuration. The operator page is available at /dashboard/platform/store.

Current Ecommerce source behaves as a single-store application. Although the schema can hold Store records and includes organization-related models elsewhere, products, carts, orders, regions, and other core aggregates do not form a complete organization-partitioned tenant graph.

Dashboard-managed settings

The Store settings screen currently reads and updates:

  • store name;
  • logo SVG;
  • logo color;
  • homepage title;
  • homepage description.

The server action sanitizes submitted logo SVG with SVGO before saving it. Updates require the backend permission used to manage sales-channel settings; hiding or showing the dashboard page is not the authorization boundary.

Additional Store fields

The Keystone Store model also contains:

  • defaultCurrencyCode;
  • related currencies;
  • payment, swap, and invite link templates;
  • JSON metadata;
  • a computed payment-provider configuration derived from installed providers and public Stripe or PayPal environment values.

Those fields are part of the GraphQL model, but they are not all editable in the current Store settings screen. Use the generated schema from the same revision before building another administrative client.

Currency and market configuration

The Store record is not the complete market model. Regions, countries, currencies, prices, tax rates, payment providers, and shipping options have their own records and workflows. Configure and test those relationships separately rather than assuming that changing defaultCurrencyCode converts prices or establishes a security boundary.

Operational checks

Before publishing configuration changes:

  1. verify the dashboard permission and API access path;
  2. preview branding on the built-in storefront at desktop and mobile sizes;
  3. confirm each region's currency, prices, countries, tax, payment, and shipping behavior;
  4. validate link templates against an allowlisted application origin;
  5. keep private provider credentials out of Store metadata and public environment variables;
  6. test rollback for a malformed logo or template.

For independent operator clients, use a bounded Store projection and an allowlisted update input. Do not expose unrestricted generic Store mutation access to a browser.

On this page