Story (Required)

• As an Operator Administrator, I want to specify a list of namespaces for the notifications controller to watch in the ArgoCD CR, so that I can delegate notification management to my development teams. This improves the customer experience by providing the foundational API for the self-service notifications feature.

Background and Approach (Required)

• The current centralized notification model creates a bottleneck, as only administrators can modify the global configuration. To enable a self-service model, we first need a way for administrators to declare which namespaces are allowed to manage their own notifications.
• The technical approach involves modifying the ArgoCD Custom Resource Definition (CRD) to accept this new configuration. Add a new field to the ArgoCDNotificationsSpec struct

Out of Scope

• This story does not include the operator's reconciliation logic that acts on this new field. It only covers the API change.

Dependencies

• None. This is the foundational story.

Acceptance Criteria (Mandatory)

• Given the operator is installed with the updated CRD:
  • When I run kubectl explain argocd.spec.notifications.sourceNamespaces,
  • Then the command succeeds and describes the new field as a list of strings.
  • Given the updated CRD,
  • When I apply an ArgoCD manifest containing a valid sourceNamespaces list,
  • Then the manifest is accepted by the Kubernetes API server.
  • Given the updated CRD,
  • When I apply an ArgoCD manifest where sourceNamespaces is not a list of strings (e.g., an object or an integer),
  • Then the manifest is rejected by the Kubernetes API server.
  • 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.