Repository navigation
Conversation
Ports the content domain's one Robot UI scenario. The back-office half -- create a page with translated placeholders and publish it -- is already covered by backoffice/cms/cms-page-management.cy.ts, so the delta is the part no Cypress spec asserts: that the published page is reachable under its localized storefront url and renders its title. cms-page-search-dms.cy.ts reaches a page through the search suggestions, which is a different journey and only runs with dynamic store enabled, so CmsContentPage gains a url-based visit rather than reusing that helper. Publishing is not enough on its own -- the page stays invisible to the storefront until the queue drains, hence shouldTriggerPublishAndSync. Fixtures are per repository, so all five carry the pair. Typecheck, eslint and prettier are clean locally; the run verdict is still outstanding.
The Robot scenario this replaces sets a distinct title and content placeholder and asserts both storefront elements. The first pass only covered the title, so deactivating Robot against it would have left the content placeholder unasserted anywhere. CmsPlaceholderEditPage gains updateTitleAndContent; the existing update path is unchanged, both now share one localized-fill helper. The content placeholder lives on a second tab whose fields stay inert until it is opened, which is why the tab is clicked first. Test titles follow this repository's subject-and-should convention rather than Given/When/Then, which nothing here uses.
The existing ACL spec proves a role reaches only what it was allowed. Two things it never asserted: that a deny rule beats a wildcard allow on the same user, and that a deactivated user cannot log in at all. The deny user holds two roles, one allowing every bundle, so a denial can only come from the deny rule. A deactivated user is status "blocked" in spy_user, which is what the back office writes when an administrator deactivates one.
Replaces the Robot navigation smoke test. Rather than clicking each node by index, the spec reads every navigable href out of the side menu and visits it. The collapsed second level is already in the DOM, so nothing has to be expanded first, and there is no click-order fragility to inherit. A node counts as opened when the back-office chrome renders, which is what the Robot version was really asserting when it waited for the user-navigation toggler.
The storefront half of this journey was already covered; what was missing is the cross-surface direction, where an administrator edits a customer in the back office and the customer sees it on their own profile page. Needed a back-office customer edit page object and an edit action on the customer index, which previously only knew how to remove multi-factor authentication.
Two gaps in the customer account area. Nothing asserted that a deleted address is actually gone, only that adding one reports success. And the overview spec checked four sidebar destinations by name, leaving whatever else the navigation offers unvisited. The crawl reads the links out of the navigation rather than naming destinations, so a repository with more account pages gets them covered for free. The link container differs per repository, so that selector stays in the repository while the path extraction is shared. Deleting walks up from the address entry to the nearest ancestor holding exactly one delete form. That finds the card in every repository without naming any of them, and cannot reach a neighbouring address's button.
Completes the account-area journey: an administrator adds an address through the back office and the customer sees it in their own address list. The create form fills only the fields it marks NotBlank, plus salutation, which the storefront prints. Country is selected by name rather than by key, because the field holds a country id that differs per environment.
…ce named The crawl asserted that every link in the customer account navigation opens. In suite it does not: the navigation renders a Shopping Lists entry that a plain customer cannot open, and the application answers "Only company users are allowed to access this page". That is the application's own behaviour, not a broken page, and the Robot test never claimed otherwise -- it visited a fixed list of account pages. So the assertion is now that list. The overview spec already covered five of those destinations; wishlist and returns are what it was missing. The per-repository navigation selectors added for the crawl go with it, since nothing reads them now.
Ports the back-office half of the Robot glossary test: create a translation, see it listed, edit it, and read the change back off the form. The storefront half is deliberately not ported. It edited a translation key the storefront actually renders, then undid it in a teardown. Cypress shards pack nondeterministically, so any spec rendering that page in a neighbouring shard would race with the edit. A test that has to be the only thing running is not worth the coverage. Each run uses a key of its own, so nothing shared is touched. Every locale textarea the form renders is filled rather than naming locales, because the collection is NotBlank and which locales exist depends on the store.
There was no way for a Cypress spec to act as a customer it has no password for. That blocked three Robot rows, all of which use agent impersonation as the vehicle rather than the subject: the agent-assist row and both company rows, where the company user is created through a form and nothing knows its password. Driving the control bar is not optional. The visible search field carries no name; the form submits a hidden _switch_user input that the autocomplete fills when a suggestion is chosen, so the suggestion has to be clicked. The scenario waits on the autocomplete response rather than the list appearing, which removes the race the Robot version papered over with retries. Only the older agent-control-bar component exists in this package version, so the two UI generations the Robot keyword branches on collapse to one, and the injected JavaScript click it needed for the newer one is not required.
Completes the agent-assist journey. Reuses the existing add-to-cart and checkout scenarios unchanged, which is the point: acting through an impersonated session should be indistinguishable from the customer acting for themselves, and nothing in the checkout path needed a special case for it.
Two new storefront page objects, business unit create and company user create, and the spec that drives them: an administrator builds a business unit and a company user inside it, then the new user is checked against its own role. Impersonation is what makes the second half possible at all. A company user created through a form has no password anyone knows, so the agent switches into its session instead. Its role grants company users and nothing else, so the company-role page has to refuse it. The company, its roles and the agent come from fixtures; the business unit and the company user are the part driven through the storefront, which is what the row is about. Business units need no permission of their own, so only the role and user permissions are seeded.
Multi-shipment checkout was already covered, but only up to the order being placed. What the Robot test actually ended on was never checked: that three items sent to three addresses become three shipments. ShipmentGui renders one order-item table per shipment on the order detail page, so counting them is the shipment count. The order is looked up by its own reference rather than taking the first row of the sales table, because the shards run concurrently and the newest order is not reliably this test's. Named per-shipment shipping methods are not asserted. The radio ids carry the method's position, not its name, and which method sits at which position depends on the store, so an index-based assertion would be checking the wrong thing.
My assertion was wrong and CI caught it. Ending assistance does not bounce the agent to the login form: the agent is still authenticated, just no longer a customer, so the account area answers 500. The merchant-portal impersonation spec already encodes that same behaviour. Asserting the 500 would be asserting an incident rather than an intention. The control bar shows the customer search only when nobody is being assisted and the exit link only while somebody is, so the swap between them is what actually proves the session was handed back. The three tests that matter all passed: impersonation itself, the customer's own profile data, and placing an order on their behalf.
Two failures from the same root cause: taking a widget at face value instead of reading what it renders. The business-unit options are labelled "<name> (ID: <id>)", so selecting by the bare name could never match. The Robot keyword said "Select From List By Label Contains" and that Contains was the tell I walked past. The page object now reads the id off the option carrying the name and selects by that. The glossary edit test opened whichever row the table happened to be showing, which is how it read back a real German cart translation instead of its own. It passed once and failed twice on retry, so it was never reliably green. Both lookups now assert the key is in the table before taking a row, which is what the shared find() helper offers and I had not used.
The Arrange asserted the warehouse-user checkbox was unchecked, but the Act
persists the flag. With retries.runMode 2 a transient failure after the save
made every later attempt fail on that precondition, so the test could never
recover. The `.check()` in the Act is idempotent, so the precondition only cost
retry protection.
The Assert used `.contains(...).should('have.length', 1)`. `.contains()` yields
the first match only, so the length assertion could not fail and the
"exactly one action" claim was never verified. Assert on the row's text instead,
matching what BackofficePage.find already does.
The state wait moves into SalesDetailPage. In the spec it duplicated the retry
budget and OMS command list triggerOms owns, and it reloaded the raw cy.url(),
which drops the basic-auth credentials SE envs need. Both call sites now share
the constants and the url helper, and the repository selector no longer leaks
through a page-object pass-through.
The b2c and b2c-mp dynamic fixtures called haveFullOrder, haveShipmentType and haveShipmentMethod. None of the three is reachable in those repositories: haveFullOrder ships in spryker-feature/self-service-portal, which is not installed there, and the two shipment helpers are registered only in suite's DynamicFixture suite. Fixtures load from a global before() keyed by spec path regardless of skip, so the files alone broke every test in the spec on both demoshop lanes while the suite-only focused run stayed green. The demoshop fixtures now build the two back-office users and nothing else, and the order-backed OMS walk is gated to suite. The warehouse-user flag test, which needs no order, still runs on all three repositories.
getOrderItemStateSelector matched `td.state-history a` anywhere on the order detail page. The Robot source it ports scopes the same lookup to one shipment table and one SKU row before reading the state link, and dropping that mattered twice: the wait could be satisfied by a state-history link belonging to a different order item, and reloadUntilFound counts anything other than exactly one match as not-found, so an order with two items in the state never converges and dies after the full retry budget on `exhausted retries looking for body`. The batch's fixture builds a single-item order, so the local run stayed green; the defect was in the shared page object, not in this spec.
The title claimed "the order items" while the spec proves one. The fixture order cannot hold more: haveFullOrder delegates to haveOrder, whose createQuoteTransfer calls withItem() once and whose override key is `item`, singular — the Robot source's two-item assertion needs a quote-building path this reshape does not add. Naming one item keeps the title, and the target_test recorded against it, honest about the coverage that shipped.
The picking order's stock targets the demodata Warehouse1 by name because haveStock persists only the name, so a fresh stock lands with picking_list_strategy = NULL and the generate-picking-lists onEnter command throws inside requirePickingListStrategy(), parking the item in picking list generation scheduled with no error the spec can see. Warehouse1 carries multi-shipment, the only generator strategy Pyz registers. The source waits for two order items to reach ready for picking; the port waits for one, because haveFullOrder builds a strictly single-item order.
Ports the back office half of company.robot: the company is created, activated and approved, then a business unit, a company role granting only company users, and a company user whose customer the form creates. The storefront half is the permission check, driven through agent impersonation because nothing knows the new user's password. Four new back office page objects. Two ordering constraints are load bearing and are why the company is picked first and alone: changing the company select re-fetches the role checkboxes, which do not exist at all before that request, and it resets the business unit select, which stays disabled until a company is chosen. Also fixes the storefront row's post-create assertion, which looked for the new company user's email in a users table that renders name, business unit and role and no email at all. It now matches the row by its run-unique business unit.
The back-office test title listed what it sets up and never said what it proves. What it asserts is that the new company user shows up in the back-office company-user list under its company, which is now the title. Also drops two helpers the spec never used. getStatusCellSelector and getRow were written for a company-status assertion that was dropped; Activate and Approve are already load-bearing without one, because the company-user form refuses a company that is not active and approved.
Both specs reach the new company user only by impersonating them, which is the Agent Assist feature, and readme.md requires a tag per covered feature. The Robot source carried agent-assist in its suite-level Test Tags; the port dropped it. Shape follows agent-mfa-auth.cy.ts: surface and primary feature @-prefixed, further covered features bare. Both halves of the row are tagged, not just the new back-office spec — leaving the two disagreeing is worse than the omission. Also drops the yves spec's comment about the users table having no email column. The repository that owns the selector says the same thing one line from the selector itself, and that is where the reasoning belongs.
The create() docblock, the cy.wait in selectCompany() and the role-checkbox getter each explained that changing the company re-renders the role list. Each now carries only its own job: the docblock the ordering contract, the inline comment the mechanism behind the wait, the repository the label shape its cy.contains depends on.
The company field of the company-role create form is a Select2ComboBoxType with data-autocomplete-url '/company-gui/suggest' and a minimum input length of two (CompanyGui's CompanyToCompanyRoleCreateForm, wired by Pyz CompanyRoleGui's dependency provider), so typing the name fires an HTTP round-trip. Without the intercept the only budget covering it was cy.contains' 4s defaultCommandTimeout, and with retries.runMode at 2 a slow suggest would have surfaced as a rerun rather than a failure. Every other page object driving this widget already waits on the intercept - cost-center-create-page, ssp-asset-add-page, ssp-asset-update-page and the company-user-create-page added by this same branch. The business-unit page stays wait-free on purpose: its fk_company is a plain ChoiceType with the choices rendered server side.
… for their own signals
stereomon
changed the title
…n the tab is missing
…um order value All four fail only under the concurrent CI lane and pass locally every run, and none of their Robot sources was ever executed by suite's Robot UI lane: the three merchant scenarios sit outside the lane's test set and carry no smoke tag, and the order-threshold scenario carries the static-set tag the lane runs serially, with no smoke tag either. Quarantining them gives up no coverage that the lane used to have; each spec records why above its describe.
Collaborator
Author
Four specs land quarantined, on purpose
Each carries the reason above its No coverage is given upNone of these four Robot sources was ever executed by suite's Robot UI lane. The lane is pinned to
These are journeys the Robot lane never proved green here. Quarantining them takes nothing away that CI used to have; it keeps them running and visible while the two underlying problems are fixed. That also explains the shape of this branch's CI. The lane executes 44 Robot scenarios, covering 40 of the 86 rows this PR ports. Every red on this branch has been one of the other 46 — not one failure among the 40 whose source the lane actually executed. Why each fails, and what has to change
The three merchant specs — a Merchant Portal bundle defect. They die in
That is a defect in the portal's own bundle, not in these specs, and out of scope for a test migration. More waits cannot reach it. Before mergeTwo follow-up tickets:
|
Collaborator
Author
|
Both follow-ups are raised:
|
…-39280-sunset-robot-framework-coverage-map-one-clean-cutover
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Accumulating branch for the Robot UI retirement. Each domain batch is proven locally and merged in here; this pull request is what goes to master once the round closes.
https://spryker.atlassian.net/browse/CC-39280
86 of 86 in-scope scenarios are ported and verified. 0 are still to port and 0 are authored but not yet verified. The per-scenario state, including which pull request each row landed in, is in the matrix on the source branch's checklist.
The Robot originals are not deleted. The lane that runs them is switched off in CI instead, which is what suite#1087 does, so every row below keeps
pr_sourceunset and the sources stay inspryker/robotframework-suite-testsas a record.Counts
1 scenario parked, not migrated
Each one is recorded as
DEFERwith the reason it cannot be ported yet. None is counted as migrated, and none carries a skipped placeholder — a skipped target would read as coverage that nothing actually runs.Test plan
npx tsc --noEmitandnpx prettier --check— both clean.python3 gate.pyon the matrix branch —gates clean.Checklists
administration — 6 scenarios
administration · robot-ui-to-cypress · CC-39280 · 6 scenarios
MIGRATE 4 · OBSOLETE 1 · DEFER 1 ▸ 4/4 verified
Batches:
administrationTarget PR: #392
MIGRATE / RESHAPE — port these
cypress/e2e/backoffice/administration/glossary-management.cy.ts::should create a translation and list itlocal 2026-08-24 · 2 passing · 13scypress/e2e/backoffice/navigation/navigation-smoke.cy.ts::should open every left navigation node without an errorcypress/e2e/yves/agent-assist/customer-impersonation.cy.ts::agent should be able to place an order for the impersonated customerlocal 2026-08-24 · 4 passing · 40scypress/e2e/backoffice/acl/acl-navigation-access.cy.ts::should deny an action for a role with an explicit deny ruleOBSOLETE / DROP — delete the source, do not port
DEFER — parked, not counted as migrated
checkout — 16 scenarios
checkout · robot-ui-to-cypress · CC-39280 · 16 scenarios
MIGRATE 13 · OBSOLETE 3 ▸ 13/13 verified
Batches:
checkoutTarget PR: #397
MIGRATE / RESHAPE — port these
cypress/e2e/yves/cart/shared-cart-external-link.cy.ts::given a cart shared by external link when an anonymous visitor opens it then the cart is shown as a read-only previewlocal 2026-08-24 · 1 passing · 9scypress/e2e/yves/checkout/cart-approval-process.cy.ts::given a cart above the buyer spend limit when the approver approves the request then the buyer can place the orderlocal 2026-08-24 · 1 passing · 23scypress/e2e/yves/company-account/business-unit-address-checkout.cy.ts::given a company user with no personal address when the business unit address is chosen at checkout then the order ships to itlocal 2026-08-24 · 1 passing · 16scypress/e2e/yves/checkout/checkout-address-management.cy.ts::given a separate billing address when the customer returns to the address step and changes both addresses then the order takes the changed ones and only the address marked for saving is added to the address booklocal 2026-08-24 · 1 passing · 28scypress/e2e/yves/checkout/click-and-collect.cy.ts::given an offer collected at a service point when the order is placed then it ships to the service point as a single pickup shipmentlocal 2026-08-24 · 1 passing · 25scypress/e2e/yves/comments/cart-comments.cy.ts::given a cart carrying a comment when the order is placed then the comment is on the order in the storefront and in the back officelocal 2026-08-24 · 7 passing · 48scypress/e2e/yves/discount/discounts-and-promotions.cy.ts::given a guest cart holding a product bundle when a voucher and a cart rule both collect then both discounts apply and the guest order is placedlocal 2026-08-24 · 2 passing · 41scypress/e2e/yves/checkout/split-delivery.cy.ts::given a guest cart of three items when each item is given its own delivery address then the order is split into one shipment per addresslocal 2026-08-24 · 2 passing · 1m06scypress/e2e/yves/checkout/checkout-authentication.cy.ts::given a guest cart when the customer logs in at the checkout customer step then the order is placed on that accountlocal 2026-08-24 · 2 passing · 28scypress/e2e/yves/checkout/multi-merchant-order.cy.ts::given a cart holding the main merchant product and an offer from each of two merchants when the order is placed then it is split into one shipment per merchantlocal 2026-08-24 · 1 passing · 27scypress/e2e/yves/checkout/checkout-authentication.cy.ts::given a guest cart when the customer registers at the checkout customer step then the account is created and the order is placed on itlocal 2026-08-24 · 2 passing · 28scypress/e2e/yves/quote-request/quote-request-lifecycle.cy.ts::given a quote request sent to an agent when the agent revises the item price then the customer converts it to a cart and orders at the revised pricelocal 2026-08-24 · 1 passing · 25scypress/e2e/yves/checkout/split-delivery.cy.ts::should create one shipment per delivery address when the cart is splitOBSOLETE / DROP — delete the source, do not port
company — 2 scenarios
company · robot-ui-to-cypress · CC-39280 · 2 scenarios
MIGRATE 2 ▸ 2/2 verified
Batches:
companyTarget PR: #394
MIGRATE / RESHAPE — port these
cypress/e2e/yves/company-account/company-structure-creation.cy.ts::company administrator should be able to create a business unit and a company user in itlocal 2026-08-24 · 2 passing · 13scypress/e2e/backoffice/company-account/company-structure-creation.cy.ts::should list the new company user under its company when the company structure is built in the back officelocal 2026-08-24 · 2 passing · 24scontent — 1 scenarios
content · robot-ui-to-cypress · CC-39280 · 1 scenarios
MIGRATE 1 ▸ 1/1 verified
Batches:
contentTarget PR: #392
MIGRATE / RESHAPE — port these
cypress/e2e/yves/cms/cms-page-publish.cy.ts::should render a published cms page with its title and content under its localized storefront urlcustomer — 14 scenarios
customer · robot-ui-to-cypress · CC-39280 · 14 scenarios
MIGRATE 10 · OBSOLETE 3 · DROP 1 ▸ 10/10 verified
Batches:
customerTarget PR: #399
MIGRATE / RESHAPE — port these
cypress/e2e/yves/wishlist/wishlist-management.cy.ts::given a customer owning two wishlists when a product is added to each of them then each wishlist holds only its own productlocal 2026-08-25 · 2 passing · 18scypress/e2e/yves/company-account/business-on-behalf.cy.ts::given a customer attached to two business units when they use the selector then they can act for either onelocal 2026-08-25 · 1 passing · 7scypress/e2e/yves/customer-account-management/guest-access-restrictions.cy.ts::given a guest when a product is added from its detail page then the cart holds the product and its totallocal 2026-08-25 · 3 passing · 9scypress/e2e/yves/quick-order/quick-order-to-checkout.cy.ts::given a pasted quick order of two products sold by different merchants when it is bought and reordered then every destination keeps both merchantslocal 2026-08-25 · 1 passing · 23scypress/e2e/yves/cart/shared-cart-checkout.cy.ts::given a cart shared with a colleague at full access when the colleague orders it then the order is placed and keeps the merchant relationlocal 2026-08-25 · 1 passing · 24scypress/e2e/yves/shopping-list/shopping-list-sharing.cy.ts::given a shopping list shared with a colleague at full access when the colleague opens it then it is on their overview and its products reach their cartlocal 2026-08-25 · 1 passing · 20scypress/e2e/yves/shopping-list/shopping-list-product-offers.cy.ts::given a product sold by two merchants when both offers are added to one shopping list then the list and the cart keep a line per merchantlocal 2026-08-25 · 1 passing · 19scypress/e2e/yves/customer-account-management/customer-profile-management.cy.ts::customer should see a profile change an administrator made in the back officecypress/e2e/yves/customer-account-management/customer-address-management.cy.ts::customer should see an address an administrator added in the back officecypress/e2e/yves/wishlist/wishlist-product-offers.cy.ts::given a product sold by two merchants when both offers are added to one wishlist then the wishlist and the cart keep a line per merchantlocal 2026-08-25 · 1 passing · 16sOBSOLETE / DROP — delete the source, do not port
merchandising — 6 scenarios
merchandising · robot-ui-to-cypress · CC-39280 · 6 scenarios
MIGRATE 5 · OBSOLETE 1 ▸ 5/5 verified
Batches:
merchandisingTarget PR: #400
MIGRATE / RESHAPE — port these
cypress/e2e/backoffice/merchandising/product-set-management.cy.ts::given three products when a product set is created for them in the back office then the storefront serves the set and its whole content reaches the cart, and deleting the set retires the pagelocal 2026-08-25 · 1 passing · 34scypress/e2e/yves/product-bundle/configurable-bundle-checkout.cy.ts::given two configurations of one bundle template when one of them is doubled in the cart and the order is placed then the order carries three bundleslocal 2026-08-25 · 1 passing · 30scypress/e2e/yves/merchandising/product-relations.cy.ts::given one product carries a related-products relation and another carries none when both detail pages are opened then only the first shows the related products carousellocal 2026-08-25 · 1 passing · 18scypress/e2e/yves/merchandising/product-sets.cy.ts::given a product set holding a variant product and a simple one when the set is opened from the overview and the variant is picked then the whole set reaches the cart with the picked variantlocal 2026-08-25 · 1 passing · 31scypress/e2e/yves/merchandising/product-labels.cy.ts::given a published label is assigned to a product when the catalog listing and the detail page are opened then both render the labellocal 2026-08-25 · 1 passing · 13sOBSOLETE / DROP — delete the source, do not port
merchant — 22 scenarios
merchant · robot-ui-to-cypress · CC-39280 · 22 scenarios
MIGRATE 18 · OBSOLETE 1 · DROP 3 ▸ 18/18 verified
Batches:
merchantTarget PR: #392
MIGRATE / RESHAPE — port these
cypress/e2e/mp/product-offer/offer-creation.cy.ts::given a product owned by another merchant when a merchant creates an offer on it then the storefront sells it under that merchant at the offer pricelocal 2026-09-21 · 1 passing · 30scypress/e2e/mp/marketplace-product-concretes/product-concrete-management.cy.ts::given a merchant that created a multi sku product when the back office approves it then the storefront serves it, and denying it takes the detail page awaylocal 2026-09-21 · 2 passing · 59scypress/e2e/backoffice/product-offer/offer-approval.cy.ts::given an approved offer on the storefront when the back office denies it then it leaves the detail page, and approving it again brings it backlocal 2026-09-21 · 1 passing · 43scypress/e2e/mp/marketplace-order-management/order-fulfilment.cy.ts::given an order with two of a merchant's items when the merchant ships it and delivers one item then each item carries its own statelocal 2026-09-21 · 1 passing · 4mcypress/e2e/mp/marketplace-product-concretes/merchant-product-management.cy.ts::given a merchant product with one variant when the merchant adds another concrete and the back office renames the product then the storefront serves both changeslocal 2026-09-21 · 1 passing · 37scypress/e2e/backoffice/merchant-management/merchant-user-management.cy.ts::given a merchant when the back office adds a user to it then the user can be activated, renamed, deactivated and deletedlocal 2026-09-21 · 1 passing · 25scypress/e2e/backoffice/merchant-management/merchant-crud.cy.ts::given a merchant created in the back office when it is approved and renamed then the storefront serves it, and unassigning its store retires the pagelocal 2026-09-21 · 1 passing · 42scypress/e2e/mp/merchant-portal/customer-specific-prices.cy.ts::given a merchant relation to a business unit when the merchant prices a product for it then only that business unit is charged that price, and deleting the row restores the default onelocal 2026-09-21 · 1 passing · 50scypress/e2e/mp/merchant-portal/merchant-user-account.cy.ts::given a merchant user when it edits its own name and password in the portal then the new password signs it in and the back office lists the new namelocal 2026-09-21 · 1 passing · 3mcypress/e2e/mp/product-offer/offer-volume-prices.cy.ts::given an offer carrying a volume price when the merchant deletes that price row then the storefront falls back to the offer default pricelocal 2026-09-21 · 1 passing · 36scypress/e2e/mp/merchant-portal/product-volume-prices.cy.ts::given a merchant product carrying a volume price when the merchant deletes that price row then the storefront falls back to the default pricelocal 2026-09-21 · 1 passing · 37scypress/e2e/backoffice/product-offer/offer-view-and-filter.cy.ts::given two merchants each owning an offer when the offer table is filtered by one of them then only its offer is listed and the view action shows the merchant, its sku and the offer statuslocal 2026-09-21 · 2 passing · 16scypress/e2e/yves/product/merchant-product-original-price.cy.ts::given a merchant product priced below its original price when the catalog is searched then the card and the detail page both show the two priceslocal 2026-09-21 · 1 passing · 22scypress/e2e/backoffice/merchant-management/merchant-deactivation.cy.ts::given a merchant offered on the storefront when the back office deactivates it then its profile and its products leave the storefrontlocal 2026-09-21 · 1 passing · 98scypress/e2e/mp/merchant-portal/merchant-store-status.cy.ts::given an online merchant when it sets its store offline then its profile and its products leave the storefrontlocal 2026-09-21 · 1 passing · 43scypress/e2e/mp/merchant-portal/merchant-profile-update.cy.ts::given a merchant profile edited in the merchant portal when it is published then the storefront serves the new valueslocal 2026-09-21 · 1 passing · 19scypress/e2e/yves/product-offer/offer-availability.cy.ts::given an offer with a limited stock when part of it is ordered and that order is then cancelled then the offer availability falls and is restored with itlocal 2026-09-21 · 1 passing · 40scypress/e2e/yves/catalog/merchant-search.cy.ts::given two merchants offering a product of the same name when the merchant facet is applied then only that merchant's product is listedlocal 2026-09-21 · 1 passing · 1mOBSOLETE / DROP — delete the source, do not port
order — 6 scenarios
order · robot-ui-to-cypress · CC-39280 · 6 scenarios
MIGRATE 6 ▸ 6/6 verified
Batches:
orderTarget PR: #402
MIGRATE / RESHAPE — port these
cypress/e2e/backoffice/order-management/configurable-product-oms.cy.ts::given a configured product ordered and shipped when the order is reordered then the configuration is on the order but not in the new cartlocal 2026-08-25 · 1 passing · 36scypress/e2e/yves/comments/order-comments.cy.ts::given a placed order when the customer comments on it in the storefront then the comment is shown there and in the back officelocal 2026-08-25 · 1 passing · 24scypress/e2e/backoffice/order-management/shipment-management.cy.ts::given an order delivered as one shipment when a second shipment is created and then edited then the item moves and the edited address is keptlocal 2026-08-25 · 1 passing · 31scypress/e2e/yves/order-management/order-cancellation.cy.ts::given every item of an order is cancellable when the customer cancels it then the order is cancelledlocal 2026-08-25 · 2 passing · 36scypress/e2e/backoffice/order-management/order-refund.cy.ts::given a delivered order of three items when they are refunded one by one then each refund is recorded and the grand total reaches zerolocal 2026-08-25 · 1 passing · 36scypress/e2e/yves/return-management/return-creation-storefront.cy.ts::given a shipped order of three items when the customer returns two of them then only those move to waiting for returnlocal 2026-08-25 · 1 passing · 1m33splatform — 6 scenarios
platform · robot-ui-to-cypress · CC-39280 · 6 scenarios
MIGRATE 3 · RESHAPE 1 · OBSOLETE 2 ▸ 4/4 verified
Batches:
platformTarget PR: #396
MIGRATE / RESHAPE — port these
cypress/e2e/yves/discount/discounts-and-promotions.cy.ts::given a cart rule, a voucher and a promotional product discount when the voucher is redeemed and the promotional product is added then all three are applied and the order is placedlocal 2026-08-24 · 1 passing · 31scypress/e2e/yves/checkout/minimum-order-value.cy.ts::given global order thresholds when the cart is above the maximum and then below it then checkout is blocked and the soft threshold fee is chargedlocal 2026-08-24 · 1 passing · 32scypress/e2e/backoffice/data-exchange/dynamic-entity-configuration.cy.ts::given a data exchange api configuration for a table when its resource fields are configured and saved then the reloaded form renders back what was savedlocal 2026-08-24 · 1 passing · 22scypress/e2e/backoffice/data-exchange/api-specification-download.cy.ts::given a table is not exposed when its data exchange api configuration is enabled and the specification is regenerated then the downloaded specification gains its resourcelocal 2026-08-24 · 1 passing · 44sOBSOLETE / DROP — delete the source, do not port
product — 21 scenarios
product · robot-ui-to-cypress · CC-39280 · 21 scenarios
MIGRATE 18 · OBSOLETE 3 ▸ 18/18 verified
Batches:
productTarget PR: #403
MIGRATE / RESHAPE — port these
cypress/e2e/yves/product-configurator/configurable-product-checkout.cy.ts::given a configurable product when it is configured on its detail page then the configuration completes and the chosen option reaches the cartlocal 2026-08-25 · 2 passing · 24scypress/e2e/yves/product/back-in-stock-notification.cy.ts::given a product with no stock left when its detail page is opened then it reads as out of stock and offers a back in stock notificationlocal 2026-08-25 · 3 passing · 15scypress/e2e/yves/catalog/catalog-browsing.cy.ts::given a search result when a colour facet is applied then the catalog narrows to fewer products without emptyinglocal 2026-08-25 · 4 passing · 9scypress/e2e/yves/catalog/quick-add-to-cart.cy.ts::given a buyable product in the catalog when it is quick added from its card then it lands in the cartlocal 2026-08-25 · 3 passing · 11scypress/e2e/yves/product-configurator/configurable-product-shopping-list.cy.ts::given a configurable product when it is added to the cart without being configured then the cart states that it cannot be processedlocal 2026-08-25 · 3 passing · 26scypress/e2e/yves/product-configurator/configurable-product-wishlist.cy.ts::given a configurable product configured on its detail page when it is wishlisted and configured again from the wishlist then the wishlist carries the newer configurationlocal 2026-08-25 · 2 passing · 24scypress/e2e/yves/quote-request/configurable-product-rfq.cy.ts::given a configured product submitted as a quote request when an agent returns it and the customer converts it then the cart still carries the configurationlocal 2026-08-25 · 1 passing · 1m27scypress/e2e/yves/product/customer-specific-prices.cy.ts::given a customer whose company has no merchant specific price when the product is browsed then the default price is shown in the catalog and on the product detail pagelocal 2026-08-25 · 2 passing · 9scypress/e2e/yves/product/discontinued-alternative-products.cy.ts::given a discontinued product carrying an alternative when its product detail page is opened then the alternative is offered therelocal 2026-08-25 · 2 passing · 27scypress/e2e/backoffice/product-management/product-lifecycle-management.cy.ts::given an abstract product created and approved in the back office when the catalog is searched then the storefront lists itlocal 2026-08-25 · 2 passing · 1m48scypress/e2e/yves/product-measurement-unit/measurement-unit-checkout.cy.ts::given a measurement unit product when the quantity falls between two base units then the storefront says so rather than accepting itlocal 2026-08-25 · 2 passing · 25scypress/e2e/yves/product-measurement-unit/packaging-unit-checkout.cy.ts::given a packaging unit product when an amount outside its rules is entered then the storefront says so rather than accepting itlocal 2026-08-25 · 2 passing · 24scypress/e2e/yves/product/availability-calculation.cy.ts::given a product with a limited stock when part of it is ordered and that order is then cancelled then availability falls and is restored with itlocal 2026-08-25 · 1 passing · 41scypress/e2e/yves/product/product-bundle-checkout.cy.ts::given a bundle product when its product detail page is opened then the products it bundles are listed on itlocal 2026-08-25 · 2 passing · 20scypress/e2e/yves/product/original-price.cy.ts::given an abstract product priced above its default price when the catalog is searched then the card shows the default and the original price side by sidelocal 2026-08-25 · 2 passing · 18scypress/e2e/yves/product/product-detail-visibility.cy.ts::given a guest when a product variant is selected then the price, add to cart and the product options are shown and no wishlist form islocal 2026-08-25 · 3 passing · 5scypress/e2e/yves/catalog/product-restrictions.cy.ts::given a whitelist scoped to a customer merchant relationship when that customer searches then only the whitelisted product is offeredlocal 2026-08-25 · 2 passing · 14scypress/e2e/yves/product/volume-prices.cy.ts::given a product priced in volume tiers when the quantity on the detail page reaches a tier then the tier price replaces the unit pricelocal 2026-08-25 · 2 passing · 15sOBSOLETE / DROP — delete the source, do not port
store — 4 scenarios
store · robot-ui-to-cypress · CC-39280 · 4 scenarios
MIGRATE 4 ▸ 4/4 verified
Batches:
storeTarget PR: #404
MIGRATE / RESHAPE — port these
cypress/e2e/backoffice/core/dynamic-store-creation.cy.ts::given a store is created in the back office when a shopper opens the storefront then the store switcher offers itlocal 2026-08-26 · 4 passing · 47scypress/e2e/yves/core/multistore-cms-page.cy.ts::given a cms page is unassigned from a store when a shopper opens its url on that store then the page is not foundlocal 2026-08-26 · 2 passing · 43scypress/e2e/yves/core/multistore-product.cy.ts::given a product is unassigned from a store when a shopper opens its detail page on that store then the page is not foundlocal 2026-08-26 · 2 passing · 43scypress/e2e/yves/core/multistore-product-offer.cy.ts::given a store is unassigned from a product offer when a shopper opens the detail page then only the remaining store still lists that offerlocal 2026-08-26 · 2 passing · 43swarehouse — 1 scenarios
warehouse · robot-ui-to-cypress · CC-39280 · 1 scenarios
RESHAPE 1 ▸ 1/1 verified
Batches:
warehouseTarget PR: #393
MIGRATE / RESHAPE — port these
cypress/e2e/backoffice/warehouse/warehouse-picking-oms.cy.ts::should move the order item to ready for picking when picking list generation is scheduledlocal 2026-08-24 · 2 passing · 28s