Skip to Content
FrontendAppsDashboardTests Dashboard Test Case

1. Redirection and Navigation Tests

1.1: Correct Navigation with Tenant

Objective: Verify that a user is correctly redirected when navigating from the dashboard, while preserving tenant information and avoiding repeated logins.

Preconditions

  • The user has valid login credentials for a specific tenant.

  • The dashboard is accessible after login.

  • Test Steps:

    1. Login using valid credentials for the specific tenant.
    2. Verify successful login and presence on the dashboard.
    3. Click on a project listed in the dashboard.
    4. Verify redirection to the selected project’s page.
    5. Navigate back.
  • Expected Results:

    • The tenant context (tenant-123) is preserved throughout navigation.
    • Redirection to the correct project page occurs after clicking.
    • Login is required only once at the beginning.

Objective: Ensure that external links (e.g., Contact Phpcreation) on the dashboard cards redirect properly and do not break tenant or cause session issues.

Preconditions

  • The user has valid login credentials for a specific tenant.

  • The dashboard is accessible after login.

  • Test Steps:

    1. Login using valid credentials for the specific tenant.
    2. Verify successful login and presence on the dashboard.
    3. Click on a card listed in the dashboard that redirect to a external site.
    4. Confirm the presence of a valid URL (e.g., starts with http or https).
    5. Simulate a click on the link (in a way that doesn’t navigate Cypress away — e.g., validate href or target).
    6. Optionally, intercept or stub the request to confirm it would open.
  • Expected Results:

    • The external link is present and has a valid URL.
    • The link has target=“_blank” or behaves correctly to open in a new tab.
    • Clicking the link does not disrupt the tenant session or current app.
    • Tenant and login context remain intact after returning to the app.

Test Suite: Dashboard – Permissions Management

Absolutely — here’s a clearer Markdown structure with separated success and failure scenarios for permission testing, highlighting how different user roles (admin vs. viewer) should behave:


Test Suite: Dashboard – Permissions Management

Test Case 1.3: Project Visibility Based on Permissions

Objective Ensure users only see and access projects they have permission for, based on their role.

Admin User

  • Steps

    1. Login as adminUser.
    2. Dashboard loads with all projects visible.
    3. Click any project.
    4. Confirm access is granted.
  • Expected Results

    • All projects are listed.
    • Navigation to any project is successful.
    • No access restrictions are triggered.

Viewer User

  • Steps

    1. Login as viewerUser.
    2. Dashboard loads with only allowed projects visible.
    3. Attempt to manually access a restricted project via URL.
  • Expected Results

    • Only permitted projects are visible on dashboard.
    • Direct access to restricted project URL is blocked.
    • User is redirected to an “Access Denied” or “403” page.

Error manegement

Test Case 1.3: Project Visibility Based on Permissions

Objective Ensure if the user go to a page that do not exist or that they do not have permition the page informe them.

  • Steps

    1. Login as viewerUser..
    2. Dashboard loads.
    3. Modify the url for a page that do not exist.
    4. Confirm the 404 as all the require information.
    5. Open the feedback form then close it.
    6. Return to home with button in the 404 page.
  • Expected Results

    • A 404 page with a feedback form and a return to home.
Last updated on