As a power user, I want to create a many-to-many relationship between Native (System) and Custom Objects

• Type: Story
• Status: Closed
• Priority: Critical
• Resolution: Completed
• Affects Version/s: None
• Fix Version/s: Master
• Component/s: Objects
• Labels:
  • fc_22_03
  • good-to-go
  • low-code-milestone
  • now-dxp-latam
  • qa_test_mapped
  • sierra-team
  • sierra_q2
  • team-sierra
• Epic Link: Low Code System Objects Extensions

Context:

Many use cases requires users to create relationship between their custom objects with native entities of the portal. One of those use cases, even being a internal use case, is to be able to add attachments (or upload files) in custom object entries. Those files must be saved and organized in the standard repository of Liferay, so they can follow Liferay patterns and rules as accepted file types, file size limit and so on.

This story aims to solve the relationship between native (many) to custom (many). This use case can be seen in the following example:

• Tickets (custom object) that require attachments from end users and those attachments can only be related to that Ticket. When the end user adds the attachments, those files are in the default Liferay respository (Native Object), while the ID is saved in the related Ticket (custom object).

Mockups:

The story does not need mockups. It is the same behavior of many-to-many between custom objects, but allowing users to relate custom with native ones as well.

Refinement Link 

Acceptance Criteria

1 - Given a power user,
when editing an entry,
then I must be able to relate  one Custom Object Entry to many Native Objects Entries

2 - Given a power user,
when editing an entry,
then I must be able to show one Custom Object Entry to many Native Objects Entries

3 - Given a power user,
when modeling a Custom Object,
then I must be able to add a relationship to a System Object (Many to Many)

4 - Given a power user,
when modeling a Custom Object or System Object,
then I must not be able to add a self relationship  (Many to Many) 

Definition of Done (DoD):

• All Acceptance Criteria were passed;
• Make sure that the expected automated tests were created (unit / integration / functional) and passed successfully;
• Validated by QA and Product Manager;
• No critical bug related to Story scope (FP5);
• Make sure that all system documentation were updated (if necessary)