Details

    • Fix Priority:
      5
    • Sprint:
      Forms_7.3_34, Forms_7.4_01, Forms_7.4_02, Forms_7.4_03

      Description

      Reporter's description:

      In Liferay DXP 7.2, it used to be possible to give each form field a "Field name".

      This field name would be visible in Form entries exports and could be used within Model Listeners or Storage Adapters in order to fetch the value of one particular form field to do something.

      Since https://issues.liferay.com/browse/LPS-114619, the Field name has been replace with an unpredictable and auto-generated Field ID.

      The problem is that now a form entries export makes almost no sense to someone who would import it to a third party tool or Excel:

      {{[

      {"Field43455081":"Ledoux","author":"Test Test","Field23763208":"Robert","Field92893087":"Option A","modifiedDate":"9/28/20 11:56 AM","status":"Approved"}

      ,

      {"Field43455081":"Bouché","author":"Test Test","Field23763208":"Fabian","Field92893087":"Option B","modifiedDate":"9/28/20 11:56 AM","status":"Approved"}

      ]}}

      And because the Field IDs are unpredictable, it's impossible to write any code that is meant to make use of the values stored in the form entries.

      Our current users of Liferay Forms in France will have major issues with this change of behaviour of Liferay Forms.

       
      My suggestion would be:

      • To put back a "Field Reference" in addition to the "Field ID"
      • To make this "Field Reference" editable
      • To have the Exporters use that "Field Reference" instead of the "Field ID" in the export

      Solution (new expected behavior):

      Context

      In order to attend both internal and external needs, all the forms fields must have two references, one internal (Field Name) and one external (Field Reference). This is needed because in 7.2 version the Field Name was used to reference the fields by the developers, which is much more complicated now that it was replaced for the Field ID in the https://issues.liferay.com/browse/LPS-114619.

      Acceptance Criteria

      1- Given a user in a Liferay Form Builder,

      when the user adds a new field into the Form,

      then the system should automatically generate an unique Id as the Field Name.

      • The Field Name will not be displayed in the UI;
      • In Liferay Forms, the Field Name should NOT be editable;
      • This also applies for the Options' Name in selection field types (Single Selection, Multiple Selection, Select from List, etc.);
      • This also applies when inserting Element Sets.

      2- Given a user in a Liferay Form Builder,

      When adding a new field into the Form,

      Then the system should display a Field Reference in the advanced information, as it happened in the 7.2.

      • This field is mandatory;
      • This field is unique;
      • The default name of the Field will be the same as the Field Name;
      • This field is editable by the user;
      • This behavior also applies for the Options' Reference in selection field types (Single Selection, Multiple Selection, Select from List, etc.), the current Option ID should be hidden and be added an editable Option Reference instead;
      • This also applies when inserting Element Sets.

      3- Given a user in a Liferay Form Builder,

      When editing a Field Reference,

      Then the system should check if there is other field reference with the same value

      4- Given a user in a Liferay Form Builder,

      When inserting a invalid field reference value and clicking away

      Then the system should change back to the field original value instead of the new one;

      • This should also happen when the user leaves the field empty;
      • The system should alert the users about both invalid values (''already been used'' and empty).

      5- Given a developer in a Liferay's Form Builder,

      When aiming to manipulate Forms fields,

      Then they must use the Field Reference to fetch the value of one particular form field.

      • The field must be used as reference for data exporting, integration and customization.

      6- Given a internal feature in a Liferay Form Builder,

      When aiming to refer a particular form field,

      Then they must use the Field Name to identify a particular form field.

      • Internal feature examples: rules and reports.

      7- Given that a user updated an existing Form's Field Label,

      when the user checks this Field in the Rules, Reports or any other Form feature,

      then the feature (rules, reports, etc.) must display the Field's new Label without losing the reference (understanding as being still the same field, once that it uses the Field Name as reference).

      8- Given user from previous versions of DXP,

      When updating the platform to 7.3 version,

      Then the system should migrate the old Field Name customizations to the new Field Reference field.

      Side effects care

      • Some users already have customizations using the Field Name reference, we should make sure that these customizations are migrated to the new reference without problems.
      • Every change on Form Builder can generate side effects on App Builder and on the clients of Data Engine, therefore after finishing each task of this story it's important to execute the tests of these two products. For App Builder, run its specific test suite (ci:test:app-builder).

      Definition of Done (DoD):

      • All Acceptance Criteria were passed;
      • Make sure that the expected automated tests were created (unit / integration / functional) and passed successfully;
      • Code with peer review completed;
      • Validated by QA, Product Designer and/or PM;
      • No critical bug related to Story scope (ex.: similar of FP4, FP5);
      • Make sure that all system documentation were updated (if necessary)

      Make sure that it has the extensions points needed to allow GS and customers to customize the feature (If applicable)

       

       

        Attachments

          Issue Links

          There are no Sub-Tasks for this issue.

            Activity

              People

              Assignee:
              cleyton.magalhaes Cleyton Magalhaes (Inactive)
              Reporter:
              fabian.bouche Fabian Bouché
              Participants of an Issue:
              Recent user:
              Sophia Zhang
              Engineering Assignee:
              Carolina Barbosa
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 2 weeks, 6 days ago

                  Packages

                  Version Package
                  7.3.6 CE GA7
                  7.3.X
                  7.4.13 DXP GA1
                  Master