Define what to do when a configuration file is deleted [#1706650]

Problem/Motivation

Users can accidentally or intentionally delete a configuration file without use the UI.

We should define what to do when users click on "Check for new configurations".

Proposed resolution

There are several alternatives:

Stop tracking the configuration.
Mark the configuration as overriden.
Create an special status for this configurations and let the user choose.
Create an UI that allows to choose what to do with each configuration.
Other?.

Remaining tasks

Code the solution.
Write tests

User interface changes

Depends of the solution adopted.

API changes

@TODO

Comments

Comment #1

dragonwize commented 31 July 2012 at 17:59

If a tracked config gets deleted or removed, by purpose or accident, the tracking of that config should be stopped.

If the config was not being tracked, ie. migrated, nothing happens.

@dragonwize
Related to this.. what happens if the file gets updated.. perhaps in a scenario where you are keeping the configurations files on a subversion service and you do a revert or something like that. In that case the hash in the config.export file will not match the inc file or the cache... just wondering about that

Comment #3

lucascaro commented 31 July 2012 at 18:25

@GDrupal if you change the configurations within a file, you can go to admin/config/system/configuration/settings and click on "Check for new configurations" and the changed configurations will be marked as "Datastore Changed" in admin/config/system/configuration (that's how this already works). for other cases, see #1701816: [META] Test all the features of this module