Pulling the Request Queue name into a project report column

[SethPorrazzo]

Hi All, is there a way to pull in the name of the request queue into a project report as a column?  I've been going through all the possible fields presented as options for the report but haven't found a field that shows where the project's request originated from. Hopefully by bringing this field in we can make a distinction between the volume of projects coming from each request queue. 

[skyehansen]

I'm curious about whether you've tried the code from here? https://experienceleaguecommunities.adobe.com/t5/workfront-questions/how-to-capture-show-queue-topic...

[SethPorrazzo]

I tried this, but it doesn't pull in the queue name, only the topic name if a topic was used.

[skyehansen]

using the same principle from the other post (I'll leave it as an exercise to you to follow through), what if you swapped in "convertedOpTask:queueDef:project:name"?

[SethPorrazzo]

interesting, would there be any additional logic if the report was a task level report vs a project level report?

[skyehansen]

I'm not sure what you mean by "additional logic" so just to be as clear as possible; if you're looking at the two posts and my two answers side by side:

Your question is asking about projects which were converted from a request and asking to pull info.

The original question is asking about tasks which were converted from a request and asking to pull info.

My answer for both is the same: it is critical that you become familiar with how to use the API explorer, and also just as critical that you understand what workfront calls particular objects.

In this case, for both a task and a project that are converted from a request, workfront calls that request the "convertedOpTask" - no change in name. Once you know this, you can reference this object from either the task or the project listing in the API explorer in the same way.

This is why you can shift the code from one report to the next. Workfront calls the object the same on both reports, and you can therefore reference the object in the exact same way.

This same rule applies for a few different objects. For example: access rules. This is why if you have any access rules code in a project view, you can lift and shift to a task or a template, or a program or an issue report view, without changing or thinking about it.

Back to why there would be a "change in logic"(??). My interpretation of your question is, "if you were in a task report and looking for the request that got converted to this task's project", then yes -- this would be a different story involving different code.

[SethPorrazzo]

"Back to why there would be a "change in logic"(??). My interpretation of your question is, "if you were in a task report and looking for the request that got converted to this task's project", then yes -- this would be a different story involving different code." - yes, this is what I was referencing.

Is the solution as simple as entering {project}.{convertedOpTask} in text mode?

[skyehansen]

try it and see? 

Academically speaking, I’ve heard that there’s a 3-hop (3-“connection”) limit. If that’s truly the case, adding one more level to reference a project’s converted issue’s queue’s project’s name, from your task report, could cause the universe to implode. 

[SethPorrazzo]

how about this workaround (in theory). Say we create a custom calculated field at the project level to capture the request queue's name, what would that look like? I've tried using some of the API fields provided by I'm not having any luck. If we were able to capture the request queue's name as a custom field at the project level, we could bring that field into a task report. 3 lefts make a right.

[skyehansen]

I hear you! And in any other situation, this could work! I happen to have heard on the grapevine that converted issue data is either extremely difficult or actually impossible to bring over, so I am not surprised you are having problems. But yes, theoretically, this is exactly what it takes to get rid of a level or two. 

[SethPorrazzo]

ugh, I was afraid of that.  thanks for all of your help Skye.

[skyehansen]

So I finally have some free time! On the project form, I'm looking at the following for the queue name:

{convertedOpTask}.{queueDef}.{project}.{name}

Are you saying you tried this and it errored out, or if not, where did you error out? 

(I think it actually used to be more difficult, before they updated the syntax to camelCase -- the old style syntax definitely used to error out on me!)

[SethPorrazzo]

yeah,

{convertedOpTask}.{queueDef}.{project}.{name} was the exact calculation I used.  It kept giving back the result "N/A" whenever I would recalculate expressions.

[skyehansen]

oh interesting! I wonder if this is what people were talking about -- whenever I try and save the custom form, it gives an error message (even though it allowed the calculation to begin with).

You COULD try sending a ticket in to Support -- my guess is that they won't support it showing up in a calculated field due to it being part of the "unsupported" API ...but you can always try!