As an App Adm, I want to add new text fields on my object

• Type: Story
• Status: Closed
• Priority: Minor
• Resolution: Completed
• Affects Version/s: None
• Fix Version/s: Master
• Component/s: App Builder
• Labels:
  • 7.3-app_builder_must_have
  • 7.3-ce-ga1
  • appbuilder_test_manual
  • appbuilder_test_needed
  • appbuilder_test_poshi_sanity
  • appbuilder_test_spira
• Story Points: 8
• Epic Link: App Builder - Create Custom Objects
• Sprint: App_Builder_7.3_5, App_Builder_7.3_6, App_Builder_7.3_7

As an App Adm, I want to add new text fields on my object, so that I can collect, store and show texts information in my object.

Design Deliverables:

Mockups
Animations

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.
The Text Field:
As well known, the text field is one of (or the most) used type of field for forms and also attribute type of objects. Therefore, we decided to have it as the first available field type of the App Builder. In this Story, we aim to allow users to drag, drop and include text fields into their Form Views, and consequently, add text field to the data model of the custom object.

The Text Field should be available with the same features and properties of Forms, but with a few differences:

• In the App Builder, the "Autocomplete" will be a new tab and will have three options:
  • Manually;
  • From Data Provider (doesn't need to be implemented yet, there will be a Story just for it)
  • From Data Object (aka Lookup) - (doesn't need to be implemented yet, there will be a Story just for it)
• The tab "Properties" will be renamed to "Advanced"
  • A few options have been moved between the two tabs (Basic and Properties, pay attention to the mockups to get it right.)
• Besides the "Remove field from form" option, we will also have a "Remove from object" option (they will co-exist);
  • The "Remove from Form" will remove the field from the Form View, but will keep the field as an attribute of the object;
    • When the field is being used by other Form Views, the system must delete the field from the Form View in question, but keep it in those other Form Views.
  • The "Remove from Object" will remove the field form the Form View and also remove it from the data model of the Object.
    • When the field is being used by other Form Views, the system must warn the user and propagate the deletion to the other forms.

Acceptance Criteria:

• Given a user in the "Form View Builder" screen of an object, when the user drags and drop a "Text" field type from the sidebar into the Form stage area, then the system must include and display a Text type field into the current Form View.

• Given a user in the "Form View Builder" screen of an object, when the users includes a new "Text" field type into the Form View , then the system must also automatically include a new "Text" field type into the Data Model of the object.

• Given a user in the "Form View Builder" screen of an object, when the user is dragging and dropping a "Text" field into the Form stage, then he should be able to choose the place where the text field should be displayed in the Form View.

• Given that a user has included a "Text" field into a Form View of an Object, when the user highlights/selects the field in the Form View stage area, then the system must provide the user with the same options and properties of the "Text" field available in the Forms module.
  • Including: Change label, set a placeholder text, set a help text, choose field lines type, required, change field name, enter a predefined value, change searchable options, show/hide label, make repeatable, set a validation, configure a manual type autocomplete.

• Given that a user has included a "Text" field into a Form View of an Object, when a user clicks in the "Duplicate" option of the field kebab menu, then the system must automatically create a copy of the field into the Form View and in the Object model.
  • Obs: use the same behavior of the Forms module.

• Given that a user has included a "Text" field into a Form View of an Object, when the user clicks in the "Remove From Object" option of the field kebab manu, then the system must remove the field form the Form View and also remove it from the data model of the Object.
  • Obs: When the field is being used by other Form Views, the system must warn the user and propagate the deletion to the other forms.

• Given that a user has included a "Text" field into a Form View of an Object, when the user clicks in the "Remove from Form" option of the field kebab manu, then the system must remove the field from the Form View, but keep it as an attribute of the object;
  • Obs: When the field is being used by other Form Views, the system must delete the field from the Form View in question, but keep it in those other Form Views.

• Given that a user has included a "Text" field into a Form View of an Object, when the user drag and drops an existing field in the stage area, then the system must allow the user to reorder the position of the field in the Form View.

• Given that a user has included a "Text" field into a Form View of an Object, when the user highlights/selects the field in the Form View stage area, then the system must allow the user to see and change the properties of the 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)