feat(lexicon): configurable presets

[ArtificialOwl]

Required for: #51804

status: review ready.

• adding closure to the $defaultRaw parameter from ConfigLexiconEntry to set default value based on selected Preset in config.php using 'config_preset'

new ConfigLexiconEntry('key3', ValueType::STRING, fn (Preset $p): string => match ($p) {
				Preset::FAMILY => 'family',
				Preset::CLUB, Preset::MEDIUM => 'club+medium',
				default => 'none',
			}, 'test key'),

• ./occ config:preset [<new_preset>]

[nickvergessen]

Moving my technical comment to the Draft PR, as the issue is more focused on the "content".

---

I'm not a fan of the approach proposed here and in #51804 (comment) as it's very focused on server and shipped apps.
We need to have the modes given as a constant and should then have a way for each config in it's Lexicon to have a different fall back, so this can be properly done by non-shipped apps as well.
The nested PHP array in a simple file is way to dangerous to have a typo or something sneak in.

So from my POV the "presets" should be handled on each individual entry of the ConfigLexiconEntry with an optional defaultPresetArray array parameter that has the preset name as key and the respective default as a value.

This also allows apps to properly define the config keys within their app without having to wait for a server release, etc. which is very important for apps being released independently or spanning over multiple different server versions.

[ArtificialOwl]

I'm not a fan of the approach proposed here and in #51804 (comment) as it's very focused on server and shipped apps. We need to have the modes given as a constant and should then have a way for each config in it's Lexicon to have a different fall back, so this can be properly done by non-shipped apps as well.

I really like this idea, but I would like to advocate for both solution. with a priority on the PHP array.

• We keep the ability for anyone to create it's own preset.
• App's metadata is not to be defined by the app itself:
  • Feature like app enabled by default will require Lexicon to be loaded, meaning the app to be enabled,
  • You can initiate the download of the app at preset selection,

The nested PHP array in a simple file is way to dangerous to have a typo or something sneak in.

We could run a check on request (when a new preset is selected, background job, via occ command)

So from my POV the "presets" should be handled on each individual entry of the ConfigLexiconEntry with an optional defaultPresetArray array parameter that has the preset name as key and the respective default as a value.

This or a new specific method in IConfigLexicon called by AppConfig/UserConfig when a Get on a config key has no known config value; instead of loading additional data. Or we don't mind always loading all config values for all presets ?

This also allows apps to properly define the config keys within their app without having to wait for a server release, etc. which is very important for apps being released independently or spanning over multiple different server versions.

We can assume that a change of value type means a change of the key name.

[nickvergessen]

We keep the ability for anyone to create it's own preset.

This is/was not the main idea of the presets. If you want to share a subset of your configuration you can already do that by simply creating a JSON and importing it with occ config:import

Feature like app enabled by default …

This is and should be controlled by server, so the preset from app's side don't need to handle this.

Or we don't mind always loading all config values for all presets ?

Default could be a callback that receives the preset?

We can assume that a change of value type means a change of the key name.

We are not speaking about config type changes, but let's say Talk introduced a new config in the Summit release first week of June (and we actually had 4), we would need to require people to update server first/as well, before the matching defaults would be available.
That would be a very bad trade-off.

The main goal is to assist admins with a good experience and developing an own preset is not one of them. It's more important that apps can provide good/sane defaults for known cases out of the box, without having to take loops through server releases.

[ArtificialOwl]

@nickvergessen : I changed the approach

Preset are an Enom and the syntax will use its own method:

(new ConfigLexiconEntry('my_key', ValueType::STRING, 'default'))->preset(ConfigLexiconPreset::FAMILY, 'default_family'),

First argument can be an array of ConfigLexiconPreset and we only keep the default for current preset,

The only thing I am not sure is the use of defined constant to set in store the preset stored in the system config value. (switched to a public static value)

[ArtificialOwl]

@nickvergessen beside the dot (.) in the config key, do you agree more on that new implementation of the feature ? :-]

[nickvergessen]

Yeah it goes into a better direction now. Can improve the coding experience a bit more :)

[ArtificialOwl]

@nickvergessen what about having a second parameter as reference in the Closure that store the returned value in database if set to true ?

	new ConfigLexiconEntry('key5', ValueType::STRING,
		function (ConfigLexiconPreset $p, bool &$store): string {
			$store = true;
			return md5(random_bytes(15));
		},
		'test key'
	),

instead of using onSet() intialize() in #53619

[nickvergessen]

Hmm not sure, I see how it could save calculation efforts, but increases complexity again.
Do we have usecases of complex types (arrays) in app config atm where the default array should be different depending on the preset?
At least in talk we don't have anything alike. The most preset changes are simply booleans (feature toggles) or small-ints (level selection for permissions).

All arrays don't have a default that'd depend on preset, most are empty by default.

[nickvergessen]

Some comments about the command, otherwise it looks good to go

[ArtificialOwl]

Some comments about the command, otherwise it looks good to go

can you please remove your change request ? ;-)

[nickvergessen]

LGTM