Expand my Community achievements bar.

Latest Community Ideas Review is Out: Discover What’s New and What to Expect!

Pulling the Request Queue name into a project report column

Avatar

Level 4

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. 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

13 Replies

Avatar

Level 4

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

Avatar

Community Advisor

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"?

Avatar

Level 4

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

 

Avatar

Community Advisor

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.

Avatar

Level 4

"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?

 

Avatar

Community Advisor

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. 

Avatar

Level 4

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.

Avatar

Community Advisor

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. 

Avatar

Level 4

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

Avatar

Community Advisor

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!)

Avatar

Level 4

yeah,

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

Avatar

Community Advisor

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!