Episode 6. UX/UI settings

   

In the last episode, we figured out how to create users and grant access rights to them. This is a good start, but, most probably, the application has much more settings than that. Some of these settings can turn on or off parts of the application functionality, others can affect how the user interface looks. This is what we are here to discuss today.

As soon as the company owner started working with the application, he immediately  found out that Sales Document has a fixed list of statuses. While during the pre-sale demonstration he was specifically told that he can edit any status name, add any number of new ones and delete whatever he doesn’t need. So my guess is, there is some setting somewhere that turns this functionality on or off. I could probably ask developers or look it up in the manual. But instead let’s reverse-engineer this functionality to figure it out ourselves.

First of all, where am I? This object has a Number a Date, and it can be posted. So, this is definitely a Document, right? OK, let’s see. Documents. And here is our SalesOrder. Let’s now find the form we saw the Status field in.

These are all the forms, and it’s not entirely obvious which one is which, so let’s look it up here. This is the property that tells the Platform which form to use for adding and editing documents. So, this one looks like what we need. Let’s open it. And here it is. Wait. There are two of them. OK. Let’s see.

So the first form field is called Status. It displays the form attribute having the same name. The attribute lives down here and belongs to the form. It’s not an Object’s attribute and isn’t stored in the database along with the document.

The second field is called OrderState. It displays the ObjectState attribute which is our document’s attribute that will be saved to the database along with it.

So, this form field looks exactly like what we need. It displays this form attribute, which in its turn represents this OrderState document’s attribute. The type of this document’s attribute is a reference to the SalesOrderStatuses catalog, living up here. So, now I can be 100% sure the application supports this functionality.

There is a catalog for SalesOrder statuses and there is a SalesOrder document attribute that stores a reference to this catalog. The functionality is here, it’s just somehow disabled by default.The question is how?

Here is an idea. There is a single Status field in the SalesOrder document form at runtime. But there are two identically looking fields in the form at design time. The only way for this to work is having a piece of code hiding one of them and unhiding another one depending on some conditions.

And here is one more hint for us. Both fields come with these Close order links that obviously get hidden and unhidden together with them. This is why they are combined into these two invisible groups - GroupStatuses and StateGroup - to more easily play with the visibility of the entire group of fields. So, what I would do is search for this GroupStatuses name in the form module, like this. And here we go.

This is where one of the groups gets hidden. And here is another one. And this is the condition that decides which one to hide. The condition reads the Functional Option called UseSalesOrderStatuses.

So, this is what controls the functionality I need. Functional option is, basically, a flag that is used to switch selected functionality on and off. If I were you, I would click this link to learn more about this Metadata Object.

And now, let’s go and trace this guy in its natural habitat. This is where the Functional Options live. And this is our guy. Functional options do not store data themselves. Instead, they use other objects - mostly Constants - to do this job for them. And this is where it’s set up. So, this functional option stores its value in the UseSalesOrderStatuses constant. And here it is. So, this constant value controls whether a user can change the SalesOrder status list or not.

Now we need to find a form that allows to change this constant value. So, I’m searching it across all forms. And here we go: two forms with this constant.

Let’s check out the first one. And here is our constant. Great. Now let’s find where this form is opened from. And this is the command that opens our form. Here it is in the metadata tree. And this is where it lives in the command interface - in the Subsystem called Accounting Settings. Except, there is no Subsystem with such a name. But don’t you worry. Just try to look it up like this. And here we go. This is what we were looking for. This sub-subsystem lives inside of this subsystem, that should be displayed under this name in the UI.

OK, looks like now we know all we need, so let’s switch to the application and check out our findings. Settings subsystem. Here. Clicking it. Sales command. Here. Going in. And… Ta-da. This is our constant. Turning it on. And now this link got accessible. So, let’s click it. And now I can create my own status list like this. 

Let’s check the SalesOrder document. And these are our new statuses. And, of course, there are many more Functional options switching on and off various pieces of the application functionality. So, definitely check them out first when you’re looking for some missed feature. 

The important thing to note about these UX settings (usually implemented using the Functional options) is that they are global. As soon as any user switches these guys on or off, the functionality controlled by these options changes for all the users. Unlike them, the UI settings are local. Any UI setting made by the current user affects this user and this user only.

What UX and UI settings have in common is that they are stored in the same database along with the application and all the data. So, they go wherever the database goes and get restored along with the database’s backup.

The window we are looking at now is called the Main Window. It consists of the Home page - this big central part of the window, and panels - these narrow stripes surrounding the Home page from all sides. A user can set up the panels using this Panel settings submenu. And this is how it works.

These are our open panels. I can move any of them to any side of the window like this, make them share one side like this, or like this, or even drop any of them down to this grey area to hide it completely like this. After I’m done playing I can restore the default and go take a look at the Home page settings.

What we see here on the left is the list of forms hand-picked by application developers as available on the home page. I can take any of them and drop it to the left or right side of the Home page like this, remove the forms I don’t need any more, change the forms’ order, and here we go - completely different home page honed specifically for my liking.

So, this was the Main window. Other forms also have settings that live up here in the Change form menu. The settings are pretty self-explanatory. I can hide fields I don’t need, change fields’ order, display fields that live in the object but weren’t included into the form by developers, play with groups and so on.

Object lists like this one have additional settings, where I can set up filters, change the sorting order, and set up an object's appearance depending on some conditions, as it was shown in this episode on the link down below.

A big story of its own is report settings. Most of the reports allow a user to set them up on several different levels: from specifying the report parameters and selecting different predefined report variants to the radical redesign of the way the data are processed and displayed. This topic was discussed in detail in this episode on the link. So, this is our UX/UI settings.