ex2_ground_station_software now has labels describing what each command argument is (see here for example). It would be helpful to operators if these arguments are labelled in the help menu so that they know what each of them do.
Additional Details
The labels are the args dictionary keys, while the value is their expected data type. Since it might be cluttered if we show both the label and datatype, we should only show the keys (label) since they are be descriptive enough.
As many API endpoints rely on the num_arguments field in the Telecommands model, keep it as it is and instead add a new column storing these labels.
Although PostgreSQL supports SQL Arrays, sqlite3 does not (which we still use for unit tests). An idea I have in storing these labels would just be a single string with the labels separated by a comma (eg. 'arg1,arg2,arg3,...'). We can then separate these when rendering the webpage
Once added, argument labels can also be used in AutomatedCommands and Flightschedule to label the argument text boxes, instead of having 'Argument 1', 'Argument 2', etc. as labels.
Brief Feature Description
ex2_ground_station_software now has labels describing what each command argument is (see here for example). It would be helpful to operators if these arguments are labelled in the help menu so that they know what each of them do.
Additional Details
The labels are the args dictionary keys, while the value is their expected data type. Since it might be cluttered if we show both the label and datatype, we should only show the keys (label) since they are be descriptive enough.
As many API endpoints rely on the
num_argumentsfield in the Telecommands model, keep it as it is and instead add a new column storing these labels.Once added, argument labels can also be used in AutomatedCommands and Flightschedule to label the argument text boxes, instead of having 'Argument 1', 'Argument 2', etc. as labels.
Priority
Low