As a DXP Developer, I want to prevent updates to Liferay object native fields
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:
- Removing Native Objects OOTB fields;
- Changing non-visual properties of OOTB fields.
1- Given a user creating a new Form View for a Liferay Native Object in App Builder,
when the user looks at canvas area of the Form View screen,
then Form View should have by default all required OOTB fields of the Native Object.
2- Given a user in the Form View Builder of a Native Object and that the Form View Builder doesn't contain all required OOTB fields of the Native Object,
when the user tries to finish the creation by clicking in the "Save" button of the screen,
then the system should allow the user to create the Form View without all the required OOTB fields.
- In the LPS-115672 we validate that during Apps deployment.
3- 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.
- Properties that should be allowed to be edited:
- Show/Hide Label;
- Predefined Value;
- Help Text;
- Make Required at View Level (depends on LPS-103467).
4- Given a user in the Form View of a Liferay Native Object,
when the user clicks in the kebab menu of an OOTB field in the Form View,
then the system must not allow the user to remove any OOTB field from the Native Object Data Definition.
- The same constraint should be applied when trying to remove an OOTB field from the Object sidebar;
- Removing OOTB fields only from the Form view should be allowed.
- 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