Querying a metric by its internal ID returns an "unauthorized_metric" in some cases

[nickyreinert]

Expected Behaviour

Sometimes the API does not return all required metrics using the metrics-endpoint, in this case you may use the internal metric ID that you can obtain from OBERON. You may then build your query like this:

{
    "rsid": "reportsuite",
    "globalFilters": [
        {
            "type": "dateRange",
            "dateRange": "2022-04-01T00:00:00.000/2022-05-01T00:00:00.000"
        }
    ],
    "metricContainer": {
        "metrics": [
            {
                "columnId": "0",
                "id": "metrics/cm1234_abc",
                "sort": "desc"
            }
        ]
    },
    "dimension": "variables/marketingchannel"

}

This returns the selected metric for all marketing channels as expected. If you add another metric like this:

{
    "rsid": "reportsuite",
    "globalFilters": [
        {
            "type": "dateRange",
            "dateRange": "2022-04-01T00:00:00.000/2022-05-01T00:00:00.000"
        }
    ],
    "metricContainer": {
        "metrics": [
            {
                "columnId": "0",
                "id": "metrics/cm1234_abc",
                "sort": "desc"
            },
            {
                "columnId": "1",
                "id": "metrics/visits
                "sort": "desc"
            }
        ]
    },
    "dimension": "variables/marketingchannel"
}

I would expect visits and the selected metric.

Actual Behaviour

Instead the API returns an error:

{'columnId': 'abc', 'errorCode': 'unauthorized_metric', 'errorId': '123, 'errorDescription': 'User does not have access to the requested metric'}

You have to remove the "metrics" suffix to make it work:

{
    "rsid": "reportsuite",
    "globalFilters": [
        {
            "type": "dateRange",
            "dateRange": "2022-04-01T00:00:00.000/2022-05-01T00:00:00.000"
        }
    ],
    "metricContainer": {
        "metrics": [
            {
                "columnId": "0",
                "id": "cm1234_abc",
                "sort": "desc"
            },
            {
                "columnId": "1",
                "id": "metrics/visits
                "sort": "desc"
            }
        ]
    },
    "dimension": "variables/marketingchannel"
}

So the API should not return an "access denied" when it's actually an misconfiguration.

Besides that, the API apparently accepts the query using "metrics/123_abc", but not if you query another metric with the same syntax. Which is inconsistent behaviour.

[parrish488]

@nickyreinert In the examples you're providing, is cm1234_abc a custom made calculated metric? If so, it shouldn't be prepended with metrics/, it should just be passed as the full ID. I believe what you're saying is "access denied" is happening instead of something more helpful, like "metric not found" or something like that. Am I understanding correctly?