Enforce event ordering

[Arnei]

WILL BREAK THE UI WITHOUT THE REQUIRED BACKEND CHANGES: opencast/opencast#6461

The events table is sorted by a sort parameter. By default, this is the start date. If there are multiple events with the same start date, the sorting for those is left to the elasticseach index in the backend. Elasticsearch however does not guarantee any ordering. This may result in the order of events changing unexpectedly like in #1102.

This patch aims to solve this by adding a secondary sort parameter to the events query. The primary parameter still takes priority. For the secondary parameter, uid was chosen as it is the only field guaranteed to be unique.

More sorting parameters can lead to increased query times. If someone with an Opencast with many events could test the impact of these changes on the events.json request times, that would be great.

How to test this

Requires an Opencast with the PR opencast/opencast#6461 installed.

• Sort the events table by different parameters and check if the resulting sorting make sense.
• Compare the response times in the network tab of the developer tools.
• Check if Sorting may change when adding a note in the notes column #1102 is still reproducible or not.

[github-actions]

Use docker or podman to test this pull request locally.

Run test server using develop.opencast.org as backend:

podman run --rm -it -p 127.0.0.1:3000:3000 ghcr.io/opencast/opencast-admin-interface:pr-1103

Specify a different backend like stable.opencast.org:

podman run --rm -it -p 127.0.0.1:3000:3000 -e PROXY_TARGET=https://stable.opencast.org ghcr.io/opencast/opencast-admin-interface:pr-1103

It may take a few seconds for the interface to spin up.
It will then be available at http://127.0.0.1:3000.
For more options you can pass on to the proxy, take a look at the README.md.

[github-actions]

This pull request is deployed at test.admin-interface.opencast.org/1103/2025-02-03_10-32-21/ .
It might take a few minutes for it to become available.

[owi92]

I haven't tested the response times, only the ordering. While the specific issue of #1102 seems to be fixed, I can sill observe some jumping when randomly clicking filters (see screencapture). So in regards to

Sort the events table by different parameters and check if the resulting sorting make sense.

I wouldn't say that it does. (I tested with opencast/opencast#6461).

Bildschirmaufnahme.2025-02-07.um.12.22.37.mov