test: [M3-7510] - Cypress tests for Databases create page for restricted users

[dmcintyr-akamai]

Description 📝

Add Cypress tests for Databases create page for restricted users

How to test 🧪

pnpm cy:e2e -s "cypress/e2e/core/databases/create-database.spec.ts"

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 ✅

• All unit tests are passing
• TypeScript compilation succeeded without errors
• 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

---

[hasyed-akamai]

Thanks @dmcintyr-akamai, apart from only checking the Button to be disable with tooltip Text we can also check for the resource section to be available similar to be this and check there is no presence of table for the database for empty state similar to this

• Also for the restricted user Access are we planning for the non-empty state as well reference as this is also a use case in which we need to check that the action menu buttons should also be disabled when having read-only access which is implemented recently in the PR ?

[linode-gh-bot]

Cloud Manager UI test results

🔺 1 failing test on test run #6 ↗︎

❌ Failing	✅ Passing	↪️ Skipped	🕐 Duration
1 Failing	529 Passing	4 Skipped	109m 38s

Details

Failing Tests
	Spec	Test
❌	placement-groups-linode-assignment.spec.ts	Placement Groups Linode assignment » can assign non-compliant Linode with flexible placement group policy

Troubleshooting

Use this command to re-run the failing tests:

pnpm cy:run -s "cypress/e2e/core/placementGroups/placement-groups-linode-assignment.spec.ts"