[Improvement] Merge runtags, version and customfilters into customfilters

[timdegroot1996]

Currently there are 3 types of "filters" you can provide to your runs.

1. tags which are set on the output.xml level and with the --outputfolder or --output parameter.
2. projectversion which you set with --projectversion also on the output level but with a custom parameter.
3. customfilters which you set with --customfilters and these are also on the output level but again with another custom parameter.

The "nicest" implementation is the customfilters one since that one scales infinitely and can also handle filters like tags or versions that are now separately added. In the future it would be nice to make this all into a single CLI option which is customfilters so that everything works the same.

Design decisions when implementing:

• How to handle backward compatibility? Is that even possible at all?
• How to handle the overview page filters (version and others?), suggestion by @HuntTheSun in this comment could be good: feat: add support for custom filters in output data processing #286 (comment)
• How to handle the server implementation since everything is separated there now

[vladislav1q]

I have a question. After implementation of custom filters, i noticed, there is no implementation in overview section. It seems not obvious, why user cannot apply some custom filter or tag to overview. It seems to me, that either filters should be implemented in "Overview" page or filters should be added in sections on this page. Option 2 (see attachment) is more rational.

[HuntTheSun]

How to handle backward compatibility? Is that even possible at all?

Good question tbh. If a new robotdashboard is run against an old DB, the only thing I could see would to convert the old projectversion and tags field to a CustomFilter, but runs can have multiple tags, I'm not sure if thats really convertable/backwards compatible. Maybe only converting the projectversion and consider leaving the tags in?
We could also shoehorn the tags into a CustomFilter key with a tag-only separator like '|' for example.
so the customfilter would be like randomFilter=randomFilterVal:TAGS=tag1|tag2|tag3:anotherFilter=anotherFilterVal
and do string parsing from there?

What would be your preference if we can't make it pretty, do it hacky or neglect backwards compatibility?

How to handle the server implementation since everything is separated there now

I'm sorry I don't follow, what do you mean by that?