search

fortify / fcli

fcli is a command-line utility for interacting with various Fortify products
https://fortify.github.io/fcli/
Other
29 stars 16 forks source link

`fcli fod lookup-items` #361

Closed rsenden closed 12 months ago

rsenden commented 1 year ago

The behavior of the fcli fod lookup-items list command isn't very intuitive / somewhat inconsistent with other fcli commands.

Apparently, fcli fod lookup-items list without parameters lists the lookup items for All. To see the details of for example the TimeZones entry, I'd expect to do something like fcli fod lookup-items get TimeZones. However, apparently there's no get command; instead I'd need to do fcli fod lookup-items list --type TimeZones.

This feels inconsistent with other fcli commands. Having a get command that outputs a list is also somewhat inconsistent, but still feels more natural. Maybe if we rename lookup-items to something else (see #362), we can come up with a more natural command structure?

kadraman commented 1 year ago

Yes this makes sense I will add individual list and get commands. I won't rename it for now and still considering whether this is appropriate :)

rsenden commented 12 months ago

From https://github.com/fortify/fcli/issues/362#issuecomment-1649298833:

As for lookup-items, are you saying that this is only useful for the fcli fod rest call command, not any of the other fcli fod commands? In that case, what about moving this functionality to fcli fod rest lookup or something similar?

kadraman commented 12 months ago

Unfortunately, the lookup-items are just typedefs/enums which are used throughout the API. However I do like the idea of moving it under rest call commands :

fcli fod rest lookup-items list
fcli fod rest lookup-items get --type  TechnologyTypes

I don't mind whether its lookup or lookup-items that's used. What do you think?

rsenden commented 12 months ago

With my question, I meant to ask whether end users would only need these commands for looking up items when using the fcli fod rest call command, or would they also need to use these commands to understand what input is allowed for certain options on other fcli fod commands?

I.e., suppose we have an option --technology-type somewhere, would users need to use these lookup commands to find out what values can be passed to this option, or does this option use an enum to define allowed values (and list those allowed values in the option description)?

If the output of the lookup commands is only relevant when users want to manually invoke API endpoints through the fcli fod rest call command, then we should move this to functionality to the fcli fod rest command tree. If the output is also relevant for option values on other commands, we can probably still choose to have this under fcli fod rest (making it clear to users that these values correspond directly to the FoD REST API values), or keep it as a stand-alone entity; not sure which is better?

Note that we only allow 3 levels of sub-commands, so we can't have fcli fod rest lookup-items list or fcli fod rest lookup-items get. Anyway, we could simply have the following, which in this case maybe even looks much more intuitive, without having to bother about lookup versus lookup-items:

fcli fod rest lookup <type, default=All>
kadraman commented 12 months ago

The output is relevant when using both the REST API directly and other commands, however I like your suggestion:

fcli fod rest lookup <type, default=All>

so will implement this 😃

rsenden commented 12 months ago

Implemented