ws_customerspecialty/ws_customerspecialty

ws_customerspecialty

PrestaShop module (1.7 - 9.0 compatible) that adds a manageable "Specialty" field to customer accounts.

What it does

• Back office: clicking Configure on the module (Modules list) opens a "Settings" panel with the front-office display toggle, and a small tab-style nav that also links to a Specialties grid for maintaining the list of selectable specialty values (title per language, active/inactive, move up/down). Values are never hard-deleted from the UI, only deactivated, since they may already be linked to customers. The Specialties admin page is intentionally not registered in the back-office sidebar menu (id_parent => -1 on its tab, per this module's own conventions doc, section 18) — Configure is the only entry point, by design.
• Back office: the native "Add/Edit customer" page gets a required "Specialty" dropdown, and the native Customers grid gets a sortable/filterable "Specialty" column and a read-only specialty block on the customer view page.
• Front office: the registration / "my account" form gets a required "Specialty" dropdown, gated by a Configure toggle (WS_CUSTOMERSPECIALTY_FRONT_ENABLED) so it can be hidden from the storefront without affecting back-office management.
• The customer's specialty title is exposed as a {specialization} order confirmation mail variable (see below).

Data model

The customer's specialty is stored in the module's own tables — ws_customerspecialty, ws_customerspecialty_lang, and the pivot table ws_customerspecialty_customer — rather than by altering ps_customer or overriding core classes. This keeps the module safe to run unchanged across PrestaShop 1.7 through 9.0, since it never depends on core method internals that vary between major versions.

Order confirmation email integration

The module does not ship its own copy of the order confirmation mail template. Instead it exposes the customer's specialty as {specialization} via the actionGetExtraMailTemplateVars hook (the same pattern used in ws_giftdropdown). To show it in an order confirmation email, add the placeholder to the shop's own order_conf.html / order_conf.txt mail templates, e.g.:

Specialty: {specialization}

If the placeholder isn't present in the active theme's mail template, the variable is computed but simply has nothing to render into — this is a one-time manual integration step per shop/theme, not something the module can safely do on your behalf without overriding core mail templates.

Compatibility notes

• Command handlers are tagged for both tactician.handler (PS 1.7/8) and messenger.message_handler (PS 9), with matching __invoke()/handle() methods on each handler.
• No PrestaShop core class overrides, no ALTER TABLE on core tables.

Deliberate differences from the legacy pchcustomerfield module

• No drag-and-drop reordering of specialty values. The grid has "Move up" / "Move down" row actions instead (customerspecialty_move_up / _move_down routes swapping position with the adjacent row). This avoids depending on PrestaShop's core Grid position/drag-reorder plumbing.
• The active/inactive toggle uses a ToggleColumn + customerspecialty_toggle_active route. If that route ever misbehaves on a given PrestaShop version, active/inactive can always be changed via the Edit form as a fallback — it isn't the only way to flip the flag.

Confirmed working live on PrestaShop 9: create, edit, and active/inactive toggle on the Specialties grid. Three real bugs were found and fixed this way (not by static guessing) during initial rollout: a wrong FormDataProviderInterface namespace, a missing LinkRowAction route_param_field option, and FrameworkBundleAdminController::trans() taking (key, domain, params) instead of Module::trans()'s (key, params, domain). "Move up"/"Move down" reordering has not been explicitly click-tested yet — verify before relying on it.

Biggest assumption to verify

The storefront "Specialty" field on registration/account-edit relies on additionalCustomerFormFields already being called by core's own front-office CustomerFormatter (passing fields by reference). The legacy module achieved this only by overriding CustomerFormatter to add that hook call itself — an override intentionally not reproduced here (see the architecture note above). If the installed PrestaShop version's CustomerFormatter does not already call this hook natively, the storefront field will not appear (back office, grid, and mail-variable behavior are unaffected either way, since none of those depend on this hook). Verify on a real 1.7 and 9.0 install; if the hook isn't native, the fallback is to make the field mandatory server-side via a small first-party CustomerFormatter override scoped to only adding that one Hook::exec() call — much smaller and safer than the legacy module's full-method copy.