Category: Saclab

  • Coupon restricted by tag group

    User story
    As an admin
    I want to assign a coupon to a specific tag group (e.g “Collector’s items”, Runway, etc.)
    So that only products with that tag group can apply the discount

    Given the admin is on the coupon settings page (WordPress admin panel => marketing => coupons => add new/ or edit existing coupon)
    Then the admin can see there is an option to set the coupon to apply to one or multiple tag groups (similar to as the current function where the coupon can be applied to certain categories)

    Given the admin is on the coupon settings page
    When the admin selects to restrict the coupon to one or multiple tag group from the tag group dropdown
    And saves the coupon
    Then the coupon is only applied to the selected tag group(s)

    Scenario: Coupon does not apply to products outside the assigned tag group
    Given a user only has only one product in cart and this product does not belong to the coupon’s tag group
    When the user enters the coupon code
    Then the system should show an error message indicating the coupon is not valid for this product

    Scenario: Mixed cart with items inside and outside the coupon’s tag group
    Given a user has added a product belonging to the coupon’s tag group to the cart
    And the user has added a product that does not belong to the coupon’s tag group to the cart
    And a valid coupon is assigned to that tag group
    When the user enters the coupon code at checkout
    Then the discount is applied only to the product within the assigned tag group
    And the product outside the tag group receives no discount
    And the order total reflects the partial discount correctly

  • Automatic email confirmation

    Implement an automatic email confirmation for users who submit the contact form at http://saclab.com/contact/ . After submitting the form, the user receives an email confirming that Saclab has received the message and setting the expectation that Saclab will reply within 24 working hours.

    User story
    As a user who submits a message via the contact form
    I want to receive an immediate confirmation email
    So that I know my request was received and when I can expect a response

    Requirements

    • Trigger: send email immediately after a successful submission of the contact form.

    • Recipient: the email address the user entered.

    • Sender: Saclab’s standard no reply email.

    • Email content:

      • Subject: We have received your message

      • Body:

        • We have received your message.

        • We will come back to you within 24 working hours.

        • Disclaimer: this is a no-reply email, please don’t response here

    Scenario: Send automatic confirmation
    When the user submits the contact form with a valid email
    Then an automatic email is sent We have received your message

    Eng: https://us12.admin.mailchimp.com/templates/edit?id=10086996
    DE: https://us12.admin.mailchimp.com/templates/edit?id=10086998

    FRE:https://us12.admin.mailchimp.com/templates/edit?id=10086997

  • Story 16.1.1 Saclab Inventory – Archive, Orders & Attachment Compression

    1. General Info

    Background (short):

    The Saclab Inventory base is close to Airtable limits due to a large number of contacts, Bag Vault entries, old orders and big uncompressed attachments. We want to slim down the live base while keeping historical data accessible in an archive and reduce attachment usage without breaking workflows.

    Goals:

    • Keep all contacts archived in a single base, while removing old / low-value ones from the live inventory.

    • Free up records in the live Saclab Inventory base (contacts, Bag Vault, old orders).

    • Reduce attachment storage for the targeted images by ~50% through compression and archiving.

    • Let dev investigate options to reduce public API calls (no concrete solution defined in this story).

    2. Scope

    2.1 Contacts

    • Archive all contacts:

      • Create/archive base (e.g. “Saclab Inventory Archive”) that contains all contacts from the time of migration (full copy of the contact table).

    • Clean up live inventory:

      • From “Saclab Inventory” → delete contacts if:

        • Last modified older than 1.1.2025, and

        • Contact has no tag "seller", "buyer", "vip".

        • We don’t have data on user like:

          • existing order

          • existing submitted item

          • shipping address

          • billing address

          • phone#

            Bildschirmfoto 2025-12-01 um 11.43.14.png

      • Contacts removed from the live base must still exist in the archive base.

      • Ensure that if a deleted customer “wakes up” by their action, the contact gets created again

      • Target: at least 5k contacts removed from the live base.

      • link to Airtable View “clients to archive”: https://airtable.com/appYjRuQ4YEFTUwtb/tbld5UYfgjeNZpuOq/viwoY20x2OuTgslR8?blocks=hide

    2.2 Bag Vault

    • Move Bag Vault out of the live “Saclab Inventory” base into its own base (into a dedicated “Bag Vault” base).

    • Remove Bag Vault data from the live base.

    • Keep bag vault functional

    • Target: at least 4k records freed from the live base.

    2.3 Orders

    • From “Saclab Inventory” → move orders older than 01.01.2023 into the archive base.

    • Remove those orders from the live base.

    • Target: at least 2k orders freed (depending on actual data).

    2.4 Attachments & Compression

    • New accepted submissions:

      • If a submission is accepted, the compression function must be enabled and used before long-term storage of attachments.

    • Existing attachments:

      • Focus on existing SYB / submission images, especially where HubSpot does not archive deal attachments properly.

      • Process: archive originals → compressreupload compressed images to Saclab Inventory / archive and keep them correctly linked.

      • Target: reduce attachment storage usage for the targeted set by around 50% (≈ half the current usage), while still maintaining enough detail in the product shots.

    2.5 Public API Calls

    • Dev should investigate current public API usage (e.g. across automations) and note potential options to reduce call volume (batching, combining flows, etc.).

    • No specific implementation or target is required in this story; any optimisation work can be handled in follow-ups.

    3. Acceptance Criteria

    #

    Scenario (Given / When / Then)

    1

    All contacts archived
    Given the current contact data in “Saclab Inventory”
    When the initial migration is completed
    Then all contacts that exist at that time are present in the archive base (e.g. “Saclab Inventory Archive”) with their core fields.

    2

    Old non-tagged contacts removed from live base
    Given a contact in “Saclab Inventory” with … (Link to View with filter settings)

    • Last modified older than 1.1.2025

    • no tag "seller", "buyer" or "vip"

    • no linked order

    • no submitted item

    • no billing / shipping address / phone#

    When the archive / clean-up process is run
    Then this contact no longer exists in the live “Saclab Inventory” base
    And the contact still exists in the archive base.
    And if the customer reappears, it gets recreated in Airtable

    3

    Important contacts remain in live base
    Given a contact in “Saclab Inventory” with tag "seller" or "buyer" or "vip", a linked order or a submitted item or existing address/phone#, or last modified after 1.1.2025
    When the archive / clean-up process is run
    Then this contact remains in the live base (not removed).

    4

    Bag Vault moved out of live base
    Given a Bag Vault table in “Saclab Inventory”
    When the Bag Vault migration is completed
    Then Bag Vault data is available in its new base
    And Bag Vault records are no longer counted as records in the live “Saclab Inventory” base
    And the bag vault is still fully functional

    5

    Orders older than 01.01.2023 archived

    Given orders in “Saclab Inventory” with order date before 01.01.2023

    When the order archive process is run

    Then these orders no longer exist in the live base

    And they exist in the archive base.

    6

    Compression for accepted submissions

    Given a submission reaches status “accepted”

    When its attachments are stored in their final location

    Then the compression function is applied to those attachments

    And only the compressed versions are kept as the long-term copies
    And the original full size images are stored on box inside a folder named DealID_SellerName_SellerEMail_BagName https://app.box.com/folder/351924093564

    7

    Existing attachments archived, compressed & reuploaded

    Given existing submission-related attachments (mainly SYB images) in HubSpot / historical records

    When the attachment archival job is run

    Then the original attachments are archived on box inside a folder named DealID_SellerName_SellerEMail_BagName https://app.box.com/folder/351924093564

    And compressed versions are reuploaded and correctly linked to the corresponding records in Saclab Inventory / archive

    And total attachment usage for this targeted set is reduced by around 50% without noticeable loss of essential image detail.

    8

    API investigation documented

    Given automations using public APIs (Airtable, HubSpot, etc.)

    When dev work for this story is completed

    Then there is a short dev note (e.g. in the ticket or on this page) summarising current public API usage patterns and potential options to reduce call volume (if any)

    And any actual implementation of API optimisations is explicitly marked as out of scope / follow-up.

    9

    No negative impact on daily work

    Given sales and ops use “Saclab Inventory” for their daily work

    When the archive and compression changes are live

    Then active contacts, orders and relevant attachments remain available in the live base

    And no actively used records are reported as missing due to the archiving rules.

  • Epic 16.1 Saclab Inventory – Archive & Attachment Compression

    General info

    General description

    Epic ticket:

    User stories

    Visual design

    Desktop:

    Mobile:

  • Release Notes – Saclab General – 04.11 Release (2025) – Nov 19 12:56

    How to use this page:

    Find your selected Jira issues in the table below. Select the expand to use them as your source of truth to write release notes.

    Release

    https://cheitgroup.atlassian.net/projects/SCLB/versions/11508

    Date

    Version

    04.11 Release (2025)

    Description

    Contributors

    Alexander BöhringerDima Savchenko (WP)

    Issues in this release

    Before you share the page, review the contents of each Jira issue and remove any sensitive data.

    Issue

    Summary

    Issue Type


    SCLB-1667

    Partner crawler reactivates sold items when sold in our shop

    Bug


    SCLB-1417

    CLONE – [BUG]SYB submission is missing photos

    CB

    Summary

    New Features

    Improvements to existing features

    Bug fixes

  • Story 11.2 Newsletter and Contact Form Tracking

    General info

    Implement the standardized dataLayer events for all form submits as described in the attached documentation (PDF).

    This includes newsletter sign-ups, DOI confirmation pageviews, and contact form submits.

    The goal is to unify form tracking across all pages, replacing current CSS/URL-based workarounds.

    User story

    As a marketing analyst,

    I want all newsletter and contact forms to trigger standardized dataLayer events,

    So that tracking and analytics can be unified and automated in GTM and GA4.

    Documentation:

    saclab.com dataLayer-Eve…

    Acceptance criteria

    #

    Given

    When

    Then

    01

    A user successfully submits any newsletter form

    The submission completes

    A dataLayer event named saclab_newsletter_sign_up is fired with form name, form ID, and user email details (as per documentation).

    02

    A user lands on the newsletter DOI confirmation page

    The page loads

    A dataLayer event named saclab_newsletter_confirmation is fired.

    03

    A user successfully submits the contact form

    The submission completes

    A dataLayer event named saclab_contact_form_submit is fired with form name, form ID, and available user data (email, name, phone).

  • Story 1.4.2 Region & Language Auto-Detection (v2)

    General info

    This functionality defines which regional/language version of the SACLAB website should be shown to a user on their first visit. The system automatically detects the user’s country, browser language, forms the location and version, and may display a popup offering the user to switch to the recommended version.

    When a user visits the website for the first time, the system automatically detects the country by IP, the browser language, determines the location, and calculates the site version. After that, the system forms a new URL based on these values. If the version changes, a popup may be shown offering the user to switch to the recommended version.

    Location rules:

    • If country = “US” or “HK” → location = “US” or “HK”

    • If country is part of the EU → location = “EU”

    • If country is not part of the EU → location = “Global”

    Version rules:

    • If country = “US” or “HK” → version = “US” or “HK”

    • If language = “en”, “de”, or “fr” → version = “en”, “de”, or “fr”

    • Else → version = “en”

    URL rules:

    User story

    As a first-time visitor of the website

    I want the system to automatically determine my location and preferred language and form the recommended version of the site

    So that I can access the most relevant regional and language version of SACLAB.

    Acceptance Criteria

    Acceptance criteria

    01

    Scenario: Detect country and language
    Given the user visits the site for the first time
    When the system loads
    Then the system must detect the user’s country by IP and browser language

    02

    Scenario: Determine location for US/HK
    Given the detected country
    When the country is “US” or “HK”
    Then the location must be “US” or “HK” accordingly

    03

    Scenario: Determine EU location
    Given the detected country
    When the country is part of the EU
    Then the location must be “EU”

    04

    Scenario: Determine Global location
    Given the detected country
    When the country is not in the EU and not US/HK
    Then the location must be “Global”

    05

    Scenario: Determine version by country
    Given the detected country,
    When the country is “US” or “HK”
    Then the version must be “US” or “HK”

    06

    Scenario: Determine version by language
    Given the detected language
    When the language is “en”, “de”, or “fr”
    Then the version must match the detected language

    07

    Scenario: Default version
    Given the user’s language is not supported
    When the version is determined
    Then the version must be set to “en”

    08

    Scenario: Form new URL
    Given the current URL has no version prefix
    When the system determines the version
    Then the new URL must be formed as old URL + version

    09

    Scenario: Do not show popup for US/HK
    Given the existing version is “US” or “HK”
    When the system compares the old and new versions
    Then the popup must not be shown

    10

    Scenario: Do not show popup if URL unchanged
    Given the old URL equals the new URL
    When the comparison is done
    Then the popup must not be shown

    11

    Scenario: Show popup when version changes
    Given the old URL differs from the new URL
    When the system forms a new version
    Then a popup must appear offering the user to switch to the recommended version

    12

    Given: User is accessing saclab.com/de/ (or EN or FR)
    When: User’s IP address is US
    Then: the system prompts the user to go to saclab.com/us/
    A popup in German is shown

    Scenario: Version Mismatch Based on Location and Language

    Given:

    • The user is accessing a site version that does not match the version recommended for their detected location
      (for example, accessing any regional or language version different from the one mapped to their IP location)

    • And the user’s IP address maps to a specific region (e.g., US, HK)

    When:

    • The system evaluates the user’s browser language

    Then:

    • If the browser language matches a supported language version (e.g., German → /de/, French → /fr/),
      the popup must appear in that language, suggesting a switch to the version appropriate for the user’s location

    • Otherwise (if the browser language does not match or cannot be detected),
      the popup must appear in English, suggesting a switch to the version appropriate for the user’s location

    image-20251110-091730.png

    12.1

    Example to scenario 12:

    Given: User is accessing http://saclab.com/de/
    When: User’s IP address is US

    If User’s language is detected as German
    Then: the system shows a popup in German prompting the user to go to http://saclab.com/us/

    Else if user’s language is NOT german

    Then: the system shows a popup in English prompting the user to go to http://saclab.com/us/

    Given: User is accessing http://saclab.com/fr/
    When: User’s IP address is HK

    If User’s language is detected as French
    Then: the system shows a popup in French prompting the user to go to http://saclab.com/hk/

    Else if user’s language is NOT French

    Then: the system shows a popup in English prompting the user to go to http://saclab.com/hk/

    13

    Given: User is accessing saclab.com/de/
    When: The user’s IP address is HK
    Then: the system prompts the user to go to saclab.com/hk/
    A popup in German is shown

    If User’s language is detected as German
    Then: the system shows a popup in German prompting the user to go to http://saclab.com/hk/

    Else if user’s language is NOT german

    Then: the system shows a popup in English prompting the user to go to saclab.com/hk/

    image-20251110-091855.png

    14

    Given: User is accessing saclab.com/us/ (or HK)
    When: site version is the same US (or HK)
    Then: the system does not suggest a redirect

    15

    Scenario: User Accessing a Different Language Version Than Their Browser Language

    Given: User is accessing saclab.com/fr/ (or EN or DE)
    When: The user’s IP address belongs to a EU and browser language DE
    Then: the system prompts the user to go to saclab.com/de/ (EU location)
    A popup in German is shown

    Given:

    • The user is accessing a site version that does not match their detected browser language
      (for example, they are on saclab.com/fr/ while their browser’s language is German)

    • And the user’s browser language is one of the supported language (e.g English, french or German)

    When:

    • The system detects the user’s browser language

    Then:

    • The system must prompt the user to switch to the version that matches their browser language

    • The popup must be displayed in the user’s detected browser language

    image-20251110-092828.png

    15.1

    Example Scenario 15

    Given: User is accessing http://saclab.com/fr/
    When: The user’s IP address belongs to a EU and browser language GERMAN
    Then: the system shows a pop-up in GERMAN prompts the user to go to http://saclab.com/de/

    Given: User is accessing http://saclab.com/fr/
    When: The user’s IP address belongs to a EU and browser language is english
    Then: the system shows a pop-up in ENGLISH prompts the user to go to http://saclab.com/

    Given: User is accessing http://saclab.com/fr/
    When: The user’s IP address belongs to a EU and browser language is French
    Then: continues to saclab.com/fr/ without any popup

    Given: User is accessing http://saclab.com/fr/
    When: The user’s IP address belongs to a EU and browser language is none of the supported language, for example Dutch
    Then: the system shows a pop-up in ENGLISH prompts the user to go to http://saclab.com/

    Given: User is accessing http://saclab.com/fr/
    When: The user’s IP address belongs to a non-EU and browser language is none of the supported language, for example Dutch
    Then: the system shows a pop-up in ENGLISH prompts the user to go to http://saclab.com/

    Given: User is accessing http://saclab.com/fr/
    When: The user’s IP address belongs to a non-EU and browser language is German
    Then: the system shows a pop-up in German prompts the user to go to http://saclab.com/de/

    Given: User is accessing http://saclab.com/fr/
    When: The user’s IP address belongs to a non-EU and browser language is FRENCH
    Then: continues to http://saclab.com/fr / without any popup

    16

    Given: User is accessing saclab.com/ (or FR or DE)
    When: The user’s IP address belongs to a non EU and browser language FR

    Then: the system prompts the user to go to saclab.com/fr/ (Global location)
    A popup in English is shown
    Title: “We’ve detected a better version for you”
    Subtitle: “We’ve found a version of our site that may be more relevant to your location or language.
    Would you like to switch to this version?”
    Redirect button: “Yes, take me there”
    Cancel button: “Stay here“
    The text is edited in the admin panel.

    image-20251110-093057.png