After removing the issue it still exists in database

[mahsa ah]

Hello Atlassian Community,

After I remove the issue from Jira UI, it still exists in the oracle database, while when you search it in UI you cannot see that issue.

Why does this happen?

How can I remove it completely from the database?

[Tom Lister]

Hi @mahsa ah 

What do you mean by remove from UI?

if you delete and issue it will be permanently removed as many of my users have painfully discovered.

if you archive an issue it will not appear in searches. But it is still in the database and can be accessed directly.

---

[Fabio Racobaldo _Herzum_]

Hi @mahsa ah ,

welcome to the Atlassian community!

I agree with @Tom Lister .Please, could you share what operation you performed on the UI in order to delete issue?

Fabio

[Pou Yang Gan]

Hi All, we have the same issue.

We ingested all the Jira data via Stitch into BQ and use looker reports to provide more insightful reporting.

This is how it currently works: Any event on Jira, whether that be tickets, worklogs etc, is exported daily via Stitch. So, even if I delete any tickets upstream in Jira, this does not retro-actively delete the previously exported records of that data. Some of these issues have been exported multiple times over the course since they are created, so even if I delete them in Jira, they still persists in BQ.

Any ideas on how to resolve this?

[Nic Brough -Adaptavist-]

You will need to configure stitch such that it deletes or updates your BQ system when issues are updated or deleted in Jira.

[Grace Dehergne]

Hi @Tom Lister ,  I have the same problem.  We are building customized metrics dashboards (something that JIRA or off the shelf applications can't provide)  using Tableau and Snowflake (with data coming from Jira).  For that matter our IT  team populates Snowflake with Jira Tables.  However I encounter the same thing.  The deleted issues still exist in the database whereas in the Jira UI, you cannot see it anymore.  It makes our metrics report unreliable.  How can we know (field value or other indication) that the issue has been deleted?

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

As I pointed out earlier, the worst possible thing you can do for reporting on Jira is read the database.  You should stop doing that., for exactly the reasons you are seeing here.

But, how exactly are your tools that are reading the database extracting the data?  Are you entirely sure that an issue that has been deleted is not in the Jira database?  And how are you doing the deleting in the UI?

[Tom Lister]

Hi @mahsa ah 

what do you mean by ‘removed from the dashboard’? It doesn’t sound like an action likely to delete the issue. Do you mean dashboard or a scrum/kanban board?

re EasyBI, did you get an actual error or do you see the fact that the issue is still reported as an error.

[mahsa ah]

Thanks for your attention

I will describe completely what happened.

After the issue was removed from the dashboard, I faced an error during getting a report from eazybi that the issue is still available.

So I checked from the database, and I realized that there was another issue exactly with the same issue number and same project name in the database and both of them did not appear in the dashboard search.

for example mentioned issue was Test-2020, while there was another Test-2020 with different issue types and descriptions in the database, which means now we have two Jira issues with the same id and project name in jiraissue table.

my question is that how it is possible to have the same issue id and project at the same time?

why by removing it in the dashboard, it still persists in the database?

[Nic Brough -Adaptavist-]

You can't have an issue with the same id in the database, not unless you are using an unsupported database that you shouldn't be.

Again, the best thing you can do is stop looking at the database.  It will not work the way you are expecting.

[Nic Brough -Adaptavist-]

Why are you looking at the database?  It's the worst possible way to report on Jira information, and you've almost certainly run into one of the many reasons why here.  You've "deleted" the issue in the UI, so everything will be working there (including the REST API), so why are you even looking in the database?