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)

    Details

      Description

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

      Design Deliverable

      Mockups

      Context

      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)
      OptionsReference  
      Autocomplete  

      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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              luiz.jardim Luiz Jardim
              Reporter:
              victor.santos Victor Santos
              Engineering Assignee:
              SE Support
              Recent user:
              Leide Mangueira
              Participants of an Issue:
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Packages

                  Version Package