Allow configuration of sorting for Project Lists

[klaustopher]

Implements https://community.openproject.org/work_packages/51671

[klaustopher]

I don't know how you got the screenshot you posted, but there is definetly spacing, so I don't know what commit you tested. I'll add the headlines. But the way how the dropdowns are styled are how the primer component looks. There is no chevron indicator, and I don't think we should apply a special styling here...

[klaustopher]

Sorting by "Project hierarchy" is currently mutually exclusive with sorting by any other column. The reason for this is the inability to sort by a second/third argument on each level. That is why the projects table upon clicking on the hierarchy sorting trigger resets the sorting to only work with the "Project hierarchy".

Sorting by "Project hierarchy" only makes sense in a single direction. When having selected that option, the "Asc"/"Desc" toggle should be removed I think.

This is a bit annoying as we are already doing special things like adding the lft as a sortable column, because it is nowhere defeined. Now we also need to treat it specially and remove the order buttons. Could we make the sorting by lft somehow explicit, and define inside of the Order class what directions it supports and then forward this info to the frontend? Also, in the WorkPackages Angular view, it's not even possible to add the hierarchy sorting in the Sort By dialog

[klaustopher]

When exporting a project list (e.g. to PDF) the sort order should be applied as well.

The sortBy params are correctly forwarded to the export, here's an example:

Opening

http://localhost:3000/projects?columns=name+created_at+public+cf_13&sortBy=[["cf_13","desc"],["name","desc"]]

I see that the export link correctly points to

http://localhost:3000/projects.csv?columns=name+created_at+public+cf_13&sortBy=[["cf_13","desc"],["name","desc"]]

So that looks correct. I added a debug output to the Projects::ExportJob and when I output the query there, the orders param gets converted into a hash and it has the wrong order in there:

worker  | ****************************************************************************************************
worker  | #<Queries::Projects::Orders::NameOrder:0x000000032cf5af08>
worker  | #<Queries::Projects::Orders::CustomFieldOrder:0x000000032cf5a8a0>
worker  | ****************************************************************************************************

So, something goes wrong when the sortBy params are converted to the order for the export job. I'll take a look what's going wrong internally there. But that should be a problem that has already been in the code for exporting code.

---

Also, looking at the job params that get stored in the database, we already have a wrong order:

{
  "job_id": "2277295d-025e-4383-8dfe-e436e8c0022e",
  "locale": "en",
  "priority": 7,
  "timezone": "UTC",
  "arguments": [
    {
      "user": {
        "_aj_globalid": "gid://open-project/User/4"
      },
      "query": {
        "user": {
          "_aj_globalid": "gid://open-project/User/4"
        },
        "orders": {
          "name": {
            "value": "desc",
            "_aj_serialized": "ActiveJob::Serializers::SymbolSerializer"
          },
          "cf_13": {
            "value": "desc",
            "_aj_serialized": "ActiveJob::Serializers::SymbolSerializer"
          },
          "_aj_symbol_keys": [
          ]
        },
        "filters": [
          {
            "name": {
              "value": "active",
              "_aj_serialized": "ActiveJob::Serializers::SymbolSerializer"
            },
            "values": [
              "t"
            ],
            "operator": "=",
            "_aj_symbol_keys": [
              "name",
              "operator",
              "values"
            ]
          }
        ],
        "selects": [
          {
            "value": "name",
            "_aj_serialized": "ActiveJob::Serializers::SymbolSerializer"
          },
          {
            "value": "created_at",
            "_aj_serialized": "ActiveJob::Serializers::SymbolSerializer"
          },
          {
            "value": "public",
            "_aj_serialized": "ActiveJob::Serializers::SymbolSerializer"
          },
          {
            "value": "cf_13",
            "_aj_serialized": "ActiveJob::Serializers::SymbolSerializer"
          }
        ],
        "group_by": null,
        "_aj_symbol_keys": [
          "filters",
          "orders",
          "group_by",
          "selects",
          "user"
        ]
      },
      "export": {
        "_aj_globalid": "gid://open-project/Projects::Export/7"
      },
      "mime_type": {
        "value": "csv",
        "_aj_serialized": "ActiveJob::Serializers::SymbolSerializer"
      },
      "_aj_ruby2_keywords": [
        "export",
        "user",
        "mime_type",
        "query"
      ]
    }
  ],
  "job_class": "Projects::ExportJob",
  "executions": 0,
  "queue_name": "default",
  "enqueued_at": "2024-05-08T06:41:44.632141000Z",
  "scheduled_at": null,
  "provider_job_id": null,
  "exception_executions": {
  }
}

[ulferts]

Good job on digging up the reason for the export problems, @klaustopher