Issue Summary

Conditions: In Epic Backlog with a Portfolio set in Tier1 configuration

When an Epic changes rank position, we see that loaded "Epics that do not change rank position" also get an audit log entry stating that the Epic was moved from the position they are currently in to the exact same position, even though they were not moved.

eg Portfolio[8] Rank: Epic 1201 was moved from 1 to 1

Steps to Reproduce

Step	Time	Image	Description	OK
1	0:40		Swap Epics in position 4 and 5
2	1:41		Epic in new position 4 gets an audit log entry correctly reflecting the rank move {}eg Portfolio[8] Rank: Epic 1201 was moved from 5 ** to 4{}
3	2:05		Items before item in position 4 get an unnecessary audit log entry eg Portfolio[8] Rank: Epic 1201 was moved from 1 to 1
4	3:21		Epic in new position 5 gets an audit log entry correctly reflecting the rank move eg Portfolio[8] Rank: Epic 1201 was moved from 4 to 5
5	3:40		Items after item in position 5 get an unnecessary audit log entry eg Portfolio[8] Rank: Epic 708 was moved from 6 to 6
6	3:53		Note only 100 items loaded initially.
7	4:07		Similar to step 5, there is an unnecessary Audit Log entry for item in position 100 says “Portfolio[8] Rank: Epic 350 was moved from 100 to 100
8	4:23		New items being loaded in backlog, eg item in position 101, do not get the audit log entry

Expected Results

No audit log entry in items in position 1-3 and 6-100 as these work items did not change their backlog rank.

Actual Results

Every work item in position 1-3 and 6-100 has an audit log entry:

Portfolio[x] Rank: Epic abc was moved from y to y 

Where

x represents the Portfolio ID

ABC represents the Epic ID

y represents the backlog rank position

Impact

Items 1,2,3 and 6-100 did not change their rank. Therefore nothing changed. Therefore no entry should be entered into the audit log.

No change was made to the rank, but an entry was logged into the Audit Log for each of the items in position 1-3, 6-100.
These unnecessary entries cause the Audit Log to be over-filled, the database to be written to, the tables to get too much data. This has impact on the database itself.

Other audit logs have logic to prevent duplicate logs entry where no changes were processed, and the backlog logic should implement this safeguard too.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available