Story (Required)

• Implement detection logic and improve delete dialog behavior when deleting Application or ApplicationSet resources from the resource tree to prevent user confusion and production incidents.

Background and Approach (Required)

• Detection Logic:

• • System detects when a resource being deleted is an Application (kind: Application, group: argoproj.io)
  • System detects when a resource being deleted is an ApplicationSet (kind: ApplicationSet, group: argoproj.io)
  • Regular Kubernetes resources (Pod, Service, Deployment, etc.) are not incorrectly detected
  • Detection logic is accurate and doesn't produce false positives

    Dialog Titles:

• • Application resources show "Delete application" title (instead of "Delete resource")
  • ApplicationSet resources show "Delete application set" title
  • Regular resources continue to show "Delete resource" title
  • Dialog titles are consistent between Applications list and Resource tree views

    Warning Messages:

• • Shows warning when deleting Application/ApplicationSet from resource tree
  • Explains that non-cascading behavior may not work as expected from resource tree
  • Warns about dangerous implications of foreground/background deletion
  •  Out of Scope

• <Defines what is not included in this story.>

Dependencies

• <Describes what this story depends on. Dependent stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

• <Describe edge cases to consider when implementing the story and defining tests.>
• <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story.>

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.