Display of issue history shows wrong account

Created on 31 July 2023, over 1 year ago

Problem/Motivation

The Drupal issue tracker history display sometimes shows changes/activity for an issue as having been performed by the wrong account.

Steps to reproduce

  1. Navigate to #42 for issue 2971390 ๐Ÿ› Make exposure of translation meta fields conditional Needs work
  2. Click on View changes
  3. Note that the wrong account is displayed for the issue summary rewrite

Proposed resolution

Don't collapse multiple actions performed for an issue by different accounts into the same history display.

User interface changes

The correct account is displayed for each action performed for a tracker issue.

Screenshots


๐Ÿ› Bug report
Status

Closed: won't fix

Component

Other

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States bkline Virginia

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @bkline
  • Status changed to Closed: works as designed over 1 year ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

    This is a side effect of the bulk updates for the following comment changing the Version and how Drupal keeps track of revisions. Notice https://www.drupal.org/node/2971390/revisions/view/11380013/11380027 โ†’ also includes that version change. Those bulk updates are run via a drush script which is operating as the anonymous Drupal user. That bulk update probably should have used $issue_node->revision = TRUE;

    With #3265096: Move issues from www.drupal.org to git.drupalcode.org โ†’ upcoming, I donโ€™t think GitLab provides a way to view issue summary revisions, so we won't have to worry about migrating this type of non-ideal data. And correcting it in the meantime would be more trouble than its worth, since weโ€™d have to back-fill more revisions.

  • Status changed to Closed: won't fix over 1 year ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bkline Virginia

    I get the argument that it's not worth fixing, but unless someone can point to documentation which explicitly states that the tracker system was intentionally designed to behave this way, I think "Closed (won't fix)" is a more appropriate status for this issue.

Production build 0.71.5 2024