Review Checklist

• Target branch (10.5 for bug fixes, others 11.x)
• Tests (if it's testable code, there should be a test for it - get help)
• Docs (every functionality needs to be documented, see here)
• Migration incl. install.sql (e.g. if the database schema changes, ...)
• Upgrade notes (deprecations, important information, migration hints, ...)
• Label
• Milestone

Resolved merge conflicts.

Hi @kjkooistra-youwe, thank you very much for this improvement, in general we really like it! We have couple of suggestions/questions, here they are:

1. Errors

• Upon creating/opening existing Select option definition in admin interface an exception is thrown (Message: trim(): Argument 1 ($string) must be of type string, null given)
• Used by class seems to be not working currently - probably because of the exception above

2. Questions

• What is the difference between the Display name and Name?

3. Improvements

• If I am correct, the definition for select options is currently stored in the JSON file. This could become performance demanding. We would suggest implementing LocationAwareConfigRepository with the write targets. Then it would be possible to define if these definitions should be stored in the DB or as the yaml file.

• It would be good to add possibility to localize Display name. (We should discuss this point in more detail before you would start working on it)

• In the class definition it would be good to add an extra select field (Something like Options provider type). Here we could have 3 options:

  • default option (pre-selected) - Selection Options table would be displayed, so user can add the options manually
  • custom options provider - hide Selection Options table and display Options Provider Class or Service Name and Options Provider Data fields
  • select options defnition - shows only the Select Options dropdown. Also when you select some option in this drop down it would be probably good that it stays pre-selected on the class definition re-load.

Let us know what do you think about these points. Would you have time and motivation to have a look at these? We really appreciate your contribution, thanks agian!

@lukmzig Thanks for your findings.

1. Errors
   I'll see if I can reproduce and fix it when I have some time.

2. Questions
   I copied the (multi)select field options configuration, so the Display Name is the same (the option label).

The enum cases are generated from the option values by default, but that doesn't work for certain special characters (√, for example). That's why an additional Name column was added, to be able to configure a valid (or custom) enum case. Also see the Check case in the documentation.

3. Improvements

• Definition: I'll look into it when I have some time.
• Localization: I saw this in the linked issue, but left it out on purpose, as it would make it even more complex. I would prefer to create the base setup first and then build further on that.
• Option provider type: this does make sense. Again, will look into it when I have some time.

@lukmzig I'm unable to reproduce the error. I would surely have noticed if creating/opening a definition would have caused an error. I updated the 11.x branch to the latest version. Can you provide more details on how to reproduce the issue? Or a trace where the trim is called?

Hi @kjkooistra-youwe, sure, seems like the exception is coming from here and it is thrown on definition load by call to the admin/class/get-select-options-usages

Trace:
in /var/www/html/dev/pimcore/pimcore/models/DataObject/SelectOptions/Definition.php:398
0 /var/www/html/dev/pimcore/pimcore/models/DataObject/SelectOptions/Definition.php(398): trim(NULL, '\')
1 /var/www/html/dev/pimcore/pimcore/models/DataObject/SelectOptions/Definition.php(384): Pimcore\Model\DataObject\SelectOptions\Definition->isConfiguredAsOptionsProvider(Object(Pimcore\Model\DataObject\ClassDefinition\Data\TargetGroup))
2 /var/www/html/dev/pimcore/pimcore/models/DataObject/SelectOptions/Definition.php(354): Pimcore\Model\DataObject\SelectOptions\Definition->getFieldsUsedInClass(Object(Pimcore\Model\DataObject\ClassDefinition), 'Class')

I did not do anything special except pulling your PR and adding a new definition. I also checked with my colleagues and they were able to reproduce this error as well. Let me know if this helped you or if we missed something.

@lukmzig Thanks. That makes sense, as those methods may return null. I'm not sure why the error didn't occur for me.

@lukmzig I updated the pull request, but the static analysis giving some errors now. I'm not sure where those are coming from though.

Fixed errors caused by changes in this commit: 9599390
Fixed merge conflicts.

@lukmzig As this pull request keeps gathering merge conflicts, can you give any indication on when it could be merged? I'd rather not keep fixing them indefinitely.

@lukmzig As this pull request keeps gathering merge conflicts, can you give any indication on when it could be merged? I'd rather not keep fixing them indefinitely.

Hi @kjkooistra-youwe, thank you for reaching out. Did you by any chance already have time to have a look at the improvements which were mentioned up? It would be quite important for us that they are resolved before we could merge your improvement.

In general, I am afraid we will not be able to merge this improvement before Pimcore 11 is released. For this reason, it is also not necessary that you resolve all conflicts right away.

@lukmzig Apart from the localization, the improvements were already implemented. Sorry for not indicating that more clearly.

I noticed similar settings are also configured in .github/ci/files/config/config.yaml. Should it be updated as well?

I noticed similar settings are also configured in .github/ci/files/config/config.yaml. Should it be updated as well?

Yes, this config is related to the codeception tests. You can add it there too to make it consistent with others. Thanks!

I noticed similar settings are also configured in .github/ci/files/config/config.yaml. Should it be updated as well?

Yes, this config is related to the codeception tests. You can add it there too to make it consistent with others. Thanks!

@kjkooistra-youwe Also, we can remove this file https://github.com/pimcore/pimcore/pull/14454/files#diff-f43ff01c1af018b3ee31fc731c951f862bf7024e87813487dc43090c24105b2b as we already moved it to thje admin-ui bundle

@kjkooistra-youwe

• 
  It would be nice to change this option label from 'Class / Service' to 'Options Provider'.

• 
  Could you please avoid the prefix 'Class' here so that it would be consistent with others (Field Collections)

It's also fine to add those in a follow up PR.

@aryaantony92

You can change the label in your PR https://github.com/pimcore/admin-ui-classic-bundle/pull/291/files#diff-b7044d81c8cbf9664c08384185ac516051a9235b8a234325bf22993531c1fc6b

The Class prefix was added on purpose to distinguish between field collections and classification store, for example. Otherwise it might become confusing when the same name is used.

@kjkooistra-youwe Could you please readd this file https://github.com/pimcore/admin-ui-classic-bundle/blob/2970bebcc20f21ccb0a5caa2110b0f9dbfb5fa20/src/OptionsProvider/SelectOptionsOptionsProvider.php to the core bundle https://github.com/pimcore/pimcore/tree/11.x/bundles/CoreBundle/src as the tests are failing and it should actually belong to the corebundle.

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
21 Code Smells

No Coverage information
0.3% Duplication

@kjkooistra-youwe great work 👏 It will be a highlight of v11.1. Thank you very much for co-operation as this took a bit time to review 😉

Also thanks to @aryaantony92, who migrated the interface changes to the admin-ui bundle.