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

As a DXP Developer, I want to prevent updates in non-visual properties of my native object fields through the UI (show them as read-only)



      As a DXP Developer, I want to prevent updates in non-visual properties of my native object fields through the UI (show them as read-only)

      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.

      • All non-visual properties must be shown as read-only

      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
              luiz.jardim Luiz Jardim
              Recent user:
              Leide Mangueira
              Participants of an Issue:
              0 Vote for this issue
              0 Start watching this issue




                  Version Package