How can I get the current project to use in a JQL query?

[Frank_Spafford]

I would like to do something like:

project = currentProject() ORDER BY createdDate

Is that possible, or can it be added?

[Nic Brough -Adaptavist- · Accepted solution]

There is no "current project" when you're in a search, they execute outside project contexts.

[David Babuder]

That's the problem we are trying to solve - we want to scope the results to a project, and we are looking for a way to do that.

Thoughts on how we can accomplish that?

[Igor Silva]

7 years of discussion so we get the accepted answer as "it's not possible", with no suggestion of how to approach the (very popular) problem.

This is so bad.

I'll re-send David message (above) for the future generations that'll arrive here:

That's the problem we are trying to solve - we want to scope the results to a project, and we are looking for a way to do that.

Thoughts on how we can accomplish that?

[Nic Brough -Adaptavist-]

I think the problem here is that you do not understand what you think you are asking for.

You can "scope the results to a project", that's always been available - you use "project = xyz" in a search.

The problem is that you don't know how to name XYZ dynamically.

It's easy to code a function that would let you do "project = currentProject()" for a search.  It's about 12 lines of code.

But for that to work, you need a definition of "current project". 

When your user is looking at a search screen, what's the current project?  When they are looking at a board that has a filter like "Project in (x, y, z) order by rank asc", what is the current project?  When they're on a dashboard which has many gadget filters looking across many projects, what is the current project?

Can you tell me what the current project is everywhere in Jira? (Apart from the obvious ones, where you don't actually need a current project function - the project header, or a single issue view, etc)

[Omar Mussa]

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.

[Phil Lanier]

Thank you, Omar!

For those who aren't clear on the intent behind the question, Omar does a great job of explaining the underlying challenge that needs to be solved for - starting with "My typical user workflow..."

[Henry Auffahrt]

We are facing right now the same problem as @Omar Mussa in our projects. Anyone finds a solution for that?

[Vicky Blease]

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!

[Jack Nolddor _Sweet Bananas_]

Hi @Frank_Spafford
 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:

project IN recentProjects(1)

You can find the complete information about this JQL function at its Function Reference page.

Kind regards.

[Frank_Spafford]

I would expect the current project to be the one that is displayed in the drop down that appears when  you click "Projects" on the JIRA menu bar.

[Rickard Abraham]

Just found this in the docs, I'm perplexed that none of these threads have mentioned it so far, is this new? Seems to work for me

project = "{{ project.name }}" ORDER BY createdDate

Docs 

[Nic Brough -Adaptavist-]

That only works when the automation is working within the context of a specific project.  That's fine, but the question here boils down to "what is the current project when I am working outside any context of project?",  which can't be answered.

[Michael Gillman]

In the new Jira experience, a Board always lives within a Project.

Wouldn't it make sense now to allow a Board filter that always queries the Project that the Board lives within? This would eliminate a great duplication of Filters...

[Nic Brough -Adaptavist-]

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.

[Michael Gillman]

Nic,

That seems at odds with what is stated here:

We redesigned the Jira experience to make the relationship between boards and projects much clearer. Now, boards belong to projects, so you can better manage multiple work streams in Jira Software.

[Nic Brough -Adaptavist-]

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.

[Glenn Burnside]

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. 

[Nic Brough -Adaptavist-]

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.

[James Hendrix]

@Glenn BurnsideI like it! I think we should have both:

• project = currentProject()
• project = currentBoard()

...and then build the dashboard selector to change projects OR boards.

[Nic Brough -Adaptavist-]

But they can't work because you don't know what the "current project" or "current board" are unless you're inside them.  Yet again, please tell me what the "current project" is when I am looking at a filter for "project in (x, y, z)"

[James Hendrix]

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-]

There's a wonderful technology called "reading the previous discussion" too.

[James Hendrix]

I'm not sure what you're implying. I've read every post here and lots of other places asking for basically the same thing. Clearly, there is a need as described here that JIRA doesn't fulfill.

[Alex Villarreal]

@Nic Brough -Adaptavist-, when I'm choosing which board I want to look at, the menu groups them in 2 sections:

• "Boards in <project>" (where project is the project that I currently have selected, and which I would understand as "the current project"), that contains boards that as far as I understand, belong to the project that I currently have selected.
• "Other boards", where there are some items that seem to live completely outside projects (for those, I agree that "current project" isn't well defined), and some that clearly state "<Board name> in <Project>". When I click on the latter, JIRA switches to that board and I see that the project that is now selected is the one where that board lives.

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.

[Nic Brough -Adaptavist-]

No, you've not understood what I wrote before.  Boards do not belong to projects, there is just some code that shows you when there is a relationship.

[Andrew Barrows]

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?

[Nic Brough -Adaptavist-]

I think you've got it.

I'm still waiting for someone here to define what the "current project" is when the board, dashboard, filter or report is set to look at "project in (x, y, z)".  Until that's answered, we can't get far with this.

[Tobias Twardon]

Hi Frank,

you can use the following Plugin to achieve this functionality:
https://marketplace.atlassian.com/plugins/com.olegburmistrov.jira.CurrentProjectFunction

It's working like a charm for us.

Best regards,

 Tobias

[Omar Mussa]

I wish this plugin were available for JIRA Cloud.

[John Gill]

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! 

[Igor Silva]

6 years after, and no solution. This is crazy.

[Nic Brough -Adaptavist-]

@Igor Silva - there's no solution because the problem cannot be "solved". 

When you do not know what project you are in, you can not answer the question, "what project are you in?"

The best you can do is ask "what project did I last visit?".  But that is not a lot of use.  Imagine I go to "search for issues" and ask "show me issues in project XYZ".  I was working in project "ABC", so where am I now?

There is not really a problem here, other than people not really knowing what they are doing (which I blame more on admins, organisations, and tech writers, than I do on individuals - the "current project" should be "where I need to be" without us having to think)

[Igor Silva]

The way filters are designed is bad and doesn't fit pretty common use cases. That's my critic.

I've just started using Jira for a product company. We're managing 6 products with different managers, architects, designers and developers, and we want all of them to look the same.

During the discovery phase I was told by sales reps (and by Atlassian marketing content) that "company-managed projects" would fit that.

The reality is that I had to clone every damn thing. I have 1 product board on each project, which I had to clone. I have 1 filter for each of those boards, which I had to clone. And that goes one.

Instead of being able to have 1 global config to fit all projects (much like I have for screen and workflows schemes), I have to duplicate them, and that just doesn't scale. Imagine when I reach 20 projects.

Specially during the first months, where we're still learning the possibilities with Jira, I'm constantly improving boards for my teams, and I have to replicate 6 times every minor thing I do. Besides the stress it generates on "having to guarantee everything is equal".

I feel personally offended by how this is disclosed by Atlassian and how those features where designed, because the demand I'm describing feels SO BASIC.

Even for workflows (which can be shared), it's so odd. I have to copy it, update it, then attach it to the shared scheme, go to a associate process, ... It takes like 8 steps to add a transition screen.

[Nic Brough -Adaptavist-]

>Instead of being able to have 1 global config to fit all projects (much like I have for screen and workflows schemes), I have to duplicate them,

Ah, you've not seen the option to share settings then. 

When you create a company-managed project, you have the option to "share settings with an existing project".  If you select that, it will ask you for the project to share with, and then set your new project to use all the same schemes that the existing project  does.

You can have a standard set of configuration schemes (one workflow scheme, one notification scheme, one security scheme, etc) that you use for all your standard projects.

[Igor Silva]

I did, and I literally mentioned that in my previous message. My argument is about boards and filters, which is the topic/question we're at.

[Nic Brough -Adaptavist-]

Um, so why did you change the subject on to project configuration that you seemed to have missed?  (I'm not looking for a direct response to that, I'm just curious as to how it fits into your original question)

I don't understand what your exact point is here.  When you create a project, you automatically get a board with it, in most cases (Most notable exemption is Service Desk projects, as they're intended to be run off the queues, not boards - agents should always be fixing the stuff closest to breaching the SLA, not planning with boards and backlogs.  But you can still create boards that include them). 

Sometimes it's a project board, which gives you a simple board based on "project = XYZ", which means "current project" (the actual topic/question we are at) is not needed.

Other times, it's a software board, which defaults to "project = XYZ", but can be changed to a different filter where "current project" cannot be defined.

So I think I need to ask a favour of you - can you re-explain your points?  How would you want to implement a "solution" to what you think the problem is?  

[Igor Silva]

Premise: companies will hardly be satisfied with Jira defaults. Absolute most people are customizing the experience.

Objective: design the customization once and apply (forcefully or not) through all my projects/products.

Current Jira does not fulfill that goal, and as a new customer, I'm deeply unhappy with my year-long decision.

To be more specific, boards and filters are a big part of our workflow, and there is no way to properly re-use them. Other schemas can be shared (such as issue types and workflows) but even that is way harder and time-consuming than it should.

I'll make it work for us, but I'm definitely never recommending Jira to anyone ever again.

That's my feedback for Atlassian.

[Nic Brough -Adaptavist-]

Could you please re-read the previous conversations?   I've asked for you to explain what the problem is, and how you might solve it, but got nothing back that suggests you have looked at those questions.

I've repeatedly asked for a definition of "current project" when people are outside a clear project context, and what you think "current project" might be when you're working in places that include many projects. 

You have not considered either of those questions, so I'm completely stuck. 

I don't just work with Atlassian stuff, but I can tell you that if you can't be clear with your definitions, there's no other software that will work for you.  You need to be clear about what you're looking for in all systems, not just Jira.

[Igor Silva]

I honestly don't know how to be more clear about my issue and situation.

Finding solutions is Atlassian's job. I'm just giving customer feedback.

I can give you - at least - 100 options on how to define "current project" (independently of software limits from current design), and most of them would solve my case. There are even a few plugins providing that functionality within the current design.

E.g. use the project key at my current path (browser URL). If none found, display an error.

My main job is delivering SaaS software much like Atlassian, and I'd consider this a major issue as - from what I GUESS (as I don't have data) - affects most of the app's users.

Last but no least, as you demonstrated no interest in helping me (us) find a solution or collect qualified feedback, focusing all your energy to prove I'm wrong, I won't watch or reply to this thread anymore.

Thanks anyway,
Unhappy Atlassian Customer

[Nic Brough -Adaptavist-]

I am sorry you are not getting what you want to hear from our answers and explanations, but we can't help you until you start to answer the questions or explore what you're hearing.

You say there are a 100 options for defining "current project", but do not give us any.

I would love to help you, but I can't until you define the problem and what you think the solution may be.

I keep having to go back to the very simple question about a very clear situation, which you have continuously ignored.  If you could try to answer it, we may be able to make progress.  Given you run a search for "project in (X, Y, Z)", what is the "current project"?

[Igor Silva]

I LITERALLY GAVE ONE, c'mon man you're not even reading.

[Nic Brough -Adaptavist-]

If you mean "use the project key at my current path", then yes, I stated that ages ago (and it also applies when you're looking at a single issue, as also stated).  

You know the current project when you're looking at the project or a single issue.  That's never been the problem.  The problem is "what is the current project when you are not working in a project context"?  Such as a search, board, report, filter, dashboard, or or or, that does not have a project context, and/or includes more than one project?

[Nic Brough -Adaptavist-]

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.

[Omar Mussa]

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.

[Nic Brough -Adaptavist-]

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

[Gabriel Bauman]

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.

[Nic Brough -Adaptavist-]

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.

[James Hendrix]

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.

[Nic Brough -Adaptavist-]

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.

[James Hendrix]

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.

[Nic Brough -Adaptavist-]

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"

[James Hendrix]

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:

1. Use the user's last-accessed project to filter the set of all project data for the widgets on the dashboard.
2. Allow a user to specify a different project (live search) or multiple projects (Ctrl+select from list). Refresh the dashboard with the new set of project data.
3. Allow a dashboard configuration to Ignore/Hide this "project context" at the dashboard level and rely solely on the widget configurations (legacy mode).

[Nic Brough -Adaptavist-]

No, you've not read the second paragraph of my last comment, where I've agreed with you and suggested a more simple way to do what you are looking for, while keeping the existing dashboard system simple and intuitive.

[James Hendrix]

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

[Omar Mussa]

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.

[Nic Brough -Adaptavist-]

That's wrong. My project context is absolutely not "null", as that's useless.  It's "all projects".

[Omar Mussa]

Also, I'm not saying that all board queries would need to have an active project context.  I just would like to be able to have one for my case, which is in creating a project/context specific query for making a reusable board.

[Omar Mussa]

In your case it would be "NULL" which is a valid answer to me.  In my case (shown here) it would be "SWPD":

ProjectContext.png

[Nic Brough -Adaptavist-]

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

[Nic Brough -Adaptavist-]

>CurrentProject is the project context my board is currently being viewed in

Boards are not viewed in a project context.  Or rather, the "project context" is "one, many or all projects".

[David Babuder]

Lists of issues can be filtered by "Current User".

Why not allow them to be filtered by "Current project"?

[Nic Brough -Adaptavist-]

Because there isn't one at the place you're looking at.

[Omar Mussa]

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.

[David Babuder]

Keep working on this Omar. You are spot-on!!

[Robert Massaioli _Atlassian_]

I understand that is what you want to do but it is not what you want to ultimately accomplish. Why do you want to do that? What key information would that give you that you seek?

[Frank_Spafford]

Robert, I would like to view issues in my "currently selected view project" and order the issues by created date, using a saved filter.

[Robert Massaioli _Atlassian_]

Frank, what are you trying to accomplish with your JQL query? Maybe there is another way to accomplish what you want if we knew what information you were ultimately trying to have at your disposal.

[Nic Brough -Adaptavist-]

That would be a nightmare - you'd have a filter that could apparently randomly change every time you went back to it.  I don't think that's a good idea (I'd certainly hate having to explain it to all the users)

[David Babuder]

What would change about the filter?

It would work as consistently as "Current User" does.

[Frank_Spafford]

I would like to have the "last viewed project" available to JQL.

That would allow me to create a single filter that could be used for any project, and would apply to the last viewed project. (I would not have to create the filter for each project of interest.)

[Nic Brough -Adaptavist-]

That's the "last viewed", as Robert says.  A function for that is not a lot of use in a query, and useless in a saved filter.

[David Babuder]

Nic:
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.

[Nic Brough -Adaptavist-]

Ok, so try this:

• Log in.
• Go to "issue search"
• Tell me what the "current project" is at this point?

[David Babuder]

That's hard for me to do, because I always log into a project so that I can see what I'm supposed to focus on.

However, imagining the state that you have suggested then the current project would be "*" (i.e. all projects).

[Nic Brough -Adaptavist-]

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? 

[David Babuder]

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. 

[Nic Brough -Adaptavist-]

When you're working in a place where you have a project context, you don't need a "current project" function because you already have it.

[David Babuder]

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?

[Nic Brough -Adaptavist-]

As soon as you run a filter like that, you're outside the project context, so it's showing "all"

[jelmerjellema]

This is an old one, but it's driving me mad as a new Jira user.

First I tried "next gen", until I found out I have to recreate workflows, statusses and what not for every project.

So I switched to Classic. I can use a workflow in numerous projects, but I have to recreate to Kanbanboard for every project. I can copy the board, go to the filter, copy the filter, change the filter, go back to the board, change the selected filter. It's easier to recreate the board from scratch.

So, as to the existential question "What IS the current project", well: it's the one that shows in the left sidebar on top. I would like to have a filter function for 'the project that shows in the left sidebar on top'. Filter may return empty if there is no such project, that's just fine.

[Nic Brough -Adaptavist-]

No, it is not.  That is "the last project Jira can identify you as using".  There is no "current project" when you're outside the context of a project, as you can be in boards, searches and reports.

[Robert Massaioli _Atlassian_]

Out of interest, which project would you expect the "current project" to be? JIRA has an internal "last viewed project" concept but it is not surfaced to JQL queries because that would make them non-deterministic.

[James Hendrix]

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

[John Gill]

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

or

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

[David Babuder]

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.