Sometime after 12.0, the code in AssignmentAction.setScoringAgentProperties() was updated which introduced a regression where the instructor would not see the scoring component icons in the grade submission UI (provided there was a scoring component attached to the assignment/gradebook item).
The following lambda is what introduced the problem:
In the student context (where a student is looking at their own submission), the above code's .filter() routine would successfully find the studentt's own submission. However, in the instructor context (where the instructor is viewing the grading UI for a particular student's submission), the filter would not find any submission matching the current user because the current user is the instructor, not a student. In this scenario, the code then falls back to the orElseGet() routine. This then has it's own filter, which in my testing never returns a submission. This results in the orElse stipulation returning a null AssignmentSubmissionSubmitter object.
After the lambda is performed, there is a condition that must be passed before any further processing is performed:
Where all the code which needs to be run in order to generate the scoring component icons/links is inside the conditional. If the submitter object is null (which is always the case in the instructor context), the conditional never passes and the icons/links are never rendered.
The bug was introduced some time after 12.0 (I haven't tracked down exactly what JIRA), but prior to the change the code was much different:
You can see that it really didn't care what/who's submission it was dealing with; it just grabbed the first submission object from the array.
The linked PR proposes the following changes:
In this way, we move the group check to the very beginning for a better short circuit mechanism, and we revert back to the old logic of just grabbing any submission from the list for the instructor context, while retaining the new logic to select only the current user's (student's) submission in the student contexts.