Can we move the "settings.yml" into the database?

[volkanunsal]

I seem to recall there was a discussion on this, but I forget what was decided. I think it would add a lot of flexibility to the app, and allow the admins to have full control of the setting from the web interface. It's also necessary to change the valid_service_areas during the onboarding process in order for the service uploads to work and the only way for that to work is if this value was stored in the database.

[monfresh]

I'm not quite sure what you mean by "the only way for that to work is if this value was stored in the database." Before you can upload data, some initial setup is required during installation, including making changes to settings.yml. The app does not require you to have valid_service_areas. If you don't want to validate the service areas in your data, you can just delete the default values in settings.yml. If you do want to validate them, then you will need to update the values to suit your needs before uploading your data.

All that's required to be able to upload services is to either update or delete the default valid service areas in settings.yml. I'm not convinced that storing settings in the database would make that much easier.

In a typical installation, settings.yml will rarely change after initial setup, so to me, it doesn't make sense to add complexity in order to make it slightly easier to update settings that will only occasionally change. However, I'm open to hearing more convincing arguments that clearly show how storing settings in the database is a much better solution that is worth the additional development effort.

[volkanunsal]

In that case, can we remove at least parts that are blocking a smooth web-based onboarding? The default valid_service_areas from settings.yml is causing the Services to fail due to not having a valid service area. Second, admin_support_email and confirmation_email are hardcoded as [email protected]. This is an app specific setting and should it not be in application.yml? That way they can be configured from app.json file's environment variables.

[volkanunsal]

I almost forgot the bounds. That's another one that could be in application.yml.

[monfresh]

By web-based onboarding, do you mean Heroku deployment?

The app is not meant to be deployed as is with the default settings. Part of the installation process is properly configuring application.yml and settings.yml. If your data includes the service_areas field, and if you don't modify the valid service areas prior to uploading your data, you will get a validation error. That is expected behavior.

If your data includes service_areas, it is recommended that you validate the values, which is why settings.yml has default values as opposed to being empty by default. The default values in settings.yml are there so that the demo app works as expected. If we wanted to make valid_service_areas empty by default (which would not be recommended), we could make them empty in settings.example.yml, but as part of the installation process, you would need to overwrite settings.yml with the contents of settings.example.yml. However, if disabling the validations is what you really want, you can simply remove the default valid_service_areas values in settings.yml.

The bottom line is that you must properly configure application.yml and settings.yml before you can continue installing the app and upload your data. This would be the case whether the settings are stored in a YAML file or in the database. Either way, you would have to modify the default valid service areas.

As for settings like bounds, they cannot be in application.yml because environment variables can only be strings, and bounds needs to be an array. The email settings could go in application.yml, but I'd like to test the scenario where the value contains multiple emails.

[volkanunsal]

Yes, I mean Heroku deployment via app.json schema.

If your data includes the service_areas field, and if you don't modify the valid service areas prior to uploading your data, you will get a validation error. That is expected behavior.

I get everything you're saying. I don't think this field has to be empty by default, but why can't the valid_service_areas field be, say, a comma separated string stored in an environmental variable, so that it could be overwritten by the user without modifying the code? This would solve a major source of errors for me. The validation errors from the Service is the biggest problem to seeding the data for an app.json deployment. In this process, I cannot overwrite the settings.yml. I can only work with ENV values.

[monfresh]

Storing valid service areas as a comma-separated string would make the values much less convenient to read and edit when you have many service areas.

How are you currently allowing the user to modify the ENV values? Can't you just create a new web page in the onboarding process that updates the values in settings.yml? Your original request in this issue was to store settings.yml in the database so that you could change it during the onboarding process. That leads me to believe you were planning on having some sort of GUI that could update the settings. If that's the case, the settings don't have to be stored in a database. You can just write code that updates the settings and writes them back to settings.yml, something like this: http://stackoverflow.com/questions/13948951/update-value-of-key-of-a-yaml-file-in-ruby-on-rails

[volkanunsal]

That would be fine on anywhere but Heroku, which has a read-only file system.