Details
-
Bug
-
Resolution: Done
-
Neutral
-
None
-
None
Description
As described below it could be a case that e.g. a select field had a value type configured as Long, however, no converter specified. The underlying JCR back-end would handle that correctly (would convert select's internal string value to Long and would store it appropriately). 6.2 fields have a similar logic actually (see JcrItemPropertySet implementation), but we still bail out from attempting to convert such cases in AbstractConfiguredFieldDefinitionConverter:
if (oldDefinition.getConverterClass() == null && oldDefinition.getType() != null && !oldDefinition.getType().equals(PropertyType.TYPENAME_STRING)) {
if (!supportsType(oldDefinition.getType())) {
log.error("No converter set for non-String field:" + oldDefinition.getName() + ": " + oldDefinition.getType());
return false;
}
log.debug(oldDefinition.getType() + " type is used in definition " + oldDefinition.getName() + " without proper converterClass.");
}
Can we just let it slide if the values are primitives?
The example case:
Option group field conversion is failing in dialogs. To see an example, open the pages app and go to the page /travel/contact. Click the main section, scroll down the page to the email field. Edit the field.

Checklists
Attachments
Issue Links
- is duplicated by
-
MGNLUI-6052 OptionGroupFieldDefinition not working when using 6.1 style component definition
-
- Closed
-
- is related to
-
MGNLFORM-318 Validator names in form fields unreadable (and so almost unusable)
-
- Closed
-
- relates to
-
MGNLFORM-320 Static field converter
-
- Closed
-