Incorrect display name of available "Advanced Service" APIs

[tehhowch]

Expected Behavior

When using clasp apis list, the displayed <api name> is what can be passed in clasp apis enable/disable <api name>

Actual Behavior

Services with names that have "-" (e.g. bigquery-json) or specialized "Advanced Services" bindings (AdminDirectory, AdminReports) are not properly reported by apis list:

If attempting to then enable the API by displayed name, e.g. clasp apis enable bigquery, HTTP 403 "The caller does not have permission" is raised, and clasp then states:

API bigquery doesn't exist. Try 'clasp apis enable sheets'.

Steps to Reproduce the Problem

1. clasp apis list
   • shows admin twice (for AdminDirectory & AdminReports)
   • shows bigquery
2. clasp apis enable bigquery
3. Receive large error trace re: HTTP 403, and message "API bigquery doesn't exist. Try 'clasp apis enable sheets'."

Specifications

• Node version (node -v): 8.11.2
• Version (clasp -v): 2.0.1
• OS (Mac/Linux/Windows): Win 10

[erickoledadevrel]

Thanks for issue report. There seems to be two distinct issues here caused by some faulty assumptions:

1. That the service ID used in Apps Script will match the prefix of the serviceName used in the serviceusage API. While almost always true, for the BigQuery API the Apps Script service ID is bigquery but the serviceName is bigquery-json.googleapis.com. See assumption in code here.
2. That every service ID maps to only one advanced service. While almost always true, the admin service ID maps to both the AdminDirectory and AdminReports advanced services, distinguished by the version. See assumption in code here.

I think we could fix the first problem by including an optional field serviceName in the AdvancedService type that specifies the serviceName to use in cases when it differs from {serviceId}.googleapis.com.

Fixing the second problem could probably be done by adding a version argument to apis enable, which would be required when the service ID maps to more than advanced service.

@grant - Does that sound reasonable?

[grant]

Sounds reasonable. Note that commander has a bug where --version prints the commander version, thus we've been using versionNumber for version flags.

Would an interface like this solve the issues?

clasp apis enable --serviceName 'calendar' --serviceId 'calendar-json' --versionNumber 'v1'
clasp apis enable slides # shortand for most APIs, throws error if there are multiple versions.
clasp apis enable slides:v1

[erickoledadevrel]

Would all of those still require that the API is already included in the PUBLIC_ADVANCED_SERVICES list? If not, how would we determine the user symbol? If so, then it would be easier to just add the service ID to that struct rather than have the developer type it in.