@camunda/e2e-test-suite 0.0.1008 → 0.0.1010

package/dist/pages/SM-8.10/ModelerHomePage.js

@@ -3,10 +3,24 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.ModelerHomePage = void 0;
 const test_1 = require("@playwright/test");
 const expectLocatorWithRetry_1 = require("../../utils/assertionHelpers/expectLocatorWithRetry");
+const randomName_1 = require("../../utils/randomName");
 const NavigationPage_1 = require("./NavigationPage");
+const ProcessApplicationPage_1 = require("./ProcessApplicationPage");
 class ModelerHomePage {
     page;
     defaultFolderName = 'Cross Component Test Project';
+    // Since camunda/camunda-hub#25831 files and folders cannot sit at a
+    // workspace ("project" in today's UI) root -- only process applications and
+    // IDP applications can. The container is therefore entered lazily, at the
+    // point a resource is created, and remembered for the lifetime of this page
+    // object (one instance per test, see fixtures/SM-8.10.ts). Specs that only
+    // need the workspace itself never trigger the hop.
+    processApplicationPage;
+    // Load-bearing: hub renders no process-application breadcrumb on a diagram
+    // page at container root, so the remembered URL -- not a breadcrumb click --
+    // is how we get back. Hub's own Playwright suite does the same.
+    processApplicationUrl;
+    processApplicationName;
     modelerPageBanner;
     createNewProjectButton;
     projectNameInput;
@@ -19,6 +33,7 @@ class ModelerHomePage {
     bpmnTemplateOption;
     formTemplateOption;
     projectBreadcrumb;
+    workspaceBreadcrumb;
     openOrganizationsButton;
     manageButton;
     crossComponentProjectFolder;
@@ -35,6 +50,7 @@ class ModelerHomePage {
     modalCloseButton;
     constructor(page) {
         this.page = page;
+        this.processApplicationPage = new ProcessApplicationPage_1.ProcessApplicationPage(page);
         // Matches both Modeler shells -- see NavigationPage.modelerPageBanner for
         // why the Design System branch excludes the /login href.
         this.modelerPageBanner = page
@@ -58,12 +74,11 @@ class ModelerHomePage {
             name: 'Choose BPMN template',
         });
         this.diagramTypeDropdown = page.locator('[data-test="diagram-dropdown"]');
-        this.bpmnTemplateOption = page
-            .locator('[data-test="create-bpmn-diagram"]')
-            .getByText('BPMN Diagram');
-        this.formTemplateOption = page
-            .locator('[data-test="create-form"]')
-            .getByText('Form');
+        // Matched on the test id alone: hub's design-system variant of the create
+        // menu renders "BPMN diagram" (lowercase d), so a text filter breaks the
+        // day that variant ships.
+        this.bpmnTemplateOption = page.locator('[data-test="create-bpmn-diagram"]');
+        this.formTemplateOption = page.locator('[data-test="create-form"]');
         // The Design System shell drops the breadcrumb-project hook. Its context
         // breadcrumb is org / project / entity, so the project crumb is the second
         // item -- scoped to the breadcrumb nav, never a bare nth() on the page.
@@ -75,6 +90,21 @@ class ModelerHomePage {
             .getByRole('button')
             .first())
             .first();
+        // Kept separate from projectBreadcrumb, which now means "the container my
+        // resources live in". When hub's workspaces terminology flag flips,
+        // breadcrumb-project comes to denote the process application, so the
+        // workspace level needs its own name from the start. Carries the same
+        // Design System fallback as projectBreadcrumb: under that shell neither
+        // test-id hook exists, and the workspace level is the project crumb.
+        this.workspaceBreadcrumb = page
+            .locator('[data-test="breadcrumb-project"]')
+            .or(page.locator('[data-test="breadcrumb-workspace"]'))
+            .or(page
+            .locator('nav[aria-label="Context navigation"] [data-slot="nav-breadcrumb-item"]')
+            .nth(1)
+            .getByRole('button')
+            .first())
+            .first();
         this.openOrganizationsButton = page.getByLabel('Open Organizations');
         this.manageButton = page.getByRole('button', { name: 'Manage' });
         this.crossComponentProjectFolder = page
@@ -248,7 +278,12 @@ class ModelerHomePage {
             }
         }
     }
+    // Opens a resource where this test put it. Several specs leave Modeler
+    // entirely (to Optimize, to Operate) and come back via
+    // clickCrossComponentProjectFolder(), which lands at workspace root -- the
+    // resource is one level down, so re-enter the container first.
     async clickProcessDiagram(name) {
+        await this.ensureInResourceContainer();
         const process = this.rows.filter({ hasText: name }).getByTitle(name).first();
         await (0, test_1.expect)(process).toBeVisible({ timeout: 90000 });
         await process.click();
@@ -267,13 +302,19 @@ class ModelerHomePage {
     async clickChooseBpmnTemplateButton() {
         await this.chooseBpmnTemplateButton.click();
     }
+    // Opens the create menu inside this test's process application. The menu at
+    // workspace root no longer offers BPMN, Form or Upload -- those resources
+    // cannot live there -- so the container is entered first. Callers are
+    // unchanged, which is why the ~150 existing spec call sites need no edit.
     async clickDiagramTypeDropdown() {
-        await (0, expectLocatorWithRetry_1.expectLocatorWithRetry)(this.page, this.diagramTypeDropdown, {
+        await this.enterResourceContainer();
+        const dropdown = this.processApplicationPage.createNewDropdown;
+        await (0, expectLocatorWithRetry_1.expectLocatorWithRetry)(this.page, dropdown, {
             postAction: async () => {
                 await this.page.reload();
             },
         });
-        await this.diagramTypeDropdown.click();
+        await dropdown.click();
     }
     async clickBpmnTemplateOption() {
         await (0, test_1.expect)(this.bpmnTemplateOption).toBeVisible({ timeout: 60000 });
@@ -286,6 +327,13 @@ class ModelerHomePage {
     // no inline editable input and renames through the breadcrumb's "More
     // actions" > "Rename" dialog.
     async enterFormName(name) {
+        // Wait for the form editor itself before probing rename affordances. The
+        // project page also renders a "More actions" button, so the or() gate below
+        // is satisfied while the caller's navigation is still in flight -- which
+        // renamed the PROJECT to the form's name instead of the form. The Carbon
+        // shell could not hit this: editable-input existed only inside the editor,
+        // so the gate implicitly waited for navigation.
+        await this.page.waitForURL(/\/forms\//, { timeout: 60000 });
         await this.formNameInput
             .or(this.moreActionsButton)
             .first()
@@ -309,8 +357,97 @@ class ModelerHomePage {
         await this.renameSubmitButton.click();
         await (0, test_1.expect)(this.renameInput).toBeHidden({ timeout: 10000 });
     }
+    // Kept under its original name because it is what ~10 call sites already
+    // mean: "go back to where my resources live". That is now the process
+    // application, not the workspace root.
     async clickProjectBreadcrumb() {
-        await this.projectBreadcrumb.click({ timeout: 60000 });
+        await this.returnToResourceContainer();
+    }
+    // The workspace ("project") level itself, for the surfaces that genuinely
+    // live there -- collaborators, IDP applications, published element
+    // templates.
+    async clickWorkspaceBreadcrumb() {
+        await this.workspaceBreadcrumb.click({ timeout: 60000 });
+    }
+    // Creates, once per test, the process application that holds this test's
+    // resources, and leaves the browser inside it. Idempotent: called again while
+    // already in the container it is a no-op, so a spec that creates several
+    // resources in a row pays for the container once.
+    //
+    // One container per test rather than one shared with the seeded workspace:
+    // deploying is process-application-wide, so a shared container would let one
+    // spec's deploy pick up every other spec's half-modelled diagram.
+    async enterResourceContainer(name) {
+        if (this.processApplicationUrl) {
+            const stillInside = await this.becameVisible(this.processApplicationPage.breadcrumb, 5000);
+            if (!stillInside) {
+                await this.returnToResourceContainer();
+            }
+            return;
+        }
+        this.processApplicationName =
+            name ??
+                (await (0, randomName_1.randomNameAgregator)('Cross Component Process Application'));
+        console.log(`Creating process application ${this.processApplicationName} inside ${this.defaultFolderName}`);
+        await this.clickCreateProcessApplication();
+        await this.processApplicationPage.nameNewProcessApplication(this.processApplicationName);
+        this.processApplicationUrl = this.page.url();
+    }
+    // Which control creates a process application depends on the hub version
+    // under test. Since camunda/camunda-hub#25831 it is a plain primary button on
+    // the workspace root, and the "Create new" menu explicitly hides the item
+    // (hideProcessApplication) because a process application is no longer just
+    // another resource. Before that change the menu item was the only way in.
+    // Race both entry points so neither version pays a full timeout, then use
+    // whichever one rendered.
+    async clickCreateProcessApplication() {
+        const button = this.processApplicationPage.createProcessApplicationButton;
+        const rootLoaded = await this.becameVisible(button.or(this.diagramTypeDropdown).first(), 60000);
+        if (!rootLoaded) {
+            await this.page.reload();
+        }
+        // Short: the joint probe above already settled which branch rendered, and
+        // hub renders exactly one of them (EntityTable renders the toolbar's create
+        // menu OR the empty state, never both), so this only confirms which.
+        if (await this.becameVisible(button, 5000)) {
+            await this.processApplicationPage.clickCreateProcessApplicationButton();
+            return;
+        }
+        await this.diagramTypeDropdown.click({ timeout: 60000 });
+        await this.processApplicationPage.clickCreateProcessApplicationOption();
+    }
+    // Re-enters this test's container if it already has one, without creating
+    // one: opening an existing resource must not have the side effect of
+    // creating a container for a spec that never asked for it.
+    async ensureInResourceContainer() {
+        if (!this.processApplicationUrl) {
+            return;
+        }
+        await this.enterResourceContainer();
+    }
+    // Navigates back to this test's process application by the remembered URL
+    // rather than by a breadcrumb click: hub renders no process-application
+    // breadcrumb on a diagram page at container root, and the breadcrumb that
+    // does exist on the container page doubles as its rename control. Hub's own
+    // Playwright suite navigates back the same way.
+    async returnToResourceContainer() {
+        if (!this.processApplicationUrl) {
+            await this.clickWorkspaceBreadcrumb();
+            return;
+        }
+        await this.page.goto(this.processApplicationUrl, {
+            waitUntil: 'domcontentloaded',
+        });
+        await this.processApplicationPage.waitForProcessApplication();
+        await this.clickMessageBanner();
+    }
+    // Single seam for "give me an empty BPMN diagram in this test's container".
+    // A process application always ships an auto-created main process; this adds
+    // a new diagram rather than adopting that one, so every existing modelling
+    // assertion keeps its current subject.
+    async startBlankBpmnDiagram() {
+        await this.clickDiagramTypeDropdown();
+        await this.clickBpmnTemplateOption();
     }
     async clickOpenOrganizationsButton() {
         await this.openOrganizationsButton.click({ timeout: 30000 });
@@ -344,6 +481,14 @@ class ModelerHomePage {
             }
         }
     }
+    // Boolean visibility probe. waitFor rather than isVisible, which resolves
+    // immediately and would report a false negative on a still-rendering page.
+    async becameVisible(locator, timeout) {
+        return locator
+            .waitFor({ state: 'visible', timeout })
+            .then(() => true)
+            .catch(() => false);
+    }
     // Probe with waitFor, not isVisible: the "New features" modal renders lazily
     // after page load, and isVisible resolves immediately — Playwright ignores
     // its timeout option — so it misses an overlay that has yet to paint.

package/dist/pages/SM-8.10/ProcessApplicationPage.d.ts

@@ -0,0 +1,23 @@
+import { Locator, Page } from '@playwright/test';
+declare class ProcessApplicationPage {
+    private page;
+    readonly createProcessApplicationButton: Locator;
+    readonly createProcessApplicationOption: Locator;
+    readonly creationDialog: Locator;
+    readonly nameInput: Locator;
+    readonly submitButton: Locator;
+    readonly cancelButton: Locator;
+    readonly breadcrumb: Locator;
+    readonly folderExplorer: Locator;
+    readonly titleBar: Locator;
+    readonly createNewDropdown: Locator;
+    readonly inlineNameInput: Locator;
+    constructor(page: Page);
+    private pageReady;
+    waitForProcessApplication(timeout?: number): Promise<void>;
+    clickCreateProcessApplicationButton(): Promise<void>;
+    clickCreateProcessApplicationOption(): Promise<void>;
+    nameNewProcessApplication(name: string): Promise<void>;
+    openByName(name: string): Promise<void>;
+}
+export { ProcessApplicationPage };

package/dist/pages/SM-8.10/ProcessApplicationPage.js

@@ -0,0 +1,132 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.ProcessApplicationPage = void 0;
+const test_1 = require("@playwright/test");
+const submitModalWithRetry_1 = require("../../utils/assertionHelpers/submitModalWithRetry");
+// Since camunda/camunda-hub#25831 a process application is a first-class
+// container rather than a folder, and a workspace root ("project" in today's
+// UI) holds nothing but process applications and IDP applications. Every file
+// and folder this suite creates therefore has to live inside a process
+// application. This page object owns that container's surface only; entering
+// and leaving it is driven from ModelerHomePage so the ~150 existing spec call
+// sites keep working unchanged.
+class ProcessApplicationPage {
+    page;
+    // Empty workspace root: a plain primary button rendered next to the "Create
+    // new" menu (hub's EmptyStateActionButtons).
+    createProcessApplicationButton;
+    // Non-empty root: the item inside the "Create new" menu. Hub passes
+    // hideProcessApplication at workspace level, so this is the fallback rather
+    // than the primary path -- its own unit test asserts the item is absent
+    // there. Kept because the Hub PR is still moving this surface.
+    createProcessApplicationOption;
+    creationDialog;
+    nameInput;
+    submitButton;
+    cancelButton;
+    breadcrumb;
+    folderExplorer;
+    titleBar;
+    createNewDropdown;
+    inlineNameInput;
+    constructor(page) {
+        this.page = page;
+        // .first() defensively only: hub renders exactly one of these today, in the
+        // workspace-root empty state. A future second placement should not turn
+        // every PA-creating test into a strict-mode violation.
+        this.createProcessApplicationButton = page
+            .getByRole('button', { name: 'Create process application' })
+            .first();
+        this.createProcessApplicationOption = page.locator('[data-test="create-process-application"]');
+        this.creationDialog = page.getByRole('dialog', {
+            name: 'Create a process application',
+        });
+        // Deliberately scoped to the dialog: ModelerCreatePage owns an unscoped
+        // getByLabel('Name', {exact: true}) for the properties panel, which would
+        // resolve to two elements while the creation modal is open.
+        this.nameInput = this.creationDialog.getByLabel('Name', { exact: true });
+        this.submitButton = this.creationDialog.getByRole('button', {
+            name: 'Create',
+            exact: true,
+        });
+        this.cancelButton = this.creationDialog.getByRole('button', {
+            name: 'Cancel',
+            exact: true,
+        });
+        this.breadcrumb = page.locator('[data-test="breadcrumb-process-application-menu"]');
+        // The Design System shell renames this region "Resources"; the Carbon shell
+        // calls it "Folder explorer". Both hold the resource table and its toolbar,
+        // so matching either keeps createNewDropdown below correctly scoped.
+        this.folderExplorer = page
+            .getByRole('region', { name: 'Folder explorer' })
+            .or(page.getByRole('region', { name: 'Resources' }))
+            .first();
+        // Design System proof that we are on a process application page: the
+        // Carbon-era breadcrumb hook is gone under that shell, the same way
+        // breadcrumb-project is.
+        this.titleBar = page.locator('[data-test="process-application-title-bar"]');
+        // The process application page renders more than one diagram-dropdown
+        // (hub's own unit tests reach for it with getAllByTestId), so the dropdown
+        // has to be resolved inside the folder explorer rather than page-wide.
+        this.createNewDropdown = this.folderExplorer
+            .locator('[data-test="diagram-dropdown"]')
+            .first();
+        this.inlineNameInput = page.locator('[data-test="editable-input"]');
+    }
+    // Any one of the title bar, the resource region or the breadcrumb proves we
+    // are on the process application page. Three branches because the Design
+    // System and Carbon shells expose different subsets: only the title bar is
+    // present under both. .first() because several match once it has rendered.
+    pageReady() {
+        return this.titleBar.or(this.folderExplorer).or(this.breadcrumb).first();
+    }
+    async waitForProcessApplication(timeout = 90000) {
+        await (0, test_1.expect)(this.pageReady()).toBeVisible({ timeout });
+    }
+    async clickCreateProcessApplicationButton() {
+        await (0, test_1.expect)(this.createProcessApplicationButton).toBeVisible({
+            timeout: 60000,
+        });
+        await this.createProcessApplicationButton.click({ timeout: 60000 });
+    }
+    async clickCreateProcessApplicationOption() {
+        await (0, test_1.expect)(this.createProcessApplicationOption).toBeVisible({
+            timeout: 60000,
+        });
+        await this.createProcessApplicationOption.click({ timeout: 60000 });
+    }
+    // Hub creates a process application through a modal today. It used an inline
+    // editable title before, and #27593 is still moving this surface, so the
+    // inline path is kept as a fallback — this is the one method that has to
+    // change if naming moves back inline.
+    async nameNewProcessApplication(name) {
+        const isModal = await this.creationDialog
+            .waitFor({ state: 'visible', timeout: 15000 })
+            .then(() => true)
+            .catch(() => false);
+        if (isModal) {
+            await this.nameInput.click({ timeout: 30000 });
+            await this.nameInput.fill(name);
+            await (0, test_1.expect)(this.nameInput).toHaveValue(name, { timeout: 10000 });
+            await (0, submitModalWithRetry_1.submitModalWithRetry)(this.submitButton, this.creationDialog);
+            await this.waitForProcessApplication();
+            return;
+        }
+        await (0, test_1.expect)(this.inlineNameInput).toBeVisible({ timeout: 30000 });
+        await this.inlineNameInput.click({ timeout: 60000 });
+        await this.inlineNameInput.fill(name);
+        await this.inlineNameInput.press('Enter');
+        await this.waitForProcessApplication();
+    }
+    async openByName(name) {
+        const processApplication = this.page
+            .getByRole('row')
+            .filter({ hasText: name })
+            .getByTitle(name)
+            .first();
+        await (0, test_1.expect)(processApplication).toBeVisible({ timeout: 90000 });
+        await processApplication.click({ timeout: 60000 });
+        await this.waitForProcessApplication();
+    }
+}
+exports.ProcessApplicationPage = ProcessApplicationPage;

package/dist/pages/SM-8.10/UtilitiesPage.js

@@ -416,6 +416,14 @@ async function modelAndRunConnectorsTimerEventDiagram(modelerCreatePage, modeler
         timeout: 60000,
     });
     await connectorMarketplacePage.downloadConnectorToProject();
+    // Both lookups are container-relative: clickProjectBreadcrumb() returns to
+    // this test's process application, which is where the uploaded diagram
+    // lives. The downloaded element template is the open question -- hub
+    // publishes element templates to the workspace, but the marketplace
+    // download is initiated from inside the container, so it should land there.
+    // If a trace shows the template at workspace root instead, the first of
+    // these two calls becomes clickWorkspaceBreadcrumb() followed by
+    // returnToResourceContainer() before the diagram is reopened.
     await modelerHomePage.clickProjectBreadcrumb();
     await modelerHomePage.clickProcessDiagram('REST Outbound Connector');
     await connectorTemplatePage.publishConnector();

package/dist/tests/8.10/access-user-role-management.spec.js

@@ -125,7 +125,7 @@ _8_10_1.test.describe('User Roles User Flow', () => {
             await modelerCreatePage.clickAppendEndEventButton();
             await (0, sleep_1.sleep)(20000);
             await modelerCreatePage.runProcessInstance(clusterName);
-            await (0, test_1.expect)(page.getByText('The diagram failed to deploy & run')).toBeVisible({ timeout: 60000 });
+            await (0, test_1.expect)(page.getByText(/The (diagram|application) failed to deploy & run/)).toBeVisible({ timeout: 60000 });
             await modelerCreatePage.clickCloseButton();
         });
     });
@@ -216,7 +216,7 @@ _8_10_1.test.describe('User Roles User Flow', () => {
             await modelerCreatePage.clickAppendEndEventButton();
             await (0, sleep_1.sleep)(20000);
             await modelerCreatePage.runProcessInstance(clusterName, '', {}, '', false);
-            await (0, test_1.expect)(page.getByText('The diagram failed to deploy & run')).toBeVisible({ timeout: 60000 });
+            await (0, test_1.expect)(page.getByText(/The (diagram|application) failed to deploy & run/)).toBeVisible({ timeout: 60000 });
             await modelerCreatePage.clickCloseButton();
         });
     });
@@ -312,7 +312,7 @@ _8_10_1.test.describe('User Roles User Flow', () => {
             await modelerCreatePage.clickAppendEndEventButton();
             await (0, sleep_1.sleep)(20000);
             await modelerCreatePage.runProcessInstance(clusterName);
-            await (0, test_1.expect)(page.getByText('The diagram failed to deploy & run')).not.toBeVisible({ timeout: 60000 });
+            await (0, test_1.expect)(page.getByText(/The (diagram|application) failed to deploy & run/)).not.toBeVisible({ timeout: 60000 });
             await (0, test_1.expect)(modelerCreatePage.viewProcessInstanceLink).toBeVisible({
                 timeout: 120000,
             });

package/dist/tests/8.10/idp-user-flows.spec.js

@@ -95,7 +95,9 @@ _8_10_1.test.describe('IDP User Flow Tests', () => {
                     await modelerHomePage.clickCrossComponentProjectFolder();
                 });
                 await _8_10_1.test.step('Add an IDP application to the project', async () => {
-                    await modelerHomePage.clickDiagramTypeDropdown();
+                    // Workspace-level menu: an IDP application can only be created at
+                    // workspace root, never inside a process application.
+                    await modelerHomePage.clickWorkspaceDiagramTypeDropdown();
                     await modelerHomePage.clickIdpApplicationTemplateOption();
                 });
                 await _8_10_1.test.step('Creates a document extraction template', async () => {
@@ -168,7 +170,9 @@ _8_10_1.test.describe('IDP User Flow Tests', () => {
                     await modelerHomePage.clickCrossComponentProjectFolder();
                 });
                 await _8_10_1.test.step('Add an IDP application to the project', async () => {
-                    await modelerHomePage.clickDiagramTypeDropdown();
+                    // Workspace-level menu: an IDP application can only be created at
+                    // workspace root, never inside a process application.
+                    await modelerHomePage.clickWorkspaceDiagramTypeDropdown();
                     await modelerHomePage.clickIdpApplicationTemplateOption();
                 });
                 await _8_10_1.test.step('Creates a document extraction template', async () => {
@@ -249,7 +253,9 @@ _8_10_1.test.describe('IDP User Flow Tests', () => {
                     await modelerHomePage.clickCrossComponentProjectFolder();
                 });
                 await _8_10_1.test.step('Add an IDP application to the project', async () => {
-                    await modelerHomePage.clickDiagramTypeDropdown();
+                    // Workspace-level menu: an IDP application can only be created at
+                    // workspace root, never inside a process application.
+                    await modelerHomePage.clickWorkspaceDiagramTypeDropdown();
                     await modelerHomePage.clickIdpApplicationTemplateOption();
                 });
                 await _8_10_1.test.step('Creates a classification template', async () => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camunda/e2e-test-suite",
-  "version": "0.0.1008",
+  "version": "0.0.1010",
   "description": "End-to-end test helpers for Camunda 8",
   "repository": {
     "type": "git",