change: [UIE-8743] - Replaced Button component in DBAAS with Akamai CDS button Web Component

[tvijay-akamai]

Description 📝

This PR is to Replaced CM Button component in DBAAS with Akamai CDS button Web Component

Changes 🔄

• Replaced Buttons in DBAAS with Akamai CDS Button Web Components.
• Changed only those button component that has no impact outside DBAAS.
• No changes to functional behavior of the buttons. Button Sizes may differ when compared to production.

Target release date 🗓️

May Release

Preview 📷

Include a screenshot or screen recording of the change.

:lock: Use the Mask Sensitive Data setting for security.

:bulb: Use <video src="" /> tag when including recordings in table.

Before	After

How to test 🧪

• Test all the buttons in DBAAS for functional and any UX issues.

Verification steps

(How to verify changes)

• Test all the buttons in DBAAS for functional and any UX alignment issues. There should no functional impact. Size of button may change compared to prod.

As an Author, to speed up the review process, I considered 🤔

👀 Doing a self review ❔ Our contribution guidelines 🤏 Splitting feature into small PRs ➕ Adding a changeset 🧪 Providing/improving test coverage 🔐 Removing all sensitive information from the code and PR description 🚩 Using a feature flag to protect the release 👣 Providing comprehensive reproduction steps 📑 Providing or updating our documentation 🕛 Scheduling a pair reviewing session 📱 Providing mobile support ♿ Providing accessibility support

• [ ] I have read and considered all applicable items listed above.

As an Author, before moving this PR from Draft to Open, I confirmed ✅

• [x] All unit tests are passing
• [x] TypeScript compilation succeeded without errors
• [x] Code passes all linting rules

---

Commit message and pull request title format standards

Note: Remove this section before opening the pull request Make sure your PR title and commit message on squash and merge are as shown below

<commit type>: [JIRA-ticket-number] - <description>

Commit Types:

• feat: New feature for the user (not a part of the code, or ci, ...).
• fix: Bugfix for the user (not a fix to build something, ...).
• change: Modifying an existing visual UI instance. Such as a component or a feature.
• refactor: Restructuring existing code without changing its external behavior or visual UI. Typically to improve readability, maintainability, and performance.
• test: New tests or changes to existing tests. Does not change the production code.
• upcoming: A new feature that is in progress, not visible to users yet, and usually behind a feature flag.

Example: feat: [M3-1234] - Allow user to view their login history

---

[tvijay-akamai]

This new component needs to adhere to basic Accessibility standards and to be consistent with its Cloud Manager counterpart. It appears to do it right overall, but I am noticing some discrepancies and lacking a couple needed improvements:

• the focus state is barely visible when its variant is primary
• there is no active state

@abailly-akamai , please send me where i can find basic accessibility standards for cloud manager.

[abailly-akamai]

@tvijay-akamai to recap, here's what we should aim to get this PR merged (spoke to Ellen about it)

1. This is currently breaking our pipeline, which can't access the remote (this is why you are seeing all these failures)
2. We need to bump the lib version with the following fix for the button:

• missing focus styles (see ng-akamai-core lib for examples)

[tvijay-akamai]

@abailly-akamai I have upgraded the web component library version which has the fix for the button focus styles. Please check and approve if looks good.

[jdamore-linode]

Still looking into these test failures with @stayal712, but in the meantime I'm noticing a couple regressions:

Button alignment on DB settings tab:

Prod	This PR

Help button alignment next to cert download button (and possibly icon color? Not sure which color is right):

Prod	This PR

Maintenance section "Upgrade Version" button alignment and appearance

Prod	This PR

[abailly-akamai]

@jdamore-linode is there an update on a solution to get the tests to pass here?

[jdamore-linode]

@abailly-akamai I believe @stayal712 is working on the tests, I can follow up with her. I am interested in the recent commits to add test IDs everywhere because in my opinion that should not be necessary just to click a button.

We discovered that any button that has an onClick prop defined can be interacted with via cy.click(), but buttons that rely on form submission do not receive the click event. Because I was able to confirm that clicking other buttons within shadow DOMs works fine, my instinct is that this is a bug with the button component that should be fixed in the CDS library, not worked around in our tests.

In the meantime, there are still unaddressed issues.

[tvijay-akamai]

Still looking into these test failures with @stayal712, but in the meantime I'm noticing a couple regressions:

Button alignment on DB settings tab:

Prod This PR Help button alignment next to cert download button (and possibly icon color? Not sure which color is right):

Prod This PR Maintenance section "Upgrade Version" button alignment and appearance

Prod This PR

@jdamore-linode These are addressed: https://github.com/linode/manager/pull/12148#issuecomment-2884119725. Please check if looks fine.

[jdamore-linode]

@tvijay-akamai it looks like those test failures need to be addressed, cc @stayal712. It looks like you might need to narrow your selection to only click on the button you want using .within like we discussed earlier

[stayal712]

@tvijay-akamai it looks like those test failures need to be addressed, cc @stayal712. It looks like you might need to narrow your selection to only click on the button you want using .within like we discussed earlier

Thanks @jdamore-linode, I have made the changes to the restricted-user-details-pages.spec.ts script as well.

[abailly-akamai]

@corya-akamai @tvijay-akamai @stayal712 what is the status of this PR?

We think the e2e issues we were seeing could be related to the button implementation itself, not necessarily warranting attempts to find the perfect workaround in Cypress. Once we confirm or rule that out (we could be quite wrong), we can move forward with either an upstream solution or the proposed implementation. Let us know how you want to proceed!

[spadhi-akamai]

@abailly-akamai Tarun is currently evaluating the most effective path forward and is exploring several potential approaches. We will keep the group informed once a final decision has been made.

[dmcintyr-akamai]

Stupid question: what does 'CDS' stand for?

and i can't see any difference in the button(s) between the before and after screenshots; is that how it's intended to be?

[tvijay-akamai]

Stupid question: what does 'CDS' stand for?

and i can't see any difference in the button(s) between the before and after screenshots; is that how it's intended to be?

Not a stupid question at all! 'CDS' stands for Akamai Core Design System. It's a comprehensive design framework that provides standardized UI components and design guidelines to ensure consistency and efficiency across Akamai's applications and services.

Yes, no difference is intentional. While the visual appearance of the buttons remains the same, the underlying implementation has been updated. Goal is to transition to using a new, framework-agnostic component. This change doesn't affect the look or behavior of the buttons but enhances their flexibility and maintainability across different Akamai platforms.

[tvijay-akamai]

@corya-akamai @tvijay-akamai @stayal712 what is the status of this PR?

We think the e2e issues we were seeing could be related to the button implementation itself, not necessarily warranting attempts to find the perfect workaround in Cypress. Once we confirm or rule that out (we could be quite wrong), we can move forward with either an upstream solution or the proposed implementation. Let us know how you want to proceed!

@abailly-akamai We explored multiple approaches including the one you previously suggested to address the Cypress implementation preference specifically related to buttons of type "submit" in our web component. There are only 2 button type submit. (For other button types there is no concern as discussed with Sakshi.)

While we did identify one solution that resolves the issue, the team decided not to proceed with it. The team's consensus is that introducing code changes solely to accommodate Cypress’s implementation preferences is not optimal, especially since there is an alternative way to simulate and test submit-type button behavior in our e2e test cases. For all other button types, our current approach works as expected.

Let us know if you’d like more details on the alternatives we considered. we can separately sync-up on the same.

[linode-gh-bot]

Cloud Manager UI test results

:tada: 666 passing tests on test run #22 ↗︎

:x: Failing	:white_check_mark: Passing	:arrow_right_hook: Skipped	:clock1: Duration
0 Failing	666 Passing	4 Skipped	138m 45s