nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Do not reuse project name: filters would still refer to the old project

Inna S

Hi,

consider this:

What happened?

We had a project named 'DevOps'. We've decided to put it aside (wrong type and more reasons) and create a new DevOps project.

Step 1: Renamed the existing project to OldDevOps and changed its key to OLDDEVOPS.

Step 2. Created a new project 'DevOps'.
No problems so far.

Step 3. Tried to set the project key to DevOps and failed because the key can't be reused.
Decided on a slightly different key and set it ok.

At this point we had Jira rename all the issued in the old project to use the new key.

Step 4. Create a basic filter for the new project to be used on the default project board.

Here is the filter:

((project = DevOps and type in (Story, Bug, "RnD Field Bug", Epic)) and statusCategory != Done) ORDER BY Rank ASC

As can be seen, it refers to the new project name 'DevOps'.

Yet, when we run the query, issues from the old project come up and issues from the new project are omitted:

My guess is that this is thanks to the same 'feature' that let's you find an issue that was moved to a different project by its old name. Still, this is both confusing and irritating.

In a nutshell: do not reuse project name.

Comments

Jack Brickey

Indeed reusing a project name is fraught with possible errors. You must clear out all references to the original ad you have shown. Finding all references can be quite the challenge.

Inna S

It was a silent project with no much of activity. And the only reference I could think of was the project name and key in a filter. But they did not warn anywhere that rename would result in this catastrophic output: effectively you may have a project but you will not be able to search for issues that reside in it. That makes the whole idea void.

Don Masten_jzyv5k

If tickets in OLDDEVOPS aren't needed. You could delete it and remove it from the trash.

Jack Brickey

Yes but before trashing the project you should delete all filters, dashboards, links to Confluence pages, etc.

Jack Brickey

Hi @Inna S , you can always reach out to Atlassian support for help with an issue like this. I know they would be interested in the process you used here.

Inna S

TBH, I'm tired of them. They are trying to use my company time for debugging their product. One year of experience and tens of cases brought me to realization that it is 'take it or leave it' situation and we've got find our ways around with the generous help of this community and almighty Google.

Inna S

We have disabled 'delete' operation because Jira does not have the concept of recycle bin and this was the suggested best practice.

As an admin, I can temporarily add myself the permission to delete, but why care?

Beyond, this is just yet another bug in Jira, this time it is a design bug and not a code problem. Last time I tried to report a bug, they refused, went out of their way to convince me the behavior was 'as designed' and ok.

At this point I'm just finding the shortest and safest path and close at that.

Btw, @Jack Brickey , removing all the filters, dashboards etc. from the old project would not help in this case: the problem exhibited itself in the new project, with new issues omitted.

Jack Brickey

FWIW, for future readers here... here is the delete and restore feature. The first image illustrates how to move a project to the trash bin. The second image illustrate how to restore (good for 60d). Admins will be notified of the delete and warning of permanent deletion upcoming.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud