Select/multiselect data types with localized and centralized select options

[markus-moser]

Select/multiselect fields only support a single value and label for one selected option and the provided select options need to be defined directly in the class editor (if no options provider is used). There a several problems with this approach in many projects:

• In many constellations it's important to localize the selected value. It's possible to do this via website translations with a special naming scheme (e.g. optionsvalue.my-option). But this could be quite challenging and a lot of work in a PIM system with hundreds of attributes and thousands of attribute values.

• Sometimes the same select options need to be used in different fields. For example when object bricks are used for different product categories the same field could be needed in two different bricks with the same options.

• Often some users should have the right to maintain the provided select options (add new ones etc.). At the moment this is only possible when the user is allowed to use the class editor which is quite dangerous.

It's possible to use a options provider to create solutions for these kind of problems but a more standardized and out of the box way would be a really good improvement as option providers have several limitations:

• It's more work to create option providers than to use a good standard feature. :-)

• Export/import/grid view works not that perfect. A good out of the box solution could provide good solutions for that. For example with a special operator which can export the translated value. The grid view itself could show the translated value in the right language etc.

• If combined with Pimcore's output channel bundle (https://github.com/pimcore/output-data-config-toolkit) things become really nasty when using option providers.

Therefore I suggest a solution similar to this:

1. Add a global "Select options" section similar to for example the classification store group/key definitions. There it might be possible to define for example select value groups and within the groups localized select values. A new user right can be added to define who is allowed to edit the select options.
2. Add 2 new data types for select/multiselect based on these select options and groups. In the class editor of the data type the used select options group needs to be configurable.
3. Add grid view operators for the new data types.

[dpfaffenbauer]

Isn't that a bit overkill for just selects? Why not use something like https://github.com/coreshop/CoreShop/blob/master/src/CoreShop/Bundle/PimcoreBundle/CoreExtension/DynamicDropdown.php where the select value is from another Object?

[markus-moser]

I have done it similarly to that in several projects. But remember a data model with 400 select/multiselect attributes in 20 object bricks. It would get really big and additionally it's not that easy to create for example a CSV exporter via the object grid. I think the dynamic dropdown is the overkill for this kind of problem. I have the same situation in nearly each PIM project with a lot of attributes.

[dpfaffenbauer]

👍 ok, the export/import argument makes sense to me ;)

The 400 attributes in 20 bricks would be easy with the DynamicDropdown. But that also depends on the use-case. In my projects, the "href" solved with the DynamicDropdown has other attributes like a image as well.

[markus-moser]

Yes I know the situation with images and other attributes needed. The dynamic dropdown is a good solution for that. The 400 attributes in 20 bricks are possible too for sure but the (for example memory consumption) overhead would be quite big.

[JonasWinter]

Is there any chance this will be shipped with the product one day? 😕

[fashxp]

fixed via #14454