Problem/Motivation
It will sometimes be necessary to override/customize the automatic assignment that plugins do, by explicitly adding an item to a given feature. Such overrides should persist when features are regenerated. This would be equivalent to the parallel case that's already implemented: the 'excluded' array. See work completed in #2595245: "excluded" configuration should not be automatically packaged.
This is a blocker for #2490888: 'existing' assignment plugin runs too early.
Proposed resolution
In the 'packages' assignment plugin, iterate through features info array and test for $info['features']['required']. If not empty, iterate and assign required items to the feature.
Add handling to the feature edit form parallel to the existing method for excluding components from a given feature. In the code base, 'excluded' and 'required' are referred to as constraints. Handle the interaction between these to flags in a toggling way, such that only one of the two flags can be set at a given time for a given item and toggling the item's selected status either removes any existing constraint or adds the appropriate constraint. Specifically:
- When an item that was previously unselected is selected:
- If it was previously excluded, set it as no long excluded.
- Otherwise, set it as required.
- When an item that was previously selected is unselected:
- If it was previously required, set it as no long required.
- Otherwise, set it as excluded.
Comments
Comment #1
mpotter commentedIn Features D7, the features_exclude tag in the info file got a bit messy. You essentially had info features[] controlling "force include" and the features-exclude[] for "force exclude". For a normal feature that you want to fully manage, you really just want to fix the config that is assigned. You don't really want to list "all other possible config" in the "exclude" array.
While I think we *do* still need a "force include" and "force exclude" flag, I think the majority of dev-created Features could also be controlled with a simple "lock" flag. The "lock" flag would simply use the existing config in the config/install directory as the only config in the package. No other config would get auto-assigned, and none of the existing config would be unassigned. The dev would be responsible for manually adding/removing config items from the package.
Comment #2
nedjoMove to Features.
Comment #3
nedjoComment #4
nedjoComment #6
nedjoComment #7
nedjoUpdated summary with the solution as implemented.