In T424939#11916371, @Samwalton9-WMF wrote:

@Kgraessle I glanced at your patch and realised I didn't include specific enough criteria here, sorry! We'll need to reword the message since the text contains the wrong Special page text. The message should read:

If log-only mode is enabled, Automoderator will not revert any edits, and instead will log the decisions it would make.

Where 'log the decisions' links to Special:Log?type=automoderator (FYI I noticed your patch links to Special:Log/AutoModerator?type=automoderator)

I validated that we're handling the timeout error.

I validated in logstash that this error is no longer happening.

One more minor thing I have noticed on Patch Demo, particularly on the desktop view it appears there's additional spacing between the first card and the heading compared to Active Discussions:

We should make sure to finish T424665: Update the element_friendly_name in PersonalDashboard Review Changes module in order to differentiate diff link clicks before removing the feature flag.

A few things I noticed upon testing the patch demo

In T424023#11844325, @jsn.sherman wrote:

regarding the existing module groups in SpecialPersonalDashboard

private function getModuleGroups(): array {
		// TODO: Remove this feature flag for active discussions hard launch
		$showActiveDiscussions = $this->getContext()->getRequest()
			->getText( 'personaldashboard_activediscussions_show' );
		$moduleGrouping = [
			'main' => [
				'primary' => [ 'ext.personalDashboard.banner', 'ext.personalDashboard.riskyArticleEdits' ],
			],
			'sidebar' => [
				'primary' => [ 'ext.personalDashboard.impact' ],
				'secondary' => [ 'ext.personalDashboard.policiesGuidelines' ],
			]
		];
		if ( $showActiveDiscussions === 'true' ) {
			$moduleGrouping['main']['primary'][] = 'ext.personalDashboard.activeDiscussions';
			return $moduleGrouping;
		}
		return $moduleGrouping;
	}

imagine having url params like ?mainPrimary=banner|riskyArticleEdits&sidebarPrimary=impact&sidebarSecondary=policiesGuidelines

and/or we can package those up like:

?moduleGroup=NewModerators

and have something like this in extension.json:

{
  "ModuleGroups": {
    "NewModerators": {
      "main": {
        "primary": {
          "ext.personalDashboard.banner": {
            "display": true
          },
          "ext.personalDashboard.riskyArticleEdits": {
            "display": true
          },
          "ext.personalDashboard.activeDiscussions": {
            "display": false
          }
        }
      },
      "sidebar": {
        "primary": {
          "ext.personalDashboard.impact": {
            "display": true
          }
        },
        "secondary": {
          "ext.personalDashboard.policiesGuidelines": {
            "display": true
          }
        }
      }
    }
  }
}

I just merged this and then had a thought afterward- we probably only want to call this the first time they visit not every time the component is mounted- though this can be done in a follow up patch.

In T421490#11832660, @Samwalton9-WMF wrote:

It looks like the display is now good, but selecting a discussion which previously had this issue still sends you to a mangled URL:
e.g. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#%3Cspan_id=%22Presumptive_deletion_for_AI-blocked_users.3F%22_typeof=%22mw:FallbackId%22%3E%3C/span%3EPresumptive_deletion_for_AI-blocked_users? instead of https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#Presumptive_deletion_for_AI-blocked_users?

Ok upon further research this is still a violation which makes sense as we're writing to the DB on a GET request.
The correct way to fix this would be to call the mw.Api to update this preference from the client side.

Still seeing an error on trwiki

Can we link Special:Log/Automoderator to the log page?

Hi! I had some product/design questions about this implementation.