Skip to main content
Version: 4.0 preview

Admin Configuration & Settings

Version
4.0 preview
Updated
View markdown

A functional description of every configuration option a shop admin can set in CBX — what each option is for and what it affects in the running application. This is usage-centric (a behavior specification to guide the refactor), not an implementation description; for how settings are stored/rendered, see the technical docs.

This is the first of the planned "all admin forms, described functionally" set. It covers the dedicated Settings area:

  1. Configuration — the global settings screen (one big multi-section form).
  2. Shop Data — the company identity used on invoices, quotes, emails and legal pages.
  3. Customer Fields — which address/customer fields appear (and are required) in each flow.

Settings that live on other entities (customer groups' B2B/B2C & discounts, currencies, tax classes, payment/shipping methods, geography, notifications, products/pages/questions/options) are noted where they interact with these screens but are documented as their own forms in later functional docs.

The three screens and what each one drives:


1. Configuration (the "Settings" screen)

A single screen of grouped sections. Most options are global toggles that change shop-wide behavior.

Verified against the live backend (3.4.1): the screen is the "Settings" menu item (heading "Settings"). The embedded managers (Currencies, Tax Classes, Salutations, Customer Groups) render as inline tables right inside it. WordPress URLs is correctly absent on Joomla (platform-specific). The final "Debugging" section is labelled "Analysis and Debugging" in the UI. (Shop Data is the separate "Store Information" menu item; see §2.)

1.1 WordPress URLs (WordPress integration only)

  • URL Segment for Cart Page / URL Segment for Account Page — the URL slugs used for the cart and customer-account pages when CBX runs inside WordPress. Affects the public URLs of those pages. (Irrelevant on Joomla, where menu items/routing supply the URLs.)

1.2 Languages

  • Shop Manager default language — the default working language of the back end / the fallback content language. Affects which translation is shown/edited by default.
  • Active Languages — the set of languages the shop offers. Affects which language tabs appear on translatable fields and which front-end languages customers can use; all translatable content (product names, questions, etc.) is maintained per active language.
  • Embedded managers (shown inline here for convenience): Currencies, Tax Classes, Salutations, Customer Groups — quick access to those entity lists from within Configuration (each is its own form; see their functional sections).

1.3 Checkout

Controls the checkout experience and defaults.

  • Continue-shopping listing (continue_listing_id) — the product listing a customer is sent to when they choose to keep shopping. Affects post-add-to-cart navigation.
  • Default Customer Group — the group assigned to new/guest customers. Affects pricing, tax mode (B2B/B2C), permitted features and discounts for anyone not otherwise grouped.
  • Default Country — the country assumed before a customer enters an address. Affects initial tax calculation, and delivery/payment option availability.
  • Secure Checkout — forces checkout over HTTPS. Affects whether the checkout redirects to a secure URL.
  • Disable Shipping — turns off the entire delivery/shipping step and shipping costs. Use for digital/service products. Affects whether delivery methods and address-shipping fields appear.
  • Show SKU in checkout record — includes option SKUs in the order's line items. Affects what the customer/admin sees in the order/cart record.
  • Preselect newsletter opt-in — whether the newsletter checkbox is checked by default at registration/checkout. Affects the default opt-in state.
  • Show delivery address fields by default — whether the separate delivery (shipping) address is expanded by default vs. "same as billing". Affects the address form's initial state.
  • Show recurring customer login — whether returning customers are shown a login prompt in the cart. Affects the cart UI for logged-out users.
  • Explicit agreement to terms — require an explicit "I accept the Terms" checkbox before ordering. Affects whether the T&C acceptance gate appears and is enforced.
  • Explicit agreement to refund policy — same, for the refund policy.

The two checkout defaults and what they steer before a customer identifies themselves:

1.4 Invoicing

  • Enable Invoicing — master switch for PDF invoice generation. Affects whether invoices exist at all.
  • Send invoice via email — automatically email the invoice to the customer. Affects post-payment email behavior.
  • Invoice Generationwhen an invoice is created: Automatic (on order), Automatic after Clearance (once payment confirmed), or After Manual Upload (admin uploads it). Affects the trigger point and whether invoices are system- or human-generated.
  • Invoice Number Prefix / Invoice Number Start — the prefix and starting number for the invoice numbering series. Affects the human-readable invoice numbers.

The three generation modes differ only in when and by whom the invoice comes into being:

1.5 Reviews

  • Reviews for Products — enable customer product reviews/ratings. Affects whether the review form/stars appear on product pages and listings.
  • Review notification email address — where new-review notifications are sent (for moderation). Affects who is alerted when a review is submitted.

1.6 Configurator

Controls the configurator page behavior and back-office display aids.

  • Show page tabs (page_nav_show_tabs) — show the per-page tab navigation in the configurator.
  • Show prev/next buttons (page_nav_show_buttons) — show step navigation buttons.
  • Block continuing if selections are missing — prevent moving to the next page / adding to cart while required answers are missing. Affects whether required-field gating is enforced during navigation.
  • Cart button on last page only — show the add-to-cart button only on the final configurator page. Affects where customers can complete the configuration.
  • Display conversion table — show a unit conversion helper. Affects an optional aid on the configurator.
  • Default Product Image — fallback image used when a product has none. Affects listings/detail pages for image-less products.
  • Show internal question names in backend / Show internal answer names in backend — display the admin-only internal names (instead of customer-facing titles) when building configurators. Affects back-office readability only.
  • Weight Unit — the unit label (e.g. kg/lb) shown for weights. Affects weight display and shipping weight presentation.

1.7 Block Headings

The customer-facing headings for the configurator side blocks (translatable):

  • Cart, Currencies, Navigation, Pricing, Visualization — the title shown above each respective block. Affects only the labels of those UI blocks.

1.8 Selection overview on configurator pages (the "price module")

Controls the live price/selection breakdown shown beside the configurator. Two parallel sets of toggles exist — one for Regular pricing and one for Recurring (subscription) pricing — plus shared options.

Shared:

  • Overview to show first — whether Regular or Recurring totals lead. Affects ordering for products that have both.
  • Show delivery options / Show payment options — include estimated delivery/payment lines in the overview. Affects what cost lines appear before checkout.
  • Show net in B2C mode — show net (ex-tax) prices even for consumer (B2C) customers. Affects whether B2C buyers see net alongside gross.

Per pricing type (Regular and Recurring), the same set of switches:

  • Show overview — master switch for that overview.
  • Show Prices — show prices at all (vs. just selections).
  • Show Configurator Pages — group the overview by configurator page.
  • Show questions — list individual questions.
  • Show question prices — show the price contribution of each question.
  • Expand Configurator Pages — how page groups are expanded: All, No Page, or Active page only. Affects the default expand/collapse state.
  • Show taxes — show tax lines in the overview.
  • Show cart button — show an add-to-cart button within the overview block.

Together these let an admin tune how detailed the live cost breakdown is for regular vs. recurring pricing.

1.9 IP Geolocation tracking

  • Enable geolocation — detect the customer's country by IP. Affects the pre-fill of country and initial tax/availability before an address is entered.
  • Geolocation Service TypeLocal (MaxMind GeoIP2 database file) or Webservice (MaxMind web API). Affects how lookups are performed.
  • MaxMind User ID / MaxMind License Key — credentials for the MaxMind service. Affects whether geolocation actually works.

1.10 License Key

  • License Key (product_key) — the CBX product/license key. Affects license validity status (drives a dashboard warning when missing/expired; not a functional kill-switch).
  • License Manager Satellites — the license-server endpoints used to validate the key. Affects where license checks are sent.

1.11 Custom Fields (labels)

CBX provides extra free-form "custom" fields on several entities; here the admin sets their display labels so they're meaningful. Setting a label is what makes the corresponding custom field usable/identifiable across the app:

  • Product custom fields 1–6 — labels for product-level custom fields.
  • Question custom fields 1–4 plus two translatable question custom fields (5–6) — labels for question-level custom fields.
  • Answer (assignment) custom fields 1–4 — labels for per-assignment custom fields.
  • Global answer (option) custom fields 1–6 — labels for option-level custom fields.

Effect: these labels appear wherever the custom field is shown/edited, and the fields can be referenced in rules, calculations and templates. (This is the app's lightweight "add your own attributes" mechanism.)

1.12 Maintenance

Housekeeping intervals for automatic cleanup.

  • Temporary user lifetime (usertime) — how long abandoned guest/temporary customer records are kept before deletion. Affects cleanup of incomplete sessions.
  • Unordered cart lifetime (unorderedtime) — how long un-ordered carts/positions are kept.
  • Cleanup interval (intervals) — how often the cleanup routine runs.
  • Label expiry (labelexpiry) — expiry handling for generated labels/temporary artifacts.

Effect: controls automatic pruning of stale data so the database doesn't accumulate abandoned sessions.

1.13 Connectors

  • Connectors — register custom integration/observer code modules (uploaded extension hooks) and their run order. Affects which custom server-side behaviors run (the main no-core-edit extensibility point for integrators).

1.14 Structured Data & Google Analytics

  • Use structured data — emit SEO structured data (e.g. Product/Review schema). Affects rich results / SEO markup on product pages.
  • Use structured data in… — which page types get structured data. Affects scope of the markup.
  • Use GA e-commerce — enable Google Analytics e-commerce tracking. Affects whether purchase events are sent to GA.
  • GA Property ID — the GA account/property to send to.
  • GA behavior for offline PSPs — how/when to record a "purchase" for payment methods without an instant confirmation (e.g. bank transfer). Affects when the conversion is counted.
  • Use GA Enhanced E-commerce — enable the richer GA enhanced-ecommerce data set (shown as a note if a prerequisite isn't met). Affects the depth of analytics data.

1.15 Debugging / Performance

Developer/operations switches:

  • Selection-call profiling (enable_performance_tracking) — log performance of configurator selection calls. Affects diagnostic logging.
  • Use minified JS / Use minified CSS — serve minified vs. source assets. Affects asset delivery (turn off for debugging front-end code).
  • Use assets cache buster — append cache-busting tokens to asset URLs. Affects browser caching of JS/CSS after updates.
  • RequireJS loading method — load the JS loader Immediately or on window onload. Affects front-end script load timing/compatibility.

2. Shop Data (Settings → Shop Data)

The company's identity record. It supplies placeholders used on invoices, quotations, emails and legal pages, and the contact details shown to customers.

  • Identity: Shop Name, Shop Website, Logo (used on invoices/PDFs).
  • Address: Address 1, Address 2, ZIP Code, City, Country, State.
  • Contact: Phone (Sales), Phone (Support), Email (Sales), Email (Support), Fax.
  • Banking (used on invoices / for bank-transfer payment): Bank Name, Bank Account Holder, Bank Account Number, Bank Code, BIC, IBAN.
  • Legal/registration: VAT IN, Commercial Register ID, Company Owner, Legal Venue.
  • Shop Description (translatable) — descriptive text usable in templates/communications.

Effect: changing any field updates what appears on generated documents (invoices/quotes), transactional emails, and customer-facing contact/legal information. (The Terms & Conditions and Refund Policy texts referenced at checkout are also maintained as part of the shop's legal content.)


3. Customer Fields (Settings → Customer/User Fields)

A matrix that decides, for every customer/address field, whether it is shown and whether it is required — separately in each of four flows:

  • Checkout — the standard buying flow.
  • Quotation — the request-a-quote flow.
  • Save Order — the save-cart-for-later flow.
  • Profile — the account profile-editing screen.

For each field there are therefore up to eight switches (show + require × the four contexts). Fields covered include the typical billing/delivery set: company, salutation, first/last name, address lines, ZIP, the country→state→county→city chain, VAT IN, phone, language, newsletter, etc.

Effect: this is how an admin tailors data collection per flow — e.g. require VAT IN only at checkout for B2B, hide phone in quotations, make company optional in the profile. It directly drives which fields render and which block submission when empty, in each respective form.


4. Notes for the refactor (functional observations)

  • B2B vs B2C is per customer group, not global. Tax mode (net/gross), feature permissions (see-prices, checkout, save, request/download/email quote) and volume discounts live on the Customer Group form, while Configuration only sets the default group and a few B2C display nuances (e.g. "show net in B2C"). A refactor should keep group-scoped commerce policy distinct from global display settings.
  • The "Selection overview" section is a large matrix of display toggles (regular × recurring × 8 switches). Functionally it's "how detailed is the live price breakdown" — a candidate for a single, cleaner presentation-config object rather than ~20 booleans.
  • Custom-field labels are the app's flexible-attributes mechanism. Six product, six question, four answer-assignment and six option custom fields exist; giving them labels activates them across rules, calculations and templates. A refactor might replace these fixed slots with proper typed custom attributes.
  • Several toggles are platform-specific (WordPress URLs) or operational (Maintenance intervals, Debugging) rather than merchandising — worth separating "store policy" from "platform/ops" settings.
  • Many settings gate whole features (Disable Shipping, Enable Invoicing, Reviews, Geolocation, GA). These are the feature flags a refactored architecture would likely model explicitly as capabilities/modules.