Enhance SSH dialog user experience

[0oM4R]

Description

this pr include two unrelated changes that only lint fixes

• prevent empty key name
• Disable closing the dialog while generating or saving the key
• Apply new constraints on names
• Rename the keys that do not follow the constraints
• Show a toast to inform the user that the keys have been recovered and updated successfully

Related Issues

• 🐞 [Bug]: Broken ssh page #4150

Tested Scenarios

• Generate an SSH key and try to close while generating
• An empty name will trigger field validation
• Import and try to close the dialog while saving
• generate keys from dashboard.dev that do not follow the new constraints, this should be recovered and named to defaultN

Documentation PR

For UI changes, Please provide the Documentation PR on info_grid

To consider

Preliminary Checks:

• Preliminary Checks
  • Does it completely address the issue linked?
  • What about edge cases?
  • Does it meet the specified acceptance criteria?
  • Are there any unintended side effects?
  • Does the PR adhere to the team's coding conventions, style guides, and best practices?
  • Does it integrate well with existing features?
  • Does it impact the overall performance of the application?
  • Are there any bottlenecks or slowdowns?
  • Has it been optimized for efficiency?
  • Has it been adequately tested with unit, integration, and end-to-end tests?
  • Are there any known defects or issues?
  • Is the code well-documented?
  • Are changes to documentation reflected in the code?

UI Checks:

• UI Checks
  • If a UI design is provided/ does it follow it?
  • Does every button work?
  • Is the data displayed logical? Is it what you expected?
  • Does every validation work?
  • Does this interface feel intuitive?
  • What about slow network? Offline?
  • What if the gridproxy/graphql/chain is failing?
  • What would a first time user have a hard time navigating here?

Code Quality Checks:

• Code Quality Checks
  • Code formatted/linted? Are there unused imports? .. etc
  • Is there redundant/repeated code?
  • Are there conditionals that are always true or always false?
  • Can we write this more concisely?
  • Can we reuse this code? If yes, where?
  • Will the changes be easy to maintain and update in the future?
  • Can this code become too complex to understand for other devs?
  • Can this code cause future integration problems?

Testing Checklist

• Does it Meet the specified acceptance criteria.
• Test if changes can affect any other functionality.
• Tested with unit, integration, and end-to-end tests.
• Tested the un-happy path and rollback scenarios.
• Documentation updated to meet the latest changes.
• Check automated tests working successfully with the changes.
• Can be covered by automated tests.

General Checklist

• Tests included
• Build pass
• Documentation
• Code format and docstring
• Screenshots/Video attached (needed for UI changes)

[samaradel]

shouldn't it be senstive case ?

[samaradel]

Why is it needed?

[0oM4R]

The keys will be renamed, this is to make the user aware of what happened to the keys

[0oM4R]

shouldn't it be senstive case ?

It was not requested, and there is no conflict in keys, so I think it is fine for now, We may have another issue to discuss further

[amiraabouhadid]

Suggested change

	assignDefaultNames(keys?: SSHKeyData[]): SSHKeyData[] {
	if (!keys) {
	keys = this.oldKeys as SSHKeyData[];
	}
	const existingNames = new Set(keys.map(k => k.name).filter(Boolean));
	for (const key of keys) {
	if (isAlphanumericWithSpace("Invalid name")(key.name) !== true) {
	key.name = this.getUniqueName(existingNames, false);
	}
	}
	return keys;
	}
	assignDefaultNames(keys?: SSHKeyData[]): SSHKeyData[] {
	if (!keys) {
	keys = this.oldKeys as SSHKeyData[];
	}
	// Collect existing names, filtering out empty or falsy names
	const existingNames = new Set(
	keys
	.map(k => k.name)
	.filter(name => name && isAlphanumericWithSpace("Invalid name")(name) === true)
	);
	for (const key of keys) {
	// Check if name is invalid or empty
	if (!key.name || isAlphanumericWithSpace("Invalid name")(key.name) !== true) {
	// Assign a unique default name
	key.name = this.getUniqueName(existingNames, false);
	} else {
	// Add valid existing name to the set to prevent duplicates
	existingNames.add(key.name);
	}
	}
	return keys;
	}

[amiraabouhadid]

Suggested change

	export function isAlphanumericWithSpace(msg: string) {
	return (value: string) => {
	if (value.endsWith(" ")) {
	return msg;
	}
	value = value.trimEnd();
	if (!/^[a-zA-Z0-9]+( [a-zA-Z0-9]+)*$/.test(value)) {
	return msg;
	}
	return true;
	};
	}
	export function isAlphanumericWithSpace(msg: string) {
	return (value: string) => {
	if (value.endsWith(" ") || !/^[a-zA-Z0-9]+( [a-zA-Z0-9]+)*$/.test(value.trimEnd())) {
	return msg;
	}
	return true;
	};
	}

[amiraabouhadid]

maybe add this
it("should not allow a string with only spaces", () => { expect(validator(" ")).toBe("Invalid input"); expect(validator(" ")).toBe("Invalid input"); });

[amiraabouhadid]

and this it("should allow a single character", () => { expect(validator("A")).toBe(true); expect(validator("z")).toBe(true); expect(validator("1")).toBe(true); });

[amiraabouhadid]

tests pass

validation err appears on empty name

save btn should be disabled when form is invalid

[ramezsaeed]

tests pass validation err appears on empty name save btn should be disabled when form is invalid

+1 save button should be disabled in this case.