What I want is for the board query to be based on the Project that the board is being viewed in from the user's perspective. My typical user workflow is for the user to select "Project" and then pick a board in that project based. For our company, boards are "Software", "Electrical", "Mechanical". And effectively I'd like to be able to create reusable boards where the query is for the "Project" that is selected. Our users never intentionally go to a board from the "Boards" dropdown.
Since the board can't reuse filters, I get into a lot of duplication right now. For example, rather than "Software" as a board, I need "Project X Software", "Project Y Software", etc. This also means I need to create "Project X Filter", etc. Making both development and execution of a consistent process across multiple projects tedious (the only part that I get to reuse is the 'workflow', I need to manually copy both the boards and filters for each project in JIRA which is an admin headache and prone to manual bugs as a result).
If the filter was able to handle "Project" (and in the case of directly selecting a board, I'd be OK with the result = NULL) then I would have a total of 3 boards, each board would only one filter and I could share this board with every project that shares a given workflow with zero changes. That is what I want to be able to do.
you can use the following Plugin to achieve this functionality:
It's working like a charm for us.
What Omar said, seriously how does Jira not have an option for "Oh your created a new project?" ..." Would you like a board like the other projects in this category or type? great, just click here and we'll copy that board over there just apply this project number for this board!!!"
Seriously, stop making other versions of jira and just FIX WHAT YOU'VE ALREADY MADE A MESS OF!!!! GRRR.
Sorry today is a day of atlassian rage!
Omar - I hear you. I don't have an answer for you (looking for the same thing), but what you're asking for makes complete sense. Your second post, the longer one, spells it out pretty well (Nic, you might want to re-read), but in a nutshell:
Most users would like (expect) to go into a project and be able to see all of the issues for that project (and JUST that project), presented in various useful ways: In a list. On a board. Or maybe on several boards, each having a different view/configuration.
Furthermore, many organizations have dozens or hundreds of nearly identical projects. And for consistency, each of those projects should be structured the same way. Same issue types, same fields, same workflows, same views, same boards. The issue types/fields/workflows are easy, we have schemes for those. But to make the boards consistent, we have to create and configure a separate board for every dang project! Which becomes extraordinarily cumbersome on so many different levels.
So... given this underlying problem statement, maybe the gurus can help identify the right way to solve for it. :-)
If you are using Jira Server you can install the FREE app called JQL Booster Pack throught Atlassian Marketplace and use the requested functionality.
After install this app, you should be able to create a query using
recentProjects() function, that will allow you to find issues in your recently viewed projects. You can also limit the number of projects retrieved by this function to get the most recent project.
You can use the following query to retrieve issues of your currentProject.
• Find issues in my current project:
You can find the complete information about this JQL function at its Function Reference page.
I started another thread - https://community.atlassian.com/t5/Jira-questions/Pass-a-URL-querystring-parameter-to-a-dashboard-gadget/qaq-p/1185212#U1187527 a few weeks ago.
I thought I was going mad, missing something obvious with dashboard reuse (or the lack of functionality) but I'm somewhat relieved to find I'm not alone!
Thank you to Jack Nolddor for the JQL Booster Pack recommendation. The recentIssues() method is the best workaround I've found so far!
Was this ever solved? Still experiencing the exact same thing. Dashboards need a project context drop-down. It could be made optional (locked) and it could inherit last-viewed project upon first load, allowing the user to select a different project in the drop-down (live-type search).
@Robert_Massaioli__Atlassian_ I think what the OP wants, or at least what I would like, is when you create a new project from an exist project using the "Share settings with an existing project"
When you navigate to that project, and you select "create a new board" (because for some reason this isn't copied as well... WHAT?!?!)
On the screen pictured, the hope would be, you would have a either:
"Board from existing project, We will swap that project filter for the project where this board will live"
"Board from an existing Saved Filter, we will insert the project where this board will live into the search context of currentProject in this example --> `project = currentProject() ORDER BY createdDate`"
I think that's the goal. Currently I have to select one of these last two option, then go edit the filter for this new board with the project I want.
If there's another solution to essential clone a board with only swapping the project context, I'd be very interested!!!!!!!!!!!
Phil Lanier response above I think makes the use case very clear!
I like the original posting better.
This modified request only gives me a copy of the queries I have today, modified to fit the new project.
But if we add a field and want to add that to the filter, I would have to update the query in every single project.
We are an organization with over 100 jira projects; just to provide some scope to the issue.
Other tools, including general purpose tools like Microsoft's SQL manager, application level databases like IBM's ClearQuest, and products like ApTest, all have a notion of the "current database or project"; all have included in their query the ability to reference the "current project (or database)". It is super useful in a saved filter, especially for large organizations.
This is the same reason "Current User" is super useful in a saved filter.
It's not hard to do, it's impossible. You can't tell what the current project is in my worked example because it does not exist. If you assume "all projects", that's fine, but useless, as that's what Jira is already assuming.
The closest you can get is "last project", and even that is not particularly useful. Imagine I view issue ABC-123, so you can say the last project I used was ABC. Now I go to a search and use a query that includes "and project in (DEF, GHI)" or "project not in (ABC)". What's the last project now?
Nic: You wrote "If you assume "all projects", that's fine, but useless, as that's what Jira is already assuming."
Well, in the scenario that you provided I would not be any worse off than current Jira behavior; however, if I am working in the context of a project, it would help.
That's not what seems to happen.
For instance, if I'm looking at the Open Issues for a project (the top left says "Projects / <project name>" , and below that "Open issues".
I then click the "star", and select my filter to run it, I now get results from all projects.
Are you saying that I should only see the issues from my current project which "pass" the filter criteria?
I could use this feature so that I could create a filter that is used by multiple projects - specifically for creating more reusable board filters. Personally, I want to find issues of type = "somecustomtype" + status = "open" + project=CurrentProject where CurrentProject is the project context my board is currently being viewed in. I'd be open to using the CurrentProjectFunction from the plugin below but it isn't supported in cloud.
>project that the board is being viewed in from the user's perspective.
Changing the wording "project context" to "the user's perspective" does not change the point. I have a board that shows "issue type = bug". What's the project context or user's perspective there?
Ok, sure so your project argument could be "*" or "ALL" or whatever the JQL equivalent is - sorry, not null. But it doesn't mean that there shouldn't be a solution for the problem I'm facing. I don't see why all of three use cases ("*", "NULL" and "ActiveProject") aren't valid project arguments.
Ok, let's keep it really simple.
You are asking for an answer to the question "what is the current project?"
The answer to that is "none, one, many or all". Your problem is too limited to be usefully "answered" by that. Your three "use-cases" are valid statements, but cannot be turned into useful requirements, and hence should be redefined in real terms or discarded.
To do that, you need to work out a way to answer the question: What is the "current project" when I am looking at a board whose filter says "project in (x, y, z)"
There is only ever one "current project" from a board user's perspective - the one selected in the JIRA user interface.
The idea is to make a board show only issues related to the currently selected project, even when the board query selects from multiple projects.
This would be useful when a board covers multiple projects but we're only interested in the selected one.
I think you've misunderstood the point. You can't answer the question "what is the current project" when you're on a board that includes more than one. There is no "currently selected project" when you're in a board, because the board might have more than one.
The only time "current project" can be answered for a board is when the filter has a project selection clause of "project = X". Which makes it redundant.
The point is to be able to create a single dashboard--for example, "Sprint Health"--with a bevvy of lovely widgets showing all manner of current-sprint-filtered data. And then to allow that dashboard to be used for any project.
Currently, you'd have to create the filters for each project, save the filters for each project, create a dashboard for each project, add the widgets for each dashboard while specifying the filters for that project.
A colossal waste of time and data! ...if only dashboards had a configurable project context...
As in my reply to Robert, it could be optional (overridden by the queries used in a widget, locked down at the dashboard level...maybe the dashboard has it's own project query which itself could be limited to a query string related to projects and therefore include a single named project, multiple projects based on project attributes, or a "chooser" allowing the user to pick a single project or maybe even multiple projects via Ctrl+Click for the widgets on the dashboard. You could add a separate configuration checkbox to ignore dashboard filter, just in case individual widgets had project filters, so you'd be compatible with current dashboards that are single-query-threaded.
Dashboards are not boards, and the question still stands, what project is the current one when your board filter is "project in X, Y, Z"
I'd agree that it would be nice to have a "project dashboard" though, I'd locate them in projects myself, then you wouldn't need a selection at all.
I shouldn't have said "Board", but rather "Dashboard". [corrected in original reply]
And when I said "current boards that are single-project-threaded," [I changed the wording to single-query-threaded in original reply] I intended you to understand that in some to-be, useful dashboard configuration setting that allows you to apply project(s) context to a dashboard (like the Rich Filters add-on allows, though much more convoluted), you might also want to have an "Ignore" function so that your existing dashboard widgets that already have project filters could still function as intended.
Overall, I think you missed the forest for the trees again. The purpose is to NOT have to create SEPARATE dashboards using SEPARATE filters for EVERY project.
No, I'm not missing the forest for the trees, I think it's you who is. You're ignoring the fact that we're looking at a forest and you want to report on the "current tree" without knowing which one it is.
I don't want to create separate dashboards either, I totally agree with you. My ideal case would be to have project owners be able to create dashboards in the projects, where you do know the "current project"
Nope. You missed it again. Let me try a more specific example:
I have 500 JIRA projects.
I have one concept of the perfect "Sprint Health" dashboard.
I do not want to build 500 Sprint Health dashboards.
I want to build one Sprint Health dashboard and let everyone use it.
When a user loads the dashboard, the system performs thusly:
I see that second paragraph. What I don't see is how creating a dashboard "in a project" solves my 500-projects-1-dashboard problem. Please elaborate.
Also, I'd like to amend my proposal to incorporate the idea of @Glenn_Burnside: Be able to select EITHER a project OR a Board in order to filter a dashboard.
...AND as a general issue query, add persistence of some kind to indicate current context, whether a project or a board. Maybe this option is a general user preference or, better-yet, en easy-access menu option to toggle between current board or current project (if current board is a composite of multiple projects, then gray-out the current project option).
I want a filter that says give me issues that match a certain criteria where the project = ActiveProject. From my perspective, ActiveProject is the project specified in the URL via "projectKey" parameter but there is no such property that I can find and filters don't seem to have a way to use the URL parameter as a criteria. I don't want to have to specify a specific value (or even a wildcard) for the projectKey in my filter. This will enable me to create reusable boards that support multiple projects.
That's correct - it's because the board defines the projectS it is for.
Again - what is the "current project" when your board filter is "project in (x, y, z)"
There are some add-ons which do "current project" in some places, but it's not based on the board, and can be misleading (because you could be in project w, then go to a board covering x, y and z), and can fail when you are using multiple tabs or browsers.
No. Because a board might include more than one project.
The move to have boards "inside" a project is understandable, but it's introducing even more confusion for users.
A board does NOT live within a project. A project has a collection of links to boards that might include the project.
Yes, and that statement is wrong.
It's horribly misleading. Boards do not belong to projects.
When a board has a filter like "Project in (X, Y, Z)", which ONE project does it belong to? Nope, can't answer that, because it's wrong. That board does not belong to any one project, it pulls in issues from all three.
Atlassian phrasing it this way has already increased the numbers of people horribly misunderstanding how boards work. It needs to be changed.
Both of these things are true though - Boards "belong" to projects in the sense that every board is assigned an owning project now. Boards can also "show" issues from across multiple project.
So, all the way back to the beginning of this, instead of describing this as "current project", think of it as, for a board, I just want to define a query like "project=currentBoardHostProject()" and have the issues on the board be filtered to those issues belonging to the project where the board is hosted. If I could create a filter that included syntax like that, then I could re-use the filter definition across a WHOLE LOT OF BOARDS AND PROJECTS.
Nope, they don't. There's a link derived from "this board includes a project", but that is not the same as "board belongs to project".
And, as I've said before, a board can include issues from many projects, and projects can be shown on many boards. So "project = currentBoard" could return many boards, and is useless on a board anyway, because you're already in the board.
There's a wonderful technology called "cookies" (not a confectionery treat) that allows you to create continuity as you use a site. For example, how did that shopping site know that you currently have three items in your shopping cart? A simple website might actually store those three items in a cookie in your browser cache. As you move around the site, even though you haven't logged in, the site can recall your cart items.
The currentProject is the project I was just looking at, and the currentBoard is the board I was just looking at. If the board is a composite of more than one project, then currentProject would probably be an invalid parameter.
This is a basic web concept.
@Nic_Brough__Adaptavist_, when I'm choosing which board I want to look at, the menu groups them in 2 sections:
So clearly, some boards belong to projects. For those that don't, how a "currentBoard()" function would behave probably warrants further discussion, but I think the meaning is pretty clear for boards that live inside a project.
Bump? Lol. I too would like to see this functionality within the jira cloud but understand (I think) what @Nic_Brough__Adaptavist_ is getting at. During a board's initial creation it was built to be flexible enough to PREselect project(s) to filter the boards contents by. If JIRA introduced a currentProject parameter in JQL it would bug the system out. I can understand his point that this could introduce a significant amount of complexity. I think a reasonable feature request would be maybe focused around a step in the right direction which would be a new option in board settings.
If we had an option to enable "Filter issues within the current project" JIRA could at least build testing against having this enabled and also a user unknowingly trying to select multiple projects. I hope this makes some sense. Thoughts?
Focussing on boards specifically (eg. Sprint or Kanban)...
It doesn't matter how Jira internally actually categorises and manages boards (it's a given that they're being obtuse about it, and it's confusing)... what is pretty darn clear to anyone not being an obstructive pedant is the repeatedly requested desire to have a board scheme (let's use generalised terminology that's commonly understood, and a Jira concept too).
At that point, it would be great if Jira would be kind enough to abstract that part of the query away from us (the current project from whose menu the board was accessed), and use some kind of interface to assign to Project(s) of your choice.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events