There are several related issues to track down for this. But the issue relates to whether or not to move the "Existing" plugin earlier in the priority chain.

We want Features that have been manually created/edited to keep their assigned config. Right now this is handled by adding the "Required:..." list of required config to the features.yml file.

However, we don't want to duplicate the list of config files from /config/install into the features.yml file like we did in D7's info file.

My proposal is to add an option for marking a Feature as "locked" or "required-all" where any yml file in the config/install directory is required. This would prevent config assigned to the feature from moving to another feature because of a change in assignment plugin. But it wouldn't be as drastic as moving the "Existing" plugin early in the list. Features that have not been marked would still freely allow config to assign to other features as plugins are changed.

I'd propose that a checkbox for this is added to the Edit page for the Feature and is automatically enabled so a Feature exported from the Edit page becomes "locked". Features exported from the main page would not be locked.

The word "locked" is probably not a good one since D7 had the different concept of a "locked feature that prevents reverting". So I'm open to other terminology here.

Marking this as "Major" because it solved several other issues marked as major in perhaps a cleaner way. Also would affect several issues regarding "conflict" and "missing" config status.

Comments

mpotter created an issue. See original summary.

mpotter’s picture

Status: Active » Needs review
StatusFileSize
new4.53 KB

Here is a patch for testing.

It handles a couple of things:

1) If "required: true" is in the module.features.yml then all config is marked as "required", both when creating the Edit form and also when running the Package assignment plugin.

2) When writing a feature from the Edit page, if all the required config is exported, it writes "required: true" instead of listing all the config directly.

mpotter’s picture

Status: Needs review » Needs work

Hmm, once an export is marked as "required: true" there is no way to unmark that to return the package to a "fluid" state that can be affected by other plugins.

Probably need to add a checkbox on the Feature Edit page.

mpotter’s picture

Status: Needs work » Needs review
StatusFileSize
new5.02 KB

OK, here is an updated patch. It adds a checkbox for "Mark all config as required". If this is checked, "require: true" is exported, otherwise the normal required list is exported. This box is checked by default if it sees "required: true" in the package, or if the required list contains the full list of config from the package.

Status: Needs review » Needs work

The last submitted patch, 4: features_required_all-2691625-4.patch, failed testing.

mpotter’s picture

StatusFileSize
new5.05 KB

Tests were failing when running manually due to the new array_diff. Here is an updated patch that passes tests locally.

mpotter’s picture

Status: Needs work » Needs review
mpotter’s picture

Yeah, tests pass now!

mpotter’s picture

StatusFileSize
new5.4 KB

Here is a version that creates a helper function in Package to determine if required-all should be enabled.

  • mpotter committed 9711bb0 on 8.x-3.x
    Issue #2691625 by mpotter: Add option to mark a feature as "Required:...
mpotter’s picture

Status: Needs review » Fixed

Committing this so I can test some other related issues. 9711bb0.

Status: Fixed » Closed (fixed)

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