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

As an App Adm, I want to create a new form view for an object

    Details

    • Branch Version/s:
      7.2.x
    • Backported to Branch:
      Committed
    • Story Points:
      20
    • Sprint:
      App_Builder_7.3_3, App_Builder_7.3_4, App_Builder_7.3_5

      Description

      As an App Adm, I want to create a new form view for an object, so that I can customize the forms that my App's user are going to use.

      Design Deliverables

      Mockups

      Context

      App Builder:
      In this first version of the product, we are proposing a feature that allow user to create CRUD applications. That being said, each object will represent a new App that will be able to insert new entries, see the listing, delete and view existing entries.

      Form Views:
      To add new entries, the App admin will need to create Form Views that will be published and consequently, used by the App's final users to submit new entries for the objects. Not only that, but ir our solution, the Form View creation will also be used to define the object structure, meaning that underneath, while the user adds and updates fields in his Form Views, the system will also be adding and updating the object model.

      This Feature - The Form View Builder:
      In this feature, we want to allow the users to create new Form Views for their objects, but because the Form View Builder is one of the most complex feature of the product, we decided to divide it into parts: (1) creating an empty Form View, (2) Insert the Field Types into the form, (3) insert the other features (lookup, object fields reusage, visual elements, rules, etc.). In this Story, we will only implement (1), the ability to create a new empty Form View for an object.

      Acceptance Criteria:

      • 1- Given a user on the Custom Object listing screen, when the user clicks on the "New Custom Object" button, then the system must prompt the user for a name for the Custom Object and create the object with that name.
          • Should not be empty;
          • Should not have only spaces (" ").
      • 2- Given that a user has clicked in the button to create a "New Custom Object" and already inputed a name for it, when the user leaves the option to go straight to the "Form View Builder" screen marked and continues to the creation of the object, then the system must redirect the user to the "Form View Builder" screen to create the new Form View.
      • 3- Given that a user has clicked in the button to create a "New Custom Object" and already inputed a name for it, when the user leaves the option to go straight to the "Form View Builder" screen unmarked and continues to the creation of the object, then the system must redirect the user to the "Form View Listing" screen of the object.
      • 4- Given a user in the Form View Builder screen, when the user clicks on the "Form View Name" field, then he should be able to rename the Form View of the Object.
        • Obs: Restrictions for the "Form View Name":
          • Should not be empty;
          • Should not have only spaces (" ").
      • 5- Given a user in the "Form View Builder" screen with the Object and Form View names properly defined, when the user clicks on the "Save" button of the Form View, then the system must save the new Form View of the Custom Object and redirect the user to the "Form Views" listing screen.
      • 6- Given a user in the "Form View Builder" screen, when the user clicks on the "Cancel" button of the Form View, then the system exit the user back to the "Form Views" listing screen and do not save/apply any of the changes made by the user.
        • Obs: If the user clicks on "Cancel" during the creation of an entirely new Custom Object, the creation of the new custom object must be also canceled and the user should be redirected to the "Custom Object" listing screen.
      • 7- Given a user in the "Form View Builder" screen, when the user looks at the screen, then he should be able to identify where is the Form canvas (place to drop the fields) and where is the menu bar with the available tools (fields, object's fields, interface elements, fieldsets, etc.).
      • 8- Given a user in the "Form View Builder" screen with the right menu bar open, when the user clicks in the ">" button of the right menu bar, then the system should close/hide the right menu bar from the user.
      • 9- Given a user in the "Form View Builder" screen with the right menu bar closed, when the user clicks in the "<" button of the right menu bar, then the system should open/show the right menu bar for the user.

      Features that doesn't need to be implemented (yet):

      • The features (new fields, object, interface elements, fieldsets, import from spreadsheet, search, etc.) of the right menu bar (there's a story for each of them);
      • Translations;
      • Form Rules.

      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)

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Packages

                  Version Package
                  7.2.10 DXP FP2
                  7.2.10.1 DXP SP1
                  7.2.X
                  Master