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

          1.
          [FE][BE] Rename Field ID label to Field Name LPS-121829 Technical Task Closed Marcos Martins  
          2.
          [BE] Add new Field Reference LPS-121830 Technical Task Closed Marcos Martins  
          3.
          [FE] Set Initial Field Reference Value with Field Name Value LPS-121827 Technical Task Closed Carolina Barbosa  
          4.
          [FE] Enable Field Reference edition by default on Sidebar LPS-121828 Technical Task Closed SE Support  
          5.
          [FE][BE] Enable Field Reference edition by default on Field Options LPS-121850 Technical Task Closed SE Support  
          6.
          [FE] Check if field reference (including Options) is unique after edited by the user LPS-122220 Technical Task Closed Renato Rêgo  
          7.
          [BE][FE] Make Field Reference required LPS-122221 Technical Task Closed Marcos Martins  
          8.
          [FE] Make Field and Option Ids not visible in SideBar LPS-122028 Technical Task Closed Carolina Barbosa  
          9.
          [BE] Create new methods to return maps with Field Reference as the key LPS-121837 Technical Task Closed Carolina Barbosa  
          10.
          [BE] Create new Field Reference during Upgrade process LPS-121831 Technical Task Closed Carolina Barbosa  
          11.
          [FE] Review/Fix Front End tests LPS-121844 Technical Task Closed SE Support  
          12.
          [QA] Review/Fix poshi tests LPS-121845 Technical Task Closed SE Support  
          13.
          [FE] Analyze the effort necessary to implement this change from field name / field id LPS-121668 Technical Task Closed Aline Cantarelli  
          14.
          [BE] Analyze the effort required to change from FieldName to FieldID LPS-121670 Technical Task Closed Carolina Barbosa  
          15.
          [POSHI] Analyze the effort required to change from FieldName to FieldID LPS-121669 Technical Task Closed Carolina Barbosa  
          16.
          [FE] Rename FieldName to FieldID on Form Renderer (FormRendererWithProvider, Evaluation) LPS-121838 Technical Task Closed SE Support  
          17.
          [FE] Rename FieldName to FieldID on Rules Builder (RuleEditor, RuleList, RuleSupport, rules.es.js) LPS-121832 Technical Task Closed SE Support  
          18.
          [FE] Rename FieldName to FieldID on Form Builder (focusedFieldEvaluationEndedHandler, pageSupport) LPS-121840 Technical Task Closed SE Support  
          19.
          [FE] Use field label instead of fieldId on Calculator expression LPS-121834 Technical Task Closed SE Support  
          20.
          [FE] Rename FieldName to FieldID on fields manipulations which impact rules (delete, move, edit, duplicate,fieldBlur, fieldChange, fieldFocus) LPS-121835 Technical Task Closed SE Support  
          21.
          [FE] Rename FieldName to FieldID on Reports (Sidebar, Cards, etc) LPS-121836 Technical Task Closed SE Support  
          22.
          [FE] Check if fields validation (Sidebar) should use fieldID instead of fieldName LPS-121843 Technical Task Closed SE Support  
          23.
          [BE] Make the functions use Field ID instead of Field Name LPS-121842 Technical Task Closed SE Support  
          24.
          [BE] Replace FieldName to FieldID on Evaluator package LPS-121839 Technical Task Closed SE Support  
          25.
          [BE] Replace FieldName to FieldID on Report package LPS-121841 Technical Task Closed SE Support  
          26.
          [BE] Use Field ID instead of Field Name on CalculateDDMFormRuleActionSerializer LPS-121846 Technical Task Closed SE Support  
          27.
          [BE] Make the form annotations support Field ID LPS-121833 Technical Task Closed SE Support  
          28.
          [BE] Check if Form Renderer should use Field ID instead of Field Name LPS-121847 Technical Task Closed SE Support  
          29.
          [BE] Check if Form Web should use Field ID instead of Field Name LPS-121854 Technical Task Closed SE Support  
          30.
          [BE] Review/Fix Back End tests related to Rules LPS-121848 Technical Task Closed SE Support  
          31.
          [BE] Review/Fix Back End tests related to Reports LPS-121849 Technical Task Closed SE Support  
          32.
          [QA] Design Test Cases LPS-122591 Technical Testing Closed Cleyton Magalhaes (Inactive)  
          33.
          [QA] Manual Validation - Round 01 LPS-123219 Technical Testing Closed Cleyton Magalhaes (Inactive)  
          34.
          [QA][DE][PM] Story Review LPS-123444 Technical Task Closed Cleyton Magalhaes (Inactive)  

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved:
                Days since last comment:
                26 weeks, 5 days ago

                  Packages

                  Version Package
                  7.3.X
                  7.3.6 CE GA7
                  Master