“We conquer by continuing.”
— George Matheson
Last time, we created our app, added a few properties, and built our first table. Today we are going to work with that table to configure the layout of both the list and the form, and then maybe do a few other things before we move on to the rest of the tables. Let’s start with the list.
To edit the fields that will show up on the list view, we can bring up the list view and then select Configure -> List Layout from the context menu.
Using the slush bucket, we can select Number, Short description, Item label and Description from the available fields on the table.
That will give us a list view that looks like this.
Using basically the same method, we can arrange the fields on the form view.
The form is a bit more complicated than the list, so to help organize things, we can divide the form into sections. After we lay out the main section of the form, we can scroll down to the Section list and click on the New… option, which brings up a small dialog box where we can give our new section a name.
Once we have created the new section, we can drag in and arrange all of the fields that we would like to see in that section of the form.
Once that has been completed, we can take a look at our new form.
We are still not quite done with the form just yet, though. All of the columns that reference fields on the selected table should have a selection list that is limited to just the fields on that table. To accommodate that, we need to pull up the dictionary record for each of those fields and set up a dependency. To do that, right click on the field label and select Configure Dictionary from the resulting context menu.
Using the Advanced view, go into the Dependent Field tab and check the Use dependent field checkbox and select Table from the list of fields.
This process will need to be repeated for all of the columns that represents fields on the configured table.
The last thing that we need to add to this form, at least for now, is the ability to test the Filter against the specified table. It would probably be more user-friendly if our Filter field was some kind of query builder, but since it is just a simple String field, the least we can do is to provide some mechanism to test out the query string once it has been entered. The easiest way to do that would be to create a UI Action called Test Filter that used the Table and the Filter fields to branch to the List view of that table. Building a link to the List view in script would look something like this:
current.table + '_list.do?sysparm_query=' + encodeURIComponent(current.filter)
Branching to that page in a UI Action script would then just be this:
action.setRedirectURL(current.table + '_list.do?sysparm_query=' + encodeURIComponent(current.filter));
Clicking on the button would then take you to the list where you could see what records would be selected using that filter. To create the UI Action, we can use the context menu on the form and select Configure -> UI Actions and then click on the New button to create a new UI Action for that form.
Once our action has been configured and saved, the button should appear at the top of the form.
That should just be about it for our first table and all of the associated fields, forms, and views. Next time, we can use our Service Account Management app as a potential first user of this app and see if we can set up the configuration for that app before we move on to creating other tables.
