noreplyaddress config directive not picked up into database config table

[Scott Korvek]

I am using Mahara 1.3.3 clean install on shared hosting with inmotionhosting. Everything works, but my emails sent by mahara are getting blocked. I had the same problem with my moodle installation, but was able to configure it with SMTP email and a defined, working noreply address. However, this is not working with mahara.

I have defined the cfg->noreplyaddress directive and ensured it's pointing to the correct address. However, in the database config file, it wasn't picked up, instead pointing to <email address hidden> (I use subdomains to separate the various applications on the server) which was the default probably put in before I set it in the config file myself. So I changed the config file back to match what's in the database, again checking all the credentials, authentication, and that that email address can send/receive mail.

So I created several dummy accounts with any other email address I have, and it works on the user creation on roaming over via mnet and I get the email with the correct noreply setting.

The database didn't pick up a noreplyaddress change in the config, and instead kept the original value. Once I made the database and the config file match, all was ok. But I shouldn't have to have gone digging into the database once fixing the config file-- so that's a bug.

Forum post with full details: http://mahara.org/interaction/forum/topic.php?id=3110#post13442

[François Marier (fmarier)]

I guess we need to decide which of these have precedence when they're not the same:

1- the address in config.php
2- the address in the database

Or perhaps we should remove one of them (probably the config file one) and only have a single place where this can be set. Mahara could issue a warning when the other one is set.

What do you think?

[Ruslan Kabalin (rkabalin)]

IMHO it should be possible to set these settings from the config file and config file should have precedence over DB settings. I assume here that DB settings will have configuration interface in the site options (like we discussed concerning email settings, see bug #670683).

I will try to explain why I think so. Basically we have three types of mahara users (or rather owners):
    * new ones who do not care where email is configured - in DB or in config
    * old users who already have their settings in config.php
    * old and new users that for some reason want to control these settings from config file (e.g. multiple instance deployment with config-managed configuration)

In the case of new users, given that we do not force them to configure email settings (including no-reply address) in the config file (they are commented out by default), it will be easier to persuade them to fill in relevant settings fields after installation (add additional after-install screen asking to set up email), so email configuring bit can be changed accordingly in installation docs and these users will never need to care about adding email setting to config file (unless they need that for specific reason).

Users who already have their settings in the config file should be informed that now it is possible to configure the same using the interface, but to do that, email configuration should be removed from config file (they may see greyed out filled-in settings in configuration interface with explanation that they are imported from config file, but you can't change them in the interface until they exist in the config file).

Those who want to maintain the settings using the config file for some reason, may continue doing so, config setting will always win and rewrite what is stored in the database, configuring the same using the interface will not be possible.

[François Marier (fmarier)]

You're making a good point about settings migrating from config.php (where they typically tend to start their life) to site options. I like your idea of graying them out to provide a visual clue that the DB setting will be overriden by config.php.

In order words, when an option can be set both in config.php and in site options:

1- the config.php option takes precedence
2- if it's set in config.php, the site options setting is grayed out and set to the config.php value

[Richard Mansfield (richard-mansfield)]

I believe the config.php override and greying out was already done some time ago by Lorena in bug #548084, though there's a bit of duplication in that commit that could probably be tidied up.

[Richard Mansfield (richard-mansfield)]

Er, commit a6f274234ca8466baa715b559a7c75475664467d I mean.