search

traggo / server

self-hosted tag-based time tracking
https://traggo.net
GNU General Public License v3.0
1.17k stars 58 forks source link

Allow displaying dashboard entries based on tag value rather than only tag key #139

Closed Enthouane closed 1 year ago

Enthouane commented 1 year ago

Is your feature request related to a problem? Please describe. Not a particular problem but rather a way to expand the dashboard's display capabilities.

Describe the solution you'd like This feature request is not limited to my usecase but it might be clearer with an example so here is my specific usecase : each tag key is a staff member and each tag value is an activity (example : person1:brewing ; person2:bar ; person1:bar ; person3:brewing and so on). I can summarize each person's activities but there is no way to sum up in a graph the whole "bar" weekly activity by person.

Describe alternatives you've considered Switch the key:value tag usage but it would only reverse the problem and i would not be able to sum up a person's activity in a graph...

jmattheis commented 1 year ago

Support tag values as keys for statistics would increase the complexity of the ui + backend, I don't think this should be solved like you described.

You could track the activities a little different and achieve something similar:

person:person1 activity:brewing
person:person2 activity:bar
person:person3 activity:bar

Now you could add diagrams with the activity tag and see the sum of all persons. To view the sum of a single person, this UI feature is required https://github.com/traggo/server/issues/102

Enthouane commented 1 year ago

Thanks for the advice and the #102 mention, i actually thought for a second that we were asking the same feature.

About my original request, my goal was also to keep it as minimalist and approachable as possible for users. It will be used by several people who are not as comfortable as i am with computers and having them manipulating many tags leaves room for error.

jmattheis commented 1 year ago

I understand, but I rather not implement two features that can achieve the same end result. And #102 is already implemented in the backend and also much simpler to implement.