After reading the documentation on 'Installing or Updating Open Atrium' at https://drupal.org/node/2169701, I and understand the problem and what Features Overrides tries to addrees, but I have a couple of doubts on the matter:

1) NOT using Features Overrides

That means redoing all the custom done to the previous OA2 version from notes made when doing the configuration, and once executing the command 'drush fra -y'.
What I can not understand is why you do not get the same features override list (drush fl) when you compare the initial fresh installation with the same customized installation with reverted features (drush fra -y). There are features overridden in a fresh installation, that are not any more when the 'drush fra -y' is done on the customized installation.
Is that an issue to worry about?

2) Using Features Overrides

In this case, before reverting all the overrides by using 'drush fra -y' on the customized installation, those overrides must be saved to a module. The question is which components of the 'features_override_items' component list must be chosen. If choosing all by doing:

drush fe oa_custom features_override_items --version-set=7.x-1

then doing a revert (drush fra -y) and finally enabling the oa_custom module previously produced, that seems to work, but you can see at the features page (admin/structure/features), that some are flagged as "Needs Review".
Is that a problem? Which is the best plan to saving overrides? I can not see an easy way to produce modules for saving overrides each time you modify features on your installation

Comments

olak’s picture

+1

JKingsnorth’s picture

I'm sure #2 (using Features override) is the right way forward, as it says in the documentation page you link to.

Manually recreating all customisations would be very painful indeed.

I cannot comment on why some features would be 'Needs review' though. Presumably this isn't a problem, and they 'Need review' because they are being overridden?

mpotter’s picture

You definitely want to do #2 if you want to be able to apply distribution updates in the future.

This is a relatively new thing in Drupal. In the past, distributions were used more as a starting point for custom builds and few people worried about doing future distribution upgrades. Open Atrium 2 is more of a product that is continually improving and now people want to be able to keep on the path and apply upgrades.

This is what the Features Override module was designed to allow you to do. Without Features Override it's a very manual and difficult process and you can easily lose your site customizations.

However, Features Override is still in Beta and might still have issues like the Needs Review issue. This is also why the panopoly_users and oa_panopoly_users (and oa_worktracker) features are shown as overridden as they all try to use Features Override to override the same thing. So this is a very complex issue with no completely perfect answer. This won't cause any actual problem using your site as long as you are aware of what features are overridden.

You can also use commands like "drush fd feature-name" to capture the specific differences of a feature to document changes. Capturing the output of "drush fd feature-name" and writing it to code hooks is essentially what Features Override is trying to do.

All I can say is like with any site upgrades: Make good backups, and keep good track somehow of the changes you are making to your OA2 site.

Argus’s picture

Status: Active » Fixed

I hope your question is answered. Please reopen if needed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.