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

• Type: Story
• Status: Closed
• Priority: Minor
• Resolution: Discarded
• Affects Version/s: None
• Fix Version/s: None
• Component/s: App Builder
• Labels:
  • 7.3-app_builder_must_have
  • 7.4-ce-ga2
  • 7.4-must
  • S
  • app-builder-frozen-stories
  • fc_01_21
  • qa_reviewed
• Story Points: 8
• Epic Link: App Builder - Extend Native Objects

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