Report API: what controls the columns presented on the report?

[pco88]

So on the reports, we add columns of data as needed, eg name, custom form parameter etc. I want to be able to change the columns of the report by API, eg instead of name, custom form parameter, that report should now contain, ID, custom form parameter. What is the call that allows me to change this?

[AnthonyIm]

Hi -just to confirm I'm understanding things correctly, You are looking to use the API to update a bunch of reports in Workfront by changing the column Name to ID?

Looking at the API explorer, I'm not seeing a way to get to the column info. Unless they are "portalTabSections" but when you look at that object, it doesn't look like it is a report column

[pco88 · Accepted solution]

HI @Anthony Imgrund‚ , that's correct. I initially didn't see anything that could refer to the columns in the report but digging deeper, I may have found my answer.

It is in the viewID of the report. Then I would have to change the contents of this view. I'm not sure now whether I want to continue automating this process as it may be more work than actually doing it manually. Anyway, thanks for the reply.

[AnthonyIm]

Oh wow! Interesting... so if you created a view with the columns you wanted, you could just do an easy PUT command to update the viewID to the new one.

Learn something new every day! So far haven't needed something like this, but I love knowing it is possible :)

[Doug_Den_Hoed__AtAppStore]

Hi Polly and Anthony,

I'm late to the party, but glad to see you sorted out what you need. As an aside, this seems related to our UberFilter solution (which applies a filter to all the related reports on a dashboard), but to add just a bit more context to your discussion:

• yes, the viewID on a report is what determines the report's "Default" view
• if you select an Existing View (bottom right) in the report definition, you're effectively swapping the viewID
• you could do the same thing (on mass) via the API
• best practices -- although I admit I don't always take the time myself to do so -- is to name a specific view (usually 1:1 with its first main report) and maintain it separately from the report, then when it is ready, apply it to the report, so that the view can be more easily reused across multiple reports (via the Existing View dropdown or API), and can independently shared and leveraged by users so they can apply it to other reports on the fly
• Filters and Groupings work in the same fashion

Regards,

Doug

[pco88]

@Doug Den Hoed‚ , that's a good idea regarding just creating the view and swap the ID. I may just proceed with automating this after all.