[Improvement] Project tagging improvement

[timdegroot1996]

Currently we use project_ to define projects. There have been discussions about moving this to a separate flag in the CLI.
As can be seen at this comment and some earlier comments.

This issue is discuss the desired solution.

Additional notes from other threads

project_tag:
I would keep the project_ logic in, regardless of what --projectname does, to preserve current functionality (also not worth the refactor effort imo)

--projectname:
Option 1: override the root suite name in the xml with the --projectname flag value (without project_)

# runs table column "name" would be api
robotdashboard -o output1.xml -o output2.xml --projectname api

Option 2: add separate runs table column for --project name values

robotdashboard -o output1.xml -o output2.xml --projectname api,webserver,someOtherProject

Both of these options would not allow to set the projectname value seperately for each xml to db push,
but I think that is okay, people can just run it multiple times if they want to specify differing projectNames for xmls.

How pressing of an issue do you think this feature is? For me it would be fine to add it as low priority to the backlog.

Mentioned for inspiration and possible good solution (consistency) for project as well

Regarding project version
To me, having to rerun robotdashboard for each project version seems fine, but if you want,
I can add the option to have a version_ project version tag. My preferred behaviour would be this:

# keep existing behaviour
robotdashboard -o output1.xml -o output2.xml --projectversion 1.0.0  # set 1.0.0 for all outputs in this command
# rerun for differing project versions
robotdashboard -o output3.xml  --projectversion 1.2.3
robotdashboard -o output4.xml --projectversion 7.4.2

# version_ tags
# set project_version column to value after version_ (and do not store version_ as tag (or maybe do, no hard preference))
robotdashboard -o output1.xml:version_1.0.0 -o output4.xml:version_1.2.3

[HuntTheSun]

Thanks for opening the issue!

I think I like what you described here the most. This does kind of overload the project as you named it because we give users a lot of flexibility and possible solutions. But it does solve every possible scenario of old and new users, flexibility wise.
If you agree let's handle it like this!
Small question regarding this, what will the handling be if you provide:
robotdashboard -o output4.xml:version_7.1 -o output5.xml:version_7.3 --projectversion 7.4.2

My solution would be:
Projects can have only 1 version, because our UI simply can't handle multiple versions 😄
project_ is leading as it is more specified for a singular output
(Small note: I think we should solve this differently for project_ because people can have multiple project_ tags per run, UI can also handle that)

Do I understand correctly?
regarding project version:
In the code example, if multiple versions are supplied per xml, either (via multiple version_ tags) OR (one version_ tag AND the --projectversion flag) have argparse fail and print a RTFM error
regarding project_ project name:
Keep the existing project_ logic

---

Questions regarding --projectname flag: (not technically pertaining to tags, but since we discussed it in the same breath)

(Quoting me) --projectname:
Option 1: override the root suite name in the xml with the --projectname flag value (without project_)
# runs table column "name" would be api
robotdashboard -o output1.xml -o output2.xml --projectname api
Option 2: add separate runs table column for --project name values
robotdashboard -o output1.xml -o output2.xml --projectname api,webserver,someOtherProject
Both of these options would not allow to set the projectname value seperately for each xml to db push,
but I think that is okay, people can just run it multiple times if they want to specify differing projectNames for xmls.

How pressing would you categorize this issue? For me its fine keeping it the way it is for now.
Also, would you prefer Option 1, 2 or sth entirely different?

[timdegroot1996]

@HuntTheSun

Do I understand correctly?
regarding project version:
In the code example, if multiple versions are supplied per xml, either (via multiple version_ tags) OR (one version_ tag AND the --projectversion flag) have argparse fail and print a RTFM error

1. I was thinking of not having it fail but just silently choosing the version_ ones if both are provided like this:
   robotdashboard -o output4.xml:version_7.1 -o output5.xml:version_7.3 --projectversion 7.4.2 would result in output4 with version 7.1 and output5 with version 7.3.

BUT

2. I also like giving an error though argparse and then telling the user something like
   "Error, you can only set 1 version per output, either use version_ per output or outputfolder, or use --projectversion for all provided folders."

I think option 2 is cleaner as unexpected behaviour is notified to the user (in our example 7.4.2 not being used is then at least told...)

regarding project_ project name:
Keep the existing project_ logic

Yes that is okay.

How pressing would you categorize this issue? For me its fine keeping it the way it is for now.
Also, would you prefer Option 1, 2 or sth entirely different?

I think this isn't a pressing issue at all and it can go to the bottom of the backlog like you mentioned. It is however easy to fix and for consistencies sake it would be nice to keep project_ and version_ kind of similar in usage. I can pick this up as well as the code is separate from --projectversion.

For clarification, in my mind project_ == project name == --projectname
All of these mean the same thing to me, which is the custom names that you can use to show your overview page bars in a custom way.

My final solution outline:

1. You can still provide custom project names with the tag project_ (currently available)
2. You can also provide custom project names with the new cli option --projectname (todo for this issue)
3. I'm not entirely sure if we should put it as tags or put it in a separate column.
   • Benefit of storing it separately in db: you can check out the different project tags in the run table in a separate column
   • Downside of storing separately in db: old versions will not work similarly and migrating tags to the > projectname column seems unfeasable
   • I'm already thinking about how to handle this in the dashboard by having to look at multiple fields (tags and projectname) if you want to then make correct views based on both options.
   • Conclusion for 3: I think we should just keep it in tags for ease of use. Maybe it's not as nice but if we always prefix with project_ our old logic stays intact and we can simply just add the new flag
4. Similar to the error handling of --projectversion I think it would be nice to warn users if they are using both options at once? Or does it make more sense since people can have multiple projectnames to just add them resulting in example below.

robotdashboard -o output1.xml:project_1:project_2 -o output2.xml:project_1 --projectname coolproject
# results in no error and the following in the tags field (if --projectname value doesn't start with project_, add it in handling?)
# results in:     output1.xml > project_1, project_2, project_coolproject
# results in:     ouptut2.xml > project_1, project_coolproject

Does this make sense?

[timdegroot1996]

@HuntTheSun I feel like the current working for the projectversion is quite nice. However as the project tagging (project_) is not used that much I feel like the entire rework is too much work, also keeping backward/forward compatibility in mind.

I suggest closing this issue as it is not that required. If someone requests something regarding this we can always open an issue at that time.