Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-128672

As a DXP Developer, I want to prevent updates in native object fields through API Rest on Data Engine (DataDefinition)



      As a DXP Developer, I want to prevent updates in native object fields through API Rest on Data Engine (DataDefinition)

      Design Deliverable



      App Builder Native Objects are made using the existing structures of each native entity in Liferay. In order to be valuable for users, the data retrieved and gathered by native objects Apps should be the same as the one that uses the OOTB Portlet, meaning the for it to work, we must respect the same constraints that exist for it.

      That being said, we cannot let users break down the native entities while using App Builder and to do that, we need to prevent users from changing non-visual properties of OOTB fields.

      Table of visual type of properties:


      Non-visual properties Visual properties
      Field Type Label
      Repeatable Show/Hide Label
      Searchable (indexable) Predefined Value
      Searchable Type (indexType) Placeholder
      Validation Help Text
      Required at object level Selection Field Types Inline option for text field (On/Off)
      Field Reference Selection Field Types Inline option for multiple selection (On/Off)
      Order options alphabetically (alphabeticalOrder) Multiple Selection Show as Switcher option (On/Off)
      Options Make Required at View Level (when the field is not required at object level)

      Acceptance Criteria

      1- Given a user in the Form View of a Liferay Native Object,
      when the user accesses the details of properties of an OOTB field of the native object,
      then the system must not allow the user to change any non-visual property of the OOTB field.

      Definition of Done (DoD):

      • All Acceptance Criteria were passed;
      • Make sure that the expected automated tests were created (unit / integration / functional) and passed successfully;
      • Verify if the test labels were added;
      • 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


        Issue Links



              luiz.jardim Luiz Jardim
              victor.santos Victor Santos (Inactive)
              SE Support SE Support
              Kiyoshi Lee Kiyoshi Lee
              0 Vote for this issue
              0 Start watching this issue




                  Version Package