Why can I see a request queue, but my user cannot?
In the Queue Details tab of your request queue/project, ensure your user fits the criteria of the “Who can add requests to this queue?” field.
Watch this video for more details:
Transcript
We’re answering the question, why can I see a request queue, but my user cannot? Here is the Queue Details tab of the Marketing Unplanned Work Request Queue. When Publish as a Help Request Queue is checked, the Who can add requests to this queue list appears. This means basically who can see this request queue in their request list. The default is Anyone, which means everyone in the organization can see this request queue. If someone can’t see this request queue, it means you have checked one of the other options. People with view access to this project means someone has to have this project shared with them to see this request queue. They can be shared with them directly as an individual, or they may be part of a team the project is shared with. Or they may have inherited sharing rights by having another object, like the program this project is in, shared with them. People in this project’s company means everyone who is in the same company as this project is in, can see the request queue. You can see the Company field in the Project Details screen. A company doesn’t have to be designated for a project, and no company is specified here. That’s why there is no company name provided here in parentheses. People in this project’s group means everyone who is in the same group as this project will see this request queue. You can see this is the Marketing group, and that’s why Marketing is showing up next to this option in parentheses.
I gave users access to the queue, but now they can also see the request queue project. Why?
In the “Who can add requests to this queue?” list, if you chose “People with view access to this project” then anyone you give view rights to for the sake of using the request queue will also be able to view the request queue in a project list. To avoid this, use the “People in this project’s company” or the “People in this project’s group” option.
Can I turn a request into a project?
Yes. You can convert issues into tasks or projects depending on what is needed.
You can use the Search field in the navigation bar or find it listed in the Projects area.
If you open a request from the request queue you can click on the project name in the breadcrumbs area.
Can I transfer the information from a request custom form to a project custom form?
Yes. When you create a custom form select both Project and Issue as the object types. You can also edit a project custom form to include the issue object type and vice versa.
Attach the custom form to the request. When you convert the request to a project the custom form will automatically attach to the new project and the values contained in any fields will appear in both the request and the project custom forms.
I’m looking at a project or task report. How can I find out what request this object originated from?
You can access fields in the Converted Issue and the Converted Issue Originator field sources to add that information to your project and task reports.
Watch this video for more details:
Transcript
We’re answering the question, I’m looking at a project or task report. How can I find out what request this object originated from? When creating a project report, you can view information about the converted issue, which is the issue that was converted to a project. There are lots of issue fields to choose from. We’ll choose the name of the issue that was converted, and its age. The converted issue originator is the user who created the issue that was converted, and we can see that all the user fields are available to us here. We’ll choose the originator’s name. We probably want to filter our report so that we only see projects that were created by an issue conversion. When we look at the filter options, we only see the converted issue originator fields. That’s fine, all we care about is whether or not an issue was converted. So we can filter off the converted issue originator ID. If there is an ID in the converted issue originator ID field, then we know there was a converted issue as well. So we can just filter to see all the projects where the converted issue originator ID field is not blank. We’ll save this and call it Conversion to Project Info. And there we have the project report. The task report is similar, but different enough that it’s worth taking a look at. Here you can view lots of information about the converted issue originator, but not much about the converted issue. There are only two fields available, converted issue entry date and converted issue name. So we’ll select those, and we’ll choose the originator’s name again. Do it a little different this time, if we just search for name, we can go down to the objects here and find it pretty quick. But in the filter, we have all the fields for both the converted issue and the converted issue originator. So let’s filter on the converted issue ID this time. We’ll call this Conversion to Task Info. And there you have it.
What’s the best way to filter for request queues in a report?
If your project filter includes Queue>>Is Public>>Equal>>None your report will show only projects that are NOT request queues.
If your project filter includes Queue>>Is Public>>Not Equal>>None your report will show only projects that ARE request queues.
Watch this video for more details:
Transcript
We’re answering the question, what’s the best way to filter for request queues in a report? Remember that when we created our request queue, we had to first check the Publish as Help Request Queue checkbox. This gave us a chance to select how we want people to see our request queue. When creating a filter in a project report, these options are contained in the Is Public field under Queue. So if we want to see all the request queues that are accessible based on the user’s group, we can do it with this filter. We’ll call this Request Queues Viewable Based on Group. So we have two of them. If we just want to know whether or not a project is a request queue, this is how we do it. We’ll make a copy of this report, edit it. I’ll go ahead and change the name right now to All Request Queues. We need to change the filter to Queue is public not equal to None. You can imagine other ways to do this, but not equal to None is the one that works in all cases. I’m also going to add Status as a column in the view. And we’ll save it. You can see that the statuses of these request queue projects are not all the same. Some are current, some have a request queue status that is a custom status that equates with current, and some have a status of planning. They’re still request queues, but they’re just not active. As far as this report is concerned, that’s fine, because we’re not checking the status in this filter. If you just want to see active request queues, we’ll copy this report again and add another filter. Edit it. Change the name to Active Request Queues. And then we’ll add one more filter. Now this time we’re going to go not just for status, but for status equates with. So any status that equates with current will make this an active request queue, as long as it also has Queue is public not equal to None. Save that.
And there you have it.
Is it a good idea to create a custom status of Request Queue?
Some customers create a custom status of Request Queue that equates with Current. They can then run a report showing all request queues or easily exclude request queues from a report. While this has the advantage of being more user friendly than using Queue>>Is Public>>Not Equal>>None, it has the disadvantage that people creating request queues may forget to use it, since the Current status works just as well and is what they’ll see in most of the training material. For that reason many customers choose not to use a custom status of Request Queue.
However, if you’re already using the Request Queue status in your organization and you just want a way to make sure it’s being used properly (or fix cases where it isn’t), you can create the Active request queues report described in the video above, and change the filter for Project>>Status Equates With>>Equal>>Current to Project>>Status>>Equal>>Current. This will show you all active request queues that are using the Current status instead of the Request Queue status you want them to use. Select all the projects that appear and do a bulk edit to change the statuses to Request Queue.
