I think I found an odd behaviour with aggregated columns.
In the following link (https://www.outsystems.com/learn/lesson/856/intro-to-the-course/) on page 18, there is a note specifying this: “NOTE: It’s important to sort by the (green) PersonRoleId because it represents the aggregated column, that is part of the output, while PersonMovieRole.PersonRoleId refers to the original attribute that is suppressed from the output.
Sorting by an attribute that is not part of the output would have no effect.”
I think the platform should warn about that, as it is almost impossible to know that without consulting the tutorials.
Furthermore, let’s say we have the following dataset:
In the present tutorial, we are asked to create an aggregated attribute for a person’s full name, which leads to the following:
Now, let’s say I want to group by the ‘FullName’ attribute, which is presented by the following (i’ve cancelled the auto hide of the FullName column for the sake of the example):
Now, head to the Sorting tab to add a new sort. This is the presented window:
As you may see, there are 2 FullName attributes, but only one of them is an aggregated column (I believe), which leads to possible errors on querying the database, since only of them will be part of the query.
So, that is one possible problem, since non aggregate columns should not appear inside the box, when having a group by clause, avoiding missorts.
Now, something weird seems to be also happening, because If I change the name of the previously hidden FullName column, we end up with the following:
Now, the first column changed also its name, seeming to be the same column (which is not the case). Then, click to edit the first column’s name to this:
However, clicking it to edit a second time, triggers the column to go back to its original naming (the expected one):
I am not sure why this problem is happening, but I tested several times with no change.
That seems like an interface bug. The aggregate editor is still not in a state we'd want it to be...