ID vs Title/Name

[vvvityaaa]

Right now we have a mess with IDs and titles/names used as options for different commands. For instance, use-command takes for any command group ID as a specified option. On the other hand, all other commands use title/name as a specified option. This, for example, leads to confusion as mentioned in #96.
I would suggest getting rid of ID as an option for use-command and using title/name instead.

[buschNT]

@vvvityaaa Here my thoughts.

This inconsistency was addressed in issue #30 (maybe the description should have been better). I would not only use title/name as option, as we are working with IDs internally. Meaning, if you enter a name/title/slug etc. we would often need to determine the corresponding ID anyway in order to make efficient API requests, since our services use IDs as filter.
Furthermore the context uses IDs. All functions using a context require IDs and do not work with name/titles.
And IDs should prevent duplicate names/titles problems, even if this should currently not occur, I would not build the underlying logic based on a value which can potentially be not unique.

Thus the idea was: allow name/title and IDs as arguments for all commands and map all values directly to IDs. The mapping to the ID should be one of the first things to do in all commands and can likely be generalized for all commands.

This mapping is can first be done by using the API, but maybe later on it can be extended to use some kind of local cached mapping.