Guides
Start typing to search…

Visibility & Targeting

This page explains who can see an Operation and which products appear, plus the pricing precedence when multiple offers exist.

Keep in mind

  • Visibility depends on status, dates, type (PUBLIC/PRIVATE), store scoping, catalog views, and locale.
  • Pricing uses a clear precedence: Operation price → Account → Tag → Public.

🎯 What “visibility” means

  • Operation visibility: whether an Operation is available for all Customer Users linked to attached Accounts. (It appears in /shop/operations). Accounts must be ACTIVE.
  • Product visibility inside an Operation: whether a specific product variant line is displayed and purchasable in the Operation detail view.
  • Pricing visibility: which price applies when multiple offers could match.

🔐 PUBLIC vs PRIVATE

  • PUBLIC: visible to all Accounts that meet store/date rules. Only Operators can set type=PUBLIC. Once set, the type cannot be changed.
  • PRIVATE: visible only to the attached Accounts. The attachment list is managed on the admin side.

Owner & edits

  • Only the creator/owner can modify an Operation.
  • Customer Users with the proper right may manage Operations they own; Operators can see any Operation.

🏪 Store scoping

  • Operations are linked to a Store (or a list of Stores when available). A Customer User only sees Operations for the current Store context.
  • If the Store does not match, the Operation does not appear in /shop/operations for that user.

🌐 Locales

  • Admin DTOs are multilingual (names and descriptions by locale).
  • Front DTOs are single-locale, filtered by an input locale. If a requested locale is missing, a fallback strategy may apply in the UI.

🗺️ Product visibility inside an Operation

A product line is visible only if the Account is entitled to the product via Catalog Views. The visibility status of a product inside an Operation follows the same rules as outside Operations.

Decision flow (summary)

  • Operation must be ACTIVE and within [startDate, endDate].
  • For PRIVATE, the current Account must be attached.
  • Store must match the user’s context.
  • Catalog Views must expose the product for the Account.
  • If all checks pass, the product appears in the Operation detail view.

The following diagram gives a high-level decision tree:

graph TD
    A[Start] --> B[Operation status ACTIVE<br>and now within dates]
    B -- Yes --> C{Type}
    B -- No  --> Z[Not visible]

    C -- PUBLIC --> D[Store matches]
    C -- PRIVATE --> P[Account attached]
    P -- Yes --> D
    P -- No  --> Z

    D -- Yes --> E[Catalog Views allow product]
    D -- No  --> Z

    E -- Yes --> OK[Line visible to buyer]
    E -- No  --> Z

Tip: the same Catalog View rules apply inside and outside Operations.

💶 Pricing precedence

When multiple offers could apply to a product, the precedence is:

  1. Operation price (if defined for the line).
  2. Account price.
  3. Tag price.
  4. Public price.
graph TD
    OP[Operation price] --> ACC[Account price]
    ACC --> TAG[Tag price]
    TAG --> PUB[Public price]
    NOTE[Use the first available<br>from top to bottom] --> OP

This ladder represents the fallback order. If an Operation price exists, it wins. If not, fall back to Account, then Tag, then Public.

🧩 Examples

Example 1 — PUBLIC campaign

  • Type: PUBLIC, Store=FR, Dates: Sep 1 → Oct 15.
  • A Customer User on Store FR sees the Operation in /shop/operations.
  • Inside the Operation, they see only the products exposed by their Catalog Views. Prices follow the precedence.

Example 2 — PRIVATE assortment

  • Type: PRIVATE with Accounts A and B attached.
  • Account C does not see the Operation at all.
  • Accounts A and B see it; each Account only sees lines that Catalog Views allow. If some lines are hidden by views, they won’t appear.

Example 3 — Mixed pricing

  • A line has no Operation price, but the Account has a specific offer. The Account price applies.
  • If neither Operation nor Account offers exist, check Tag; otherwise Public.

🔗 API quicklinks

Headers that matter for visibility

  • dj-client (OPERATOR or ACCOUNT) and dj-api-key are required on Admin endpoints. Store scoping uses dj-store / dj-store-view. Localized rendering uses optional locale. 

Admin — Operations (discover & scope)

  • GET /admin/operations — ADM-OPERATION-550 (List Operations (filters + sorting + locale + store scoping)).
    • Key rules you’ll rely on for visibility:
      • Store scoping: effective store is the dj-store header (or tenant default). ACCOUNT callers must be attached to that store, otherwise 403.
      • Locale: optional locale renders localized fields; must be allowed by the Operation’s store (fallback to store default).
      • Sorting supported on createdAt, startDate, endDate, name.
      • Filters include status, ids, name, type, startDateFrom/To, endDateFrom/To, locale, idType, and more (see auto-docs). 
  • GET /admin/operations/(operationId) — ADM-OPERATION-500 (Get Operation by ID).
    • Honors the same store scoping and access control rules (OPERATOR sees any; ACCOUNT must be the owner with the right to read). 

Admin — Targeting accounts (PRIVATE Operations)

These endpoints exist only for PRIVATE Operations. PUBLIC Operations do not expose the accounts list. 

Admin — Lines (context for what buyers may see)

  • GET /admin/operations/(operationId)/lines — ADM-OPERATION-551 (List Operation product variants with quantity constraints).
    • Useful when auditing what an Operation could surface to buyers (final buyer visibility still depends on Catalog Views on the Shop side). Supports filters like variantIds, variantName, minQuantity, maxQuantity, recommendedQuantity, plus sorting. 

Shop (read-only visibility, referenced here) 🔜 GET /shop/operations, GET /shop/operations/(id), GET /shop/operations/(id)/lines — buyers see only Operations that are eligible to them (status/date window, store scope, and for PRIVATE: account attached).

⸻

Tip: For a quick “who can see what?” check in Admin, combine:

  1. GET /admin/operations?type=PRIVATE&… to find the Operation (with store + locale context), then
  2. GET /admin/operations/(operationId)/accounts to inspect targeting, and
  3. GET /admin/operations/(operationId)/lines to audit product scope before testing in Shop.   
  • Buyer list: GET /shop/operations — returns only ACTIVE Operations within date and store scope, filtered by Account eligibility.
  • Buyer detail: GET /shop/operations/(id) and GET /shop/operations/(id)/lines — only lines visible via Catalog Views will appear.
  • Admin attach Accounts (PRIVATE): POST /admin/operations/(id)/accounts (+ GET/DELETE to list or remove).

✅ Checklist before you publish

  • Type is correct (PUBLIC or PRIVATE) — remember it cannot be changed later.
  • Store is set properly.
  • Localized name/description are filled.
  • For PRIVATE, Accounts are attached.
  • Catalog Views expose all intended products for those Accounts.
  • Optional: Operation prices configured where needed.

Updated 17 days ago