Grails

Add smart field rendering tags (like bean-fields plugin)

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 2.3-M2
  • Component/s: None
  • Labels:
    None

Description

The bean-fields plugin (http://grails.org/plugin/bean-fields) provides tags that render input fields smartly, namely doing the following:

  • Rendering HTML <label> for the field with the appropriate attributes, and text from i18n or fallback to convention
  • Rendering fields errors inline by the field
  • Rendering of customizable "required" indicator
  • Customization of the layout of these decorated input fields using a template mechanism, where templates are retained for the duration of the request and can be modified during request processing
  • Rendering fields according to the constraints on the command/domain object, where possible.
  • Smart selection of HTML markup to use based on field type
  • Simple rendering of edit fields for list of properties of an object with one tag

The plugin is well established and provides the basis for the work but there are some suggestions for improvement when pulling into core:

  • Adapt to use Grails naming conventions for field labels
  • Make it easier to define templates, preferably with named stylings/suites of templates. e.g. an artefact with a simple DSL for defining the GSP fragments, so that a form can specify templateName="standardForm" or similar, and all the field templates will be loaded from that suite. Something like this will improve performance also over using g:render to render common GSP that sets up the templates.
  • Improve performance where currently it delegates to existing grails tags, it may be a lot better to use functions in the grails taglibs and have the regular field tags call these also (rather than multiple tag invocations)
  • Examine retro-fitting this functionality to some or all of the existing field tags, such that when the beanName attribute is specified, it switches to smart behaviour. This would prevent a proliferation of similar tags. I think these tags should be in the "g" namespace, and this would avoid such problems. Most of the bean tags delegate to grails tags anyway so the attributes are largely orthogonal
  • Fix the naming/paradigm for overriding "required indicator" when rendering fields, there is confusion about how to force a field to appear mandatory, and I have never been happy about this requiredField attribute name. Look at adding "required" attribute to override required or not, and "requiredIndicator" to override the default required indicator (note the presence of "constraints" attribute override means you can achieve this currently with dummy constraints)
  • Issues with input field not having a template in the same way as other field types

Issue Links

is depended upon by

New Feature - A new feature of the product, which has yet to be developed. GRAILS-4094 Make GSP-Field-Tags aware of Domain-Classes

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

New Feature - A new feature of the product, which has yet to be developed. GRAILS-270 Required fields should be automatically displayed in the pages with visual indication

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Marc Palmer made changes -
Field Original Value New Value
Description The bean-fields plugin provides tags that render input fields smartly, namely doing the following:

* Rendering HTML <label> for the field with the appropriate attributes, and text from i18n or fallback to convention
* Rendering fields errors inline by the field
* Rendering of customizable "required" indicator
* Customization of the layout of these decorated input fields using a template mechanism, where templates are retained for the duration of the request and can be modified during request processing
* Rendering fields according to the constraints on the command/domain object, where possible.
* Smart selection of HTML markup to use based on field type
* Simple rendering of edit fields for list of properties of an object with one tag

The plugin is well established and provides the basis for the work but there are some suggestions for improvement when pulling into core:

* Adapt to use Grails naming conventions for field labels
* Make it easier to define templates, preferably with named stylings/suites of templates. e.g. an artefact with a simple DSL for defining the GSP fragments, so that a form can specify templateName="standardForm" or similar, and all the field templates will be loaded from that suite. Something like this will improve performance also over using g:render to render common GSP that sets up the templates.
* Improve performance where currently it delegates to existing grails tags, it may be a lot better to use functions in the grails taglibs and have the regular field tags call these also (rather than multiple tag invocations)
* Examine retro-fitting this functionality to some or all of the existing field tags, such that when the beanName attribute is specified, it switches to smart behaviour. This would prevent a proliferation of similar tags. I think these tags should be in the "g" namespace, and this would avoid such problems. Most of the bean tags delegate to grails tags anyway so the attributes are largely orthogonal
 The bean-fields plugin (http://grails.org/plugin/bean-fields) provides tags that render input fields smartly, namely doing the following:

* Rendering HTML <label> for the field with the appropriate attributes, and text from i18n or fallback to convention
* Rendering fields errors inline by the field
* Rendering of customizable "required" indicator
* Customization of the layout of these decorated input fields using a template mechanism, where templates are retained for the duration of the request and can be modified during request processing
* Rendering fields according to the constraints on the command/domain object, where possible.
* Smart selection of HTML markup to use based on field type
* Simple rendering of edit fields for list of properties of an object with one tag

The plugin is well established and provides the basis for the work but there are some suggestions for improvement when pulling into core:

* Adapt to use Grails naming conventions for field labels
* Make it easier to define templates, preferably with named stylings/suites of templates. e.g. an artefact with a simple DSL for defining the GSP fragments, so that a form can specify templateName="standardForm" or similar, and all the field templates will be loaded from that suite. Something like this will improve performance also over using g:render to render common GSP that sets up the templates.
* Improve performance where currently it delegates to existing grails tags, it may be a lot better to use functions in the grails taglibs and have the regular field tags call these also (rather than multiple tag invocations)
* Examine retro-fitting this functionality to some or all of the existing field tags, such that when the beanName attribute is specified, it switches to smart behaviour. This would prevent a proliferation of similar tags. I think these tags should be in the "g" namespace, and this would avoid such problems. Most of the bean tags delegate to grails tags anyway so the attributes are largely orthogonal
Hide
Permalink
Graeme Rocher added a comment -

+1 but I think we should keep it as a separate "required" plugin that way we can fix any issues outside the lifecycle of Grails itself

Show
Graeme Rocher added a comment - +1 but I think we should keep it as a separate "required" plugin that way we can fix any issues outside the lifecycle of Grails itself
Hide
Permalink
Marc Palmer added a comment -

Things I've remembered that is problematic in bean fields that need tweaking:

  • use of "requiredField" to set per-field required indicator. To suppress indicator you have to set this to a blank string, naming is ambiguous. Add "requiredIndicator" for the string used, and "required" for flag indicating to show or not
  • input field does not have a customizable template
  • Look at possibility of using the body of the tag as the field template, so you can write ad-hoc templates inline.
Show
Marc Palmer added a comment - Things I've remembered that is problematic in bean fields that need tweaking: use of "requiredField" to set per-field required indicator. To suppress indicator you have to set this to a blank string, naming is ambiguous. Add "requiredIndicator" for the string used, and "required" for flag indicating to show or not input field does not have a customizable template Look at possibility of using the body of the tag as the field template, so you can write ad-hoc templates inline.
Marc Palmer made changes -
Assignee Marc Palmer [ wangjammer5 ]
Marc Palmer made changes -
Description The bean-fields plugin (http://grails.org/plugin/bean-fields) provides tags that render input fields smartly, namely doing the following:

* Rendering HTML <label> for the field with the appropriate attributes, and text from i18n or fallback to convention
* Rendering fields errors inline by the field
* Rendering of customizable "required" indicator
* Customization of the layout of these decorated input fields using a template mechanism, where templates are retained for the duration of the request and can be modified during request processing
* Rendering fields according to the constraints on the command/domain object, where possible.
* Smart selection of HTML markup to use based on field type
* Simple rendering of edit fields for list of properties of an object with one tag

The plugin is well established and provides the basis for the work but there are some suggestions for improvement when pulling into core:

* Adapt to use Grails naming conventions for field labels
* Make it easier to define templates, preferably with named stylings/suites of templates. e.g. an artefact with a simple DSL for defining the GSP fragments, so that a form can specify templateName="standardForm" or similar, and all the field templates will be loaded from that suite. Something like this will improve performance also over using g:render to render common GSP that sets up the templates.
* Improve performance where currently it delegates to existing grails tags, it may be a lot better to use functions in the grails taglibs and have the regular field tags call these also (rather than multiple tag invocations)
* Examine retro-fitting this functionality to some or all of the existing field tags, such that when the beanName attribute is specified, it switches to smart behaviour. This would prevent a proliferation of similar tags. I think these tags should be in the "g" namespace, and this would avoid such problems. Most of the bean tags delegate to grails tags anyway so the attributes are largely orthogonal
 The bean-fields plugin (http://grails.org/plugin/bean-fields) provides tags that render input fields smartly, namely doing the following:

* Rendering HTML <label> for the field with the appropriate attributes, and text from i18n or fallback to convention
* Rendering fields errors inline by the field
* Rendering of customizable "required" indicator
* Customization of the layout of these decorated input fields using a template mechanism, where templates are retained for the duration of the request and can be modified during request processing
* Rendering fields according to the constraints on the command/domain object, where possible.
* Smart selection of HTML markup to use based on field type
* Simple rendering of edit fields for list of properties of an object with one tag

The plugin is well established and provides the basis for the work but there are some suggestions for improvement when pulling into core:

* Adapt to use Grails naming conventions for field labels
* Make it easier to define templates, preferably with named stylings/suites of templates. e.g. an artefact with a simple DSL for defining the GSP fragments, so that a form can specify templateName="standardForm" or similar, and all the field templates will be loaded from that suite. Something like this will improve performance also over using g:render to render common GSP that sets up the templates.
* Improve performance where currently it delegates to existing grails tags, it may be a lot better to use functions in the grails taglibs and have the regular field tags call these also (rather than multiple tag invocations)
* Examine retro-fitting this functionality to some or all of the existing field tags, such that when the beanName attribute is specified, it switches to smart behaviour. This would prevent a proliferation of similar tags. I think these tags should be in the "g" namespace, and this would avoid such problems. Most of the bean tags delegate to grails tags anyway so the attributes are largely orthogonal
* Fix the naming/paradigm for overriding "required indicator" when rendering fields, there is confusion about how to force a field to *appear* mandatory, and I have never been happy about this requiredField attribute name. Look at adding "required" attribute to override required or not, and "requiredIndicator" to override the default required indicator
* Issues with input field not having a template in the same way as other field types
Marc Palmer made changes -
Description The bean-fields plugin (http://grails.org/plugin/bean-fields) provides tags that render input fields smartly, namely doing the following:

* Rendering HTML <label> for the field with the appropriate attributes, and text from i18n or fallback to convention
* Rendering fields errors inline by the field
* Rendering of customizable "required" indicator
* Customization of the layout of these decorated input fields using a template mechanism, where templates are retained for the duration of the request and can be modified during request processing
* Rendering fields according to the constraints on the command/domain object, where possible.
* Smart selection of HTML markup to use based on field type
* Simple rendering of edit fields for list of properties of an object with one tag

The plugin is well established and provides the basis for the work but there are some suggestions for improvement when pulling into core:

* Adapt to use Grails naming conventions for field labels
* Make it easier to define templates, preferably with named stylings/suites of templates. e.g. an artefact with a simple DSL for defining the GSP fragments, so that a form can specify templateName="standardForm" or similar, and all the field templates will be loaded from that suite. Something like this will improve performance also over using g:render to render common GSP that sets up the templates.
* Improve performance where currently it delegates to existing grails tags, it may be a lot better to use functions in the grails taglibs and have the regular field tags call these also (rather than multiple tag invocations)
* Examine retro-fitting this functionality to some or all of the existing field tags, such that when the beanName attribute is specified, it switches to smart behaviour. This would prevent a proliferation of similar tags. I think these tags should be in the "g" namespace, and this would avoid such problems. Most of the bean tags delegate to grails tags anyway so the attributes are largely orthogonal
* Fix the naming/paradigm for overriding "required indicator" when rendering fields, there is confusion about how to force a field to *appear* mandatory, and I have never been happy about this requiredField attribute name. Look at adding "required" attribute to override required or not, and "requiredIndicator" to override the default required indicator
* Issues with input field not having a template in the same way as other field types
 The bean-fields plugin (http://grails.org/plugin/bean-fields) provides tags that render input fields smartly, namely doing the following:

* Rendering HTML <label> for the field with the appropriate attributes, and text from i18n or fallback to convention
* Rendering fields errors inline by the field
* Rendering of customizable "required" indicator
* Customization of the layout of these decorated input fields using a template mechanism, where templates are retained for the duration of the request and can be modified during request processing
* Rendering fields according to the constraints on the command/domain object, where possible.
* Smart selection of HTML markup to use based on field type
* Simple rendering of edit fields for list of properties of an object with one tag

The plugin is well established and provides the basis for the work but there are some suggestions for improvement when pulling into core:

* Adapt to use Grails naming conventions for field labels
* Make it easier to define templates, preferably with named stylings/suites of templates. e.g. an artefact with a simple DSL for defining the GSP fragments, so that a form can specify templateName="standardForm" or similar, and all the field templates will be loaded from that suite. Something like this will improve performance also over using g:render to render common GSP that sets up the templates.
* Improve performance where currently it delegates to existing grails tags, it may be a lot better to use functions in the grails taglibs and have the regular field tags call these also (rather than multiple tag invocations)
* Examine retro-fitting this functionality to some or all of the existing field tags, such that when the beanName attribute is specified, it switches to smart behaviour. This would prevent a proliferation of similar tags. I think these tags should be in the "g" namespace, and this would avoid such problems. Most of the bean tags delegate to grails tags anyway so the attributes are largely orthogonal
* Fix the naming/paradigm for overriding "required indicator" when rendering fields, there is confusion about how to force a field to *appear* mandatory, and I have never been happy about this requiredField attribute name. Look at adding "required" attribute to override required or not, and "requiredIndicator" to override the default required indicator (note the presence of "constraints" attribute override means you can achieve this currently with dummy constraints)
* Issues with input field not having a template in the same way as other field types
Hide
Permalink
Marc Palmer added a comment - - edited

Discussion with Rob Fletcher throws up these thoughts:

  • What tag namespace? "field" I think. <field:auto> <field:form> <field:select>, or even better just <field:PROPERTYNAMEHERE type="overriddenTypeNameHere">
  • Configurable per-class and property field templates/types. e.g. grails.fields.Book.author = 'longtext' and elsewhere "longtext" is defined as a field type ('input') plus a bunch of templates/args
  • Support for out of the box default behaviours that are switchable/compatible between (X)HTML and HTML5
  • Look at augmenting g:form so that the bean name and properties can be specified there, to eliminate need for <bean:required> and <bean:withForm>
  • Clean up the data passed to templates, make it uniform for all template types, include boolean for required/add in constraints info (e.g. for HTML5 number fields)
  • Examine options for convention-based loading of template GSPs (and how to prep these up so they themselves can call other tags in their impls e.g. invoke YUI date pickers etc)
  • Allow UI plugins to provide a set of templates that automatically mix in their UI paradigms, i.e. install jquery-ui and <bean:date> automatically switches to using jquery's Date Picker
  • Re-examine existing core field tags, refine them and perhaps templatize them too / merge all the concepts so that we have templatable regular fields. Or just stop BF relying on them and reimpl that stuff directly in the default templates. This would perform better - but customization of layout should not require re-implementation of this, so add field templating separately. The old g:xxxx field tags could then be deprecated.
Show
Marc Palmer added a comment - - edited Discussion with Rob Fletcher throws up these thoughts: What tag namespace? "field" I think. <field:auto> <field:form> <field:select>, or even better just <field:PROPERTYNAMEHERE type="overriddenTypeNameHere"> Configurable per-class and property field templates/types. e.g. grails.fields.Book.author = 'longtext' and elsewhere "longtext" is defined as a field type ('input') plus a bunch of templates/args Support for out of the box default behaviours that are switchable/compatible between (X)HTML and HTML5 Look at augmenting g:form so that the bean name and properties can be specified there, to eliminate need for <bean:required> and <bean:withForm> Clean up the data passed to templates, make it uniform for all template types, include boolean for required/add in constraints info (e.g. for HTML5 number fields) Examine options for convention-based loading of template GSPs (and how to prep these up so they themselves can call other tags in their impls e.g. invoke YUI date pickers etc) Allow UI plugins to provide a set of templates that automatically mix in their UI paradigms, i.e. install jquery-ui and <bean:date> automatically switches to using jquery's Date Picker Re-examine existing core field tags, refine them and perhaps templatize them too / merge all the concepts so that we have templatable regular fields. Or just stop BF relying on them and reimpl that stuff directly in the default templates. This would perform better - but customization of layout should not require re-implementation of this, so add field templating separately. The old g:xxxx field tags could then be deprecated.
Hide
Permalink
Marc Palmer added a comment -

The conventions for GSP templates could work like this:

grails.fieldtemplates.view.path = '/myfieldtemplates'
grails.fields.Book.author = 'longtext'

Then in the tags we do the equivalent of:

g:render(template:config.fieldtemplates.view.path+'/'+config.fields[className][propertyName])
Show
Marc Palmer added a comment - The conventions for GSP templates could work like this: grails.fieldtemplates.view.path = '/myfieldtemplates' grails.fields.Book.author = 'longtext' Then in the tags we do the equivalent of: g:render(template:config.fieldtemplates.view.path+'/'+config.fields[className][propertyName])
Hide
Permalink
Marc Palmer added a comment - - edited

More tweaks:

  • Why do we require valueOverride instead of reusing "value" attribute? Overriding the actual value is useful (e.g. in password fields) but I don't know why we had to go for valueOverride in the past. Also if you include value="xxx" it is passed through and two written. We need to adapt the attribute handling to merge attributes with those supplied, and write out only one set, such that values supplied by the user override any applied by bean-fields
  • Change name of bean:require to something that can not be confused with bean:required/requiredIndicator
  • Improve error handling such that if a bean has "constraints" property but it is still a Closure. This happens if you add @Validateable but don't add to the packages to scan, and results in confusing errors.
Show
Marc Palmer added a comment - - edited More tweaks: Why do we require valueOverride instead of reusing "value" attribute? Overriding the actual value is useful (e.g. in password fields) but I don't know why we had to go for valueOverride in the past. Also if you include value="xxx" it is passed through and two written. We need to adapt the attribute handling to merge attributes with those supplied, and write out only one set, such that values supplied by the user override any applied by bean-fields Change name of bean:require to something that can not be confused with bean:required/requiredIndicator Improve error handling such that if a bean has "constraints" property but it is still a Closure. This happens if you add @Validateable but don't add to the packages to scan, and results in confusing errors.
Contegix Support made changes -
Project Import Thu Mar 24 21:22:24 CDT 2011 [ 1301019744151 ]
Hide
Permalink
Mukhamad Ikhsan added a comment -

Suggestion : add compatibility in datePicker&timePicker for joda time.

Show
Mukhamad Ikhsan added a comment - Suggestion : add compatibility in datePicker&timePicker for joda time.
Graeme Rocher made changes -
Fix Version/s 1.4-M2 [ 12504 ]
Fix Version/s 1.4-M1 [ 11040 ]
Graeme Rocher made changes -
Fix Version/s 2.0-M1 [ 12504 ]
Fix Version/s 2.0-M2 [ 12805 ]
Burt Beckwith made changes -
Workflow jira [ 35538 ] Grails [ 40035 ]
Burt Beckwith made changes -
Workflow Grails [ 40035 ] Copy of Grails [ 47469 ]
Burt Beckwith made changes -
Workflow Copy of Grails [ 47469 ] Grails [ 54879 ]
Burt Beckwith made changes -
Workflow Grails [ 54879 ] Grails2 [ 62431 ]
Graeme Rocher made changes -
Link This issue is depended upon by GRAILS-4094 [ GRAILS-4094 ]
Graeme Rocher made changes -
Link This issue is depended upon by GRAILS-270 [ GRAILS-270 ]
Graeme Rocher made changes -
Fix Version/s 2.0-RC1 [ 12803 ]
Fix Version/s 2.0-M2 [ 12805 ]
Hide
Permalink
James Lang added a comment -

Marc Palmer mentioned on Grails user a few weeks ago that Robert Fletcher was doing some work on this for 2.0 release.

Is bean fields plugin what it is (i.e. remains in its present excellent, but flawed state) and no alternative will be available, or can grails community look forward to some movement on this front for 2.0 RC-1 or 2.0 final?

Show
James Lang added a comment - Marc Palmer mentioned on Grails user a few weeks ago that Robert Fletcher was doing some work on this for 2.0 release. Is bean fields plugin what it is (i.e. remains in its present excellent, but flawed state) and no alternative will be available, or can grails community look forward to some movement on this front for 2.0 RC-1 or 2.0 final?
Hide
Permalink
Marc Palmer added a comment -

No further effort of mine will be put into bean-fields other than any critical bug fixes that emerge. The time I have will be put into helping with the new code Rob is writing.

However there is no ETA, other than we all want it done ASAP. It's unpaid work.

Show
Marc Palmer added a comment - No further effort of mine will be put into bean-fields other than any critical bug fixes that emerge. The time I have will be put into helping with the new code Rob is writing. However there is no ETA, other than we all want it done ASAP. It's unpaid work.
Hide
Permalink
James Lang added a comment -

Understood re: non-core staff doing grails work completely pro bono. Just trying to get an idea where things are at. Too bad Bean fields or some version of it is not in core as it is the forms equivalent of GORM, which is to say, vital.

Show
James Lang added a comment - Understood re: non-core staff doing grails work completely pro bono. Just trying to get an idea where things are at. Too bad Bean fields or some version of it is not in core as it is the forms equivalent of GORM, which is to say, vital.
Hide
Permalink
Marc Palmer added a comment -

Yes, well the new stuff is planned to be a "core" contrib, but this line is not clearly defined. Basically there is a core paid S2 team, but we still contrib as we can to "core" plugins e.g. Resources has no paid maintainer.

Show
Marc Palmer added a comment - Yes, well the new stuff is planned to be a "core" contrib, but this line is not clearly defined. Basically there is a core paid S2 team, but we still contrib as we can to "core" plugins e.g. Resources has no paid maintainer.
Hide
Permalink
James Lang added a comment -

If it makes it into core for 2.0 there will be many grails developers kicking azz (forms are the single most time consuming process in web devel).

Anyway, did not know that anyone was paid apart from Spring staff members graeme, burt, peter and jeff (these are the ones I know of at least). Actually surprised you are not working for Spring...

Show
James Lang added a comment - If it makes it into core for 2.0 there will be many grails developers kicking azz (forms are the single most time consuming process in web devel). Anyway, did not know that anyone was paid apart from Spring staff members graeme, burt, peter and jeff (these are the ones I know of at least). Actually surprised you are not working for Spring...
Graeme Rocher made changes -
Fix Version/s 2.0.1 [ 13005 ]
Fix Version/s 2.0-RC1 [ 12803 ]
Burt Beckwith made changes -
Workflow Grails2 [ 62431 ] jira [ 71423 ]
Burt Beckwith made changes -
Workflow jira [ 71423 ] Grails2 [ 79829 ]
Peter Ledbrook made changes -
Last Reviewed 01/Jan/10
Peter Ledbrook made changes -
Workflow Grails2 [ 79829 ] jira [ 87862 ]
Peter Ledbrook made changes -
Workflow jira [ 87862 ] Grails2 [ 96086 ]
Graeme Rocher made changes -
Fix Version/s 2.0.2 [ 13064 ]
Fix Version/s 2.0.1 [ 13005 ]
Graeme Rocher made changes -
Fix Version/s 2.0.3 [ 13094 ]
Fix Version/s 2.0.2 [ 13064 ]
Graeme Rocher made changes -
Fix Version/s 2.0.4 [ 13099 ]
Fix Version/s 2.0.3 [ 13094 ]
Jeff Brown made changes -
Fix Version/s 2.2 [ 13093 ]
Fix Version/s 2.0.4 [ 13099 ]
Graeme Rocher made changes -
Fix Version/s 2.3 [ 13311 ]
Fix Version/s 2.2-RC1 [ 13093 ]
Hide
Permalink
Graeme Rocher added a comment -

The 'fields' plugin implements this feature (see http://grails.org/plugin/fields), I'm not convinced it is needed in core. Now that the scaffolding plugin has been split out of core even less

Show
Graeme Rocher added a comment - The 'fields' plugin implements this feature (see http://grails.org/plugin/fields ), I'm not convinced it is needed in core. Now that the scaffolding plugin has been split out of core even less
Hide
Permalink
Rick Jensen added a comment -

I agree. The fields plugin handles this well, and it's better to leave it in an independent plugin, rather than tie it to the core. It would be nice to add a bit to the core docs, however, that points people to the fields plugin for this functionality. (or any other plugins that do similarly)

Show
Rick Jensen added a comment - I agree. The fields plugin handles this well, and it's better to leave it in an independent plugin, rather than tie it to the core. It would be nice to add a bit to the core docs , however, that points people to the fields plugin for this functionality. (or any other plugins that do similarly)
Graeme Rocher made changes -
Fix Version/s 2.3-M2 [ 13457 ]
Fix Version/s 2.3-M1 [ 13311 ]

People

  • Assignee:
    Marc Palmer
    Reporter:
    Marc Palmer
Vote (21)
Watch (18)

Dates

  • Created:
    Updated:
    Last Reviewed: