Uploaded image for project: 'XNAT'
  1. XNAT
  2. XNAT-4260

Emails listed as recipients for certain types of notifications are overwritten by changing site admin email

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.7
    • Component/s: Admin UI
    • Labels:
    • Environment:

      xnat-dev05

    • Sprint:
      Prebeta push
    • Rank:
      0|ii0urj:
    • Sprint:
      Prebeta push

      Description

      I'm not entirely sure how this should work, but this is what I'm seeing:

      1. On a fresh dev server, enter an email on the setup page. Save
      2. Load Administer > Configuration > Notifications. The email recipients for Error messages, etc. should all match what was entered in step 1. This seems fine to me.
      3. Change the site admin email under Site Setup, and log out and back in.
      4. Return to the Notifications page. All of the emails now match the newly entered email.

      I think this is happening because the values in the siteConfig for things like notifications.emailRecipientErrorMessages are empty until you actually save that tab, so it simply displays a default value of the admin email. It seems correct to initially fill these values with the site admin, but if you change the site admin address, you probably don't want to nuke these notification emails. So, a possible fix would be instead of defaulting to the site admin, to explicitly set the value for these notifications emails to the site admin email in the site init process.

        Activity

        Hide
        moore.c@wustl.edu Charlie Moore added a comment -

        Also: tag: Justin Cleveland

        Show
        moore.c@wustl.edu Charlie Moore added a comment - Also: tag: Justin Cleveland
        Hide
        mfmckay@wustl.edu Mike McKay (Inactive) added a comment -

        Charlie, I respectfully disagree. I intentionally designed it to work this way. I don't think admins should have to worry about notifications unless they specifically elect to. By default, emails should just get sent to the admin email. When they change their admin email, I think they would expect for their new email to receive such emails unless they have monkeyed with the notifications. However, based on the way we do bulk updating of preferences (one thing I think we should change is to only invoke set on things you're changing), the notifications recipients might get stuck on an old admin email even without specifically changing the recipients (though I have not verified this). So if anything, I think the bug is in the other direction.

        Show
        mfmckay@wustl.edu Mike McKay (Inactive) added a comment - Charlie, I respectfully disagree. I intentionally designed it to work this way. I don't think admins should have to worry about notifications unless they specifically elect to. By default, emails should just get sent to the admin email. When they change their admin email, I think they would expect for their new email to receive such emails unless they have monkeyed with the notifications. However, based on the way we do bulk updating of preferences (one thing I think we should change is to only invoke set on things you're changing), the notifications recipients might get stuck on an old admin email even without specifically changing the recipients (though I have not verified this). So if anything, I think the bug is in the other direction.
        Hide
        mfmckay@wustl.edu Mike McKay (Inactive) added a comment -

        And Charlie Moore, if you know of any other issues related to AdminUI functionality not working as expected, can you at least tag me in them since it's probably something I've worked on?

        Show
        mfmckay@wustl.edu Mike McKay (Inactive) added a comment - And Charlie Moore , if you know of any other issues related to AdminUI functionality not working as expected, can you at least tag me in them since it's probably something I've worked on?
        Hide
        moore.c@wustl.edu Charlie Moore added a comment -

        Mike, could we then just leave these fields blank by default? You have that line in the descriptions for these that if left blank, they default to using the site admin, so that would be clear from a user perspective as to what's going on.

        Show
        moore.c@wustl.edu Charlie Moore added a comment - Mike, could we then just leave these fields blank by default? You have that line in the descriptions for these that if left blank, they default to using the site admin, so that would be clear from a user perspective as to what's going on.

          People

          • Assignee:
            moore.c@wustl.edu Charlie Moore
            Reporter:
            moore.c@wustl.edu Charlie Moore
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Agile