Timetracking Overview Improvements

[fm3]

Contributes to #7788 by fixing

• left-aligned annotation stats in table
• faster sql query for time summed by annotation (on a production database with 6M annotations: before: 7000ms, after: 100ms)
• prepares backend to filter by annotation state
• search in dropdown by typing project name instead of id

Not included for now:

• frontend for filtering by annotation state
• include annotation state in csv and displayed table

URL of deployed dev instance (used for testing):

• https://timetrackingfilterbyannotationstate.webknossos.xyz

Steps to test:

• Annotate some, open timetracking page, expand user entries, should be fast, look pretty even for annotations with many trees.

Issues:

• contributes to TimeTracking overview Follow-up #7788

---

• Updated changelog
  webknossos/webknossos/client) if relevant API parts change
• Removed dev-only changes like prints and application.conf edits
• Considered common edge cases

[knollengewaechs]

This is just a prerequisite to show the annotations state in the table and in the CSV, and to filter it, right?

[fm3]

Right, only for the filtering at this time. I wrote this before I learned that the priority is lower for now. I guess we can use it in the frontend in a later iteration, or remove it again if we decide we don’t want to go for this option :)

[knollengewaechs]

I took a look at the frontend code and tested the code and I think both looks good :) thank you!

[MichaelBuessemeyer]

The backend code also looks good to me 👍

@fm3, did you take measurements on the speed up of the summedByAnnotationForUser query? If you still have them, could you please add them to the PR for documentation purposes? 🙏

Please note that I did not do any testing and only looked at the code as @dieknolle3333 already tested the changes :)

[MichaelBuessemeyer]

Isn't the order of parameters here important? One common rule is that Optional Parameters should be last in param order. Does this apply here as well (at least as a style)? I guess play forwards the projectIds as Some(null) automatically in case the param is absent. Thus, the order is likely irrelevant.

But looking at the file, in most cases the option types are last in order.

But as this is likely not a syntax error / error in the code, also feel free to ignore this comment :)

[fm3]

I think the order isn’t relevant here for the compiler, as this is, so to speak, always called by name. If an optional parameter is omitted from a request query, it is auto-filled with None (different from Some(null). In fact we want to avoid null wherever possible, since the type-checker does not deal with it).

However, you are right; at least for style, I’ll move the new parameter so that the optional ones stay last.