We have somehow experienced in sevaral issues that the latest version of the issue dissapeared and on about 4 or 5 issues in a project with sevaral hundred issues we noticed that the latest history entry was the 12th of Jan 2022.
We could pinpoint the date of the occurance that apparently someone had set back the issues we checked to a content before some important clarification had happened with our stakeholders.
This has now happenend about the fourth time since last year on different issues.
So this looks like a project adon has manipulated somehow some of the content and the respective history entries on purpose or by mistake.
We checked with the support guys in our company. They say we are the only project complaining about this and that they never ever restored the database from a backup.
WHhich could have explained some mismatch and missing history entries. But then everyone in the company would have experienced the same.
And for a defect in a standard software this is far too specific a problem to be a likely cause.
So what exactly is the capabilities of a project admin?
Is it possible that this is sabotage or just a mistake of a admin user?
But then why th eproblem is restricted to only certain issues and not all of them in the one project?
To us this looks quite strange?
Many thanks.
There are a few ways you could do this, but none of them could be done by project administrators.
You could write code that edits or deletes issue history content, but only your administrators could install or run it. The only other method is directly editing the database, for which you would need to go to someone with access to it.
welll I suspect sabotage and as iI was a long time ago working as an application support and direct deletion from the database by someone who knows the data model well enough was my first thought.
Though the very first thought was somehow a restore of an older DB Backup, but we could rule that out.
I have spoken to my team as well after confidung in ine colleage ony before. And sevaral other team members remembered exactly the same state of the sample issues we checked as my colleague and I. So we were not imagining things.
And as some of you said, if a project admin has no such permissions deliberate deletion from all relevant database tables is the only possible other expalanation.
As for a software defect of Atlassian ist is too specific only on some issues of 1 out of many projects and not systematic enough.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The project admin administers the project. By default they can't work with issues unless the permission scheme/workflow allows it. Check this https://support.atlassian.com/jira-work-management/docs/get-started-as-a-project-administrator/
The first thing to look at is ask the Jira administrator to check the project permission scheme for what the admin can do and the project roles as to what the project admin can do.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.