Item9300: Checker for WebMasterEmail could guess this from Apache SERVER_ADMIN variable

The Apache ServerAdmin email address could be used to guess the WebMasterEmail address. At least for people with a correct apache configuration, this would give a better chance of registration working from initial install.

• Update Foswiki.spec to default WebMasterEmail to 'NOT SET'
• Update Checkers/WebMasterEmail.pm to default to the apache $ENV{SERVER_ADMIN} if available and report as guessed, otherwise set to null for prior behavior.

This won't effect migrations, as the WebMasterEmail is either set, or set to prior default of null.

We could also add an entry for email address to the ApacheConfigGenerator. (But would be of limited value - only set if Virtual Host specified.)

-- GeorgeClark - 10 Jul 2010

If the checker sets (i.e. guesses) WebMasterEmail, then the warning will not be shown on subsequent views. I think that would be a problem. An admin new to Foswiki could easily miss the warning the first time (especially if there are many settings to attend to) and so the warning might not be seen at all.

I am not quite sure how to do it, but I suggest that:

• Foswiki should use $ENV{SERVER_ADMIN} (if available) if WebMasterEmail has its default value.
• The checker should warn if WebMasterEmail has its default value, and show what is being used instead (i.e. show the value of $ENV{SERVER_ADMIN}).
• The default value in Foswiki.spec should be different to a null value
  • so that (intentionally) setting it to blank does not trigger the warning, and
  • so that upgrading or migrating will not suddenly cause the use of $ENV{SERVER_ADMIN} when it was not used before.

-- MichaelTempest - 10 Jul 2010

From some IRC discussion. Since guessed status is lost after the first save:

• Change Foswiki.spec to default as SERVER_ADMIN
• Change Foswiki.pm to use $ENV{SERVER_ADMIN} if WebMasterEmail set to SERVER_ADMIN, - sets value of WIKIWEBMASTER macro.
  • Probably validate SERVER_ADMIN and only use if set and valid email
• Change checker to also warn if invalid SERVER_ADMIN and WebMasterEmail set to default.

-- GeorgeClark - 10 Jul 2010

Reverting these changes - it broke 60 tests that don't understand SERVER_ADMIN. Applications are using cfg{WebMasterEmail} directly, so this involves too much. If this will be done, then probably using the Checker to set a guessed email address is a better approach.

-- GeorgeClark - 10 Jul 2010

Yes, definitely. A checker is the way to go. The WebMasterEmail will often not be the SERVER_ADMIN, especially in a corporate setting, but it's a fine default.

-- CrawfordCurrie - 11 Jul 2010

There is still a way to avoid losing the fact that the WebMasterEmail value was guessed - add another flag to %Foswiki::cfg that stores this information. The flag would only be used by configure. If the checker guesses the value for WebMasterEmail then it sets the flag, and it can also clear the flag if the value changes (because the admin entered another address). The checker then uses the flag to trigger the "!WebMasterEmail is a guessed value" warning. configure renders the flag as a checkbox, and if the admin is happy with the guessed value, he/she may clear the checkbox to suppress the warning.

-- MichaelTempest - 11 Jul 2010

My gut feel is that this is getting too complicated. The default of empty for the WikiWebMaster email is simply wrong if not updated, and should probably be escalated to an Error status. (Even if e-mail is disabled, that field is rendered in topics in the Pattern Skin, so it needs to be set or invaild mailto:?subject=Foswiki Feedback on Main= ... links are created).

By guessing the field, it becomes something valid and looses its "guessed" status on the next save of the configuration. As Sven pointed out in Tasks.Item9237, there are other defaulted / guessed values that are not even warned to the user. So as a general issue, saving of guessed, unconfirmed values probably needs a more general solution well out of scope of a quick fix like this.

Possible actions:

1. Do nothing - default email to ''. Deal with occasional support requests - registration is not working... why.
2. Escalate to an error to encourage that the parameter be supplied.
3. Also add an error check to {Register}{EnableNewUserRegistration} that flags another error if the email settings are not complete?
4. Guess an email address from the Apache env, with the risk that the warnings gets overlooked/lost. (And as Crawford points out, will typically be wrong).
5. Add a new "guessed" flag to the setting to save a guessed status until cleared.

At this point in code freeze, I think it's best to do only option 2, and possibly 3.

-- GeorgeClark - 11 Jul 2010

Closing this with no action. Sven implemented option 2 in Tasks.Item9291.

-- GeorgeClark - 13 Jul 2010

Commenting is disabled while not logged in