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; } } }

Hide a specific transition from history tab

Avdhesh Chauhan

In jIRA 4.3.4 is there a possibility to hide a specific transtion or action from the history tab- we run some jelly service every 4 hours and every time it runs the particular tanstion is seen in hte history tab - if an issue is open for 15 days then ther is close to 60 jelly transntions and 60 entires in the history tab also

is there a simple way to hide tis particular transtion from the history tab

Accepted answers

Nic Brough -Adaptavist-

No. The history is there to show you the changes made to the issues. The Jelly script changes the issue so it's a nonesense to hide it.

You would need to amend the core code of the workflow functionality to prevent it writing the history, and then you'll end up with an inconsistent history and users saying "this issue is in the wrong state, it's been changed and we don't know how"

I would take a much closer look at how you do this escalation - instead of doing the same transition over and over, try commenting instead - they will still bug your users but won't go into the history. Or, shove it into an "escalated" status so people know what a higher priority is, and then subscribe people to a filter that lists "all escalated because you aren't working fast enough"

All comments

Nic Brough -Adaptavist-

No. The history is there to show you the changes made to the issues. The Jelly script changes the issue so it's a nonesense to hide it.

Renjith Pillai

And to add what Nic said, JIRA will start behaving very badly if the number of history entries for an issue starts growing up. It will lead to severe performance issues.

Nic Brough -Adaptavist-

I've run into problems with around 300-ish change groups (by change group, I mean each entry of "person X changed this issue" - it didn't seem to matter if the changes were one field, or several).

If you do amend your processes to avoid writing the history lots, then some ideas:

1. Think carefully about comments - I've run into "unable to render issue" when there's over a couple of thousand on a single issue.

2. Once you've changed, you can think about clearing the old history out - as long as you stop Jira, get a good backup and re-index when you've finished, you can cleanse the history of issues by removing rows from changegroup and changeitem.

Avdhesh Chauhan

Thanks Nic for the suggestion we will try a workarround for our scenario

Renjith - any idea like after how many history entries the performance issue will slow down - bcz we have already quite some issues with more than 100 history rows

Walt Fles1

It would be nice if you could squash the change items into less, smaller chunks, sort of like how you squash commits in git.

Nic Brough -Adaptavist-

I'm not sure how you'd do that - squashing commits in git does make sense, but if you did it in Jira, you'd be effectively destroying information that is the whole point of having a history.