Add simulated-sender

[basiliskus]

• Using simulated-sender instead of automated-staging-test-sender for automated tests
• Using simulated-sender instead of simulated-hospital and simulated-lab for local tests
• Removed AL settings from RS setup scripts

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Consistency Check Ensure that the addition of the new simulated sender key is consistent with the security and operational requirements of the system.

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Score
Security	Improve security by ensuring proper validation or sanitization of the flexion_key variable Ensure that the flexion_key variable is properly validated or sanitized before use to prevent potential security issues such as command injection. scripts/rs/load-etor-org-settings.sh [42] -./prime organization addkey -e $env --public-key $flexion_key --scope "flexion.*.report" --orgName flexion --kid flexion.simulated-sender --doit +./prime organization addkey -e $env --public-key "${flexion_key}" --scope "flexion.*.report" --orgName flexion --kid flexion.simulated-sender --doit Suggestion importance[1-10]: 8 Why: The suggestion to sanitize the flexion_key variable is crucial for preventing security vulnerabilities like command injection, which is a significant improvement in the script's security posture.	8
	Confirm the security scope and permissions for simulated-sender Verify the scope and permissions associated with the simulated-sender to ensure it aligns with intended security policies and access controls. .github/workflows/automated-staging-test-submit.yml [33] -client_sender=simulated-sender +client_sender=simulated-sender # Ensure appropriate permissions and scope Suggestion importance[1-10]: 2 Why: The suggestion is valid but it only advises to check permissions without providing a concrete code change or identifying a specific issue in the PR. It's more of a reminder or check rather than a code improvement.	2
Enhancement	Enhance documentation to explain the simulated-sender default setting Update the documentation to include details about the new simulated-sender default setting, explaining its purpose and usage to ensure clarity for end-users. scripts/hurl/rs/readme.md [14] --s <CLIENT_SENDER> The client sender to use (Default: simulated-sender) +-s <CLIENT_SENDER> The client sender to use (Default: simulated-sender) # Explain the usage and purpose of simulated-sender Suggestion importance[1-10]: 6 Why: Updating documentation to include explanations about new default settings is beneficial for user understanding and clarity. This suggestion directly improves the documentation's quality and usefulness.	6
Possible issue	Ensure simulated-sender is correctly configured across all environments Confirm that the simulated-sender client sender configuration is correctly set up in all environments (local, staging, production) to prevent runtime errors. scripts/hurl/rs/hrl [14] -client_sender=simulated-sender +client_sender=simulated-sender # Confirm environment setup Suggestion importance[1-10]: 2 Why: Similar to the previous, this suggestion is a general reminder to verify configuration across environments without pinpointing an actual issue or providing a specific improvement in the codebase.	2

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud