4.0.1: Alerting and reports does not take EMAIL RECIPIENTS* about superset

[dosubot]

The issues you are experiencing with saving an alert in Superset and modifying the email recipients of old alerts are likely due to the validation and state management logic in the AlertReportModal component.

1. Notification Method Highlighted in Red:
   The notification method is highlighted in red because the validation logic checks if all required fields are complete before enabling the save button. Specifically, the validateNotificationSection function checks if the notification settings have the required information, including the recipients. If the recipients are not provided, it marks the section as having errors, which results in the notification method being highlighted in red.

   const validateNotificationSection = () => {
     const hasErrors = !checkNotificationSettings();
     const errors = hasErrors ? [TRANSLATIONS.RECIPIENTS_ERROR_TEXT] : [];
   
     if (emailError) {
       errors.push(TRANSLATIONS.EMAIL_SUBJECT_ERROR_TEXT);
     }
   
     updateValidationStatus(Sections.Notification, errors);
   };
   
   const checkNotificationSettings = () => {
     if (!notificationSettings.length) {
       return false;
     }
   
     let hasInfo = false;
   
     notificationSettings.forEach(setting => {
       if (!!setting.method && setting.recipients?.length) {
         hasInfo = true;
       }
     });
   
     return hasInfo;
   };

2. Unable to Modify Email Recipients of Old Alerts:
   The inability to modify email recipients of old alerts created in version 3.1.2 could be due to the way the notification settings are initialized and managed. When an alert is fetched, the notification settings are populated based on the recipients from the resource. If the recipients are not correctly parsed or if the allowed notification methods do not match the existing methods, it could prevent modifications.

   useEffect(() => {
     if (resource) {
       // Add notification settings
       const settings = (resource.recipients || []).map(setting => {
         const config =
           typeof setting.recipient_config_json === 'string'
             ? JSON.parse(setting.recipient_config_json)
             : {};
         return {
           method: setting.type,
           // @ts-ignore: Type not assignable
           recipients: config.target || setting.recipient_config_json,
           options: allowedNotificationMethods,
         };
       });
   
       setNotificationSettings(settings);
       setNotificationAddState(
         settings.length === allowedNotificationMethods.length
           ? 'hidden'
           : 'active',
       );
     }
   }, [resource]);

   Ensure that the allowedNotificationMethods includes the methods used in old alerts and that the recipients are correctly parsed and assigned.

Additionally, the NotificationMethod component handles the rendering and validation of the notification method and recipients. If the recipients are not correctly set or if there are validation errors, the component will highlight the input fields in red.

const onRecipientsChange = (
  event: React.ChangeEvent<HTMLTextAreaElement>,
) => {
  const { target } = event;

  setRecipientValue(target.value);

  if (onUpdate) {
    const updatedSetting = {
      ...setting,
      recipients: target.value,
    };

    onUpdate(index, updatedSetting);
  }
};

To resolve these issues, you need to ensure that all required fields, including the notification method and recipients, are correctly filled out and validated. Additionally, verify that the initialization logic for old alerts correctly parses and assigns the recipients and notification methods ^[1][2].

To continue talking to Dosu, mention @dosu.

[akiellor]

It looks like this has been resolved in this Pull Request. But has not yet been released.

[Kim-frau]

Great, thanks

[Kim-frau]

Allready taken care in #28409