This may be fixed by an issue @atarisafari is working on.

We've been able to reproduce this issue inconsistently, with it showing up in only a few courses. Any details on the course that is causing this would be helpful.

It is happening in both of my test courses. One of them is small and I use it to test specific errors, while the other is large and I use it to test UDOIT as a whole. The two of them are very different, so I can't really point to anything they have in common.

Was there any more progress on this? I think I'm hitting something similar and navigation isn't working is many of the courses we have.

I can pretty consistently reproduce it by changing a filter to something like "Resolved Issues" which shows less issues. Then going selecting an Issue and going Next will basically not go anywhere.

This seems to be more of a problem in courses where over 100 issues were found by UDOIT.

Also often in those courses when clicking rows on the UFIXIT page will go to issues that weren't even the ones clicked on.

This is still an issue on 3.3.1 for us. A course that has the problem has over 100 issues. Before fixing any issues there are no problems with navigation. As soon as a few issues are fixed the navigation. You can see this after issue 96 here it jumps back to 23.

This was on a site with
112 Errors
51 Suggestions
2 Issues Fixed
0 Manually Resolved
0 Files Reviewed

So I've debugged this a little more.

It looks like the value of this.props.filteredRows[newIndex] in UfixitModal->handleIssueChange doesn't match up with props.report.issues[stateActiveIssue.id] in in ContentPage->getDerivedStateFromProps.

So getDerivedStateFromProps is resetting the active issue when the status doesn't match, even though they aren't the same issue. The stateActiveIssue.id isn't actually the index for the value in issues.

I feel like it might actually has to search through the props.report.issue for the id rather than just trying it access it directly with the index?

I think what @jonespm described here is correct. The issue ID is being treated like an index. This problem occurs when the index of the issue is small enough that it also could be an issue ID (from the database table). This makes it hard to reproduce in many cases, since it has to be a very early course or a brand new database.

Finding the issue by ID here would work, but it may also just make sense to update the state using App.handleIssueSave and not use getDerivedStateFromProps. Something like this: https://github.com/ucfopen/UDOIT/compare/main...ssciolla:UDOIT:issue-644-keep-fe-state?expand=1

I'll plan to open a PR for discussion next week. There's also another issue/fix involved with that diff that I need to document.