Settings export/import

Contribute Bug

AI-generated summary

The discussion revolves around issues with the site_settings:import rake task in a forum. RGJ encountered an error when importing settings due to a dependency between sso_overrides_email and email_editable. To resolve this, RGJ proposed four possible solutions:

  • Running the import task twice
  • Exporting settings in updated_at order
  • Having the rake task run the import twice
  • Disabling checks when importing from a file

However, RGJ and sam agreed that simply running the task twice is not a trivial solution, as it requires handling multiple dependencies, error catching, and implementing a clean rollback mechanism. sam suggested running the task twice, but with the second run in batch mode, and bailing out if any errors occur.

1

Nothing really big, but I ran into a small issue using site_settings:import and it bit me hard.
There is an easy 'n ugly workaround (run the rake task twice) but this is typically something that is being run unattended so I did not see the error at first.

(Part of) exported settings file (site_settings:export)

sso_overrides_email: 'true'
email_editable: 'false'

Importing that file into another forum:

ERROR: sso_overrides_email: You must disable 'email editable' before enabling this setting.
Changed email_editable FROM: t TO: false

The second run does of course pick up the setting:

Changed sso_overrides_email FROM: f TO: true

Possible solutions:

  • Live with it and just run the import rake task twice
  • Export settings in updated_at order
  • Have the rake task run the import twice
  • Disable this kind of checks when importing from a file
3 Likes
2

Which solution do you think makes the most sense?

3

I’m not sure.

will work, does not take too much of an effort, and is most logical, but will still fail if additional restrictions are implemented after the settings were made.

will work but will not make sense to people,

is really ugly, but works

might introduce all kinds of nasty things and might take a lot of effort.

2 Likes
4

I don’t think this will work.

Simplest to me is just running this twice and if it errors the second time around bail out.

That said, it is not as trivial as “running twice”

  1. You run it the first time, catching errors on any particular setting you set
  2. Second time you just run it in a batch and bail out if anything fails

If we are already handling this mess we got to handle cases where there are multiple dependencies going on.

There is also the question of clean rollback, so this is not a trivial task at all.

2 Likes