Skip to content

CRAPP-435: Allow to refactor merge change request - #187

Open
surli wants to merge 1 commit into
mainfrom
CRAPP-435
Open

CRAPP-435: Allow to refactor merge change request#187
surli wants to merge 1 commit into
mainfrom
CRAPP-435

Conversation

@surli

@surli surli commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Description

Adds a new admin configuration option, refactorMergedChangeRequests (disabled by default), that allows page-reference refactoring (rename/move) to also apply to already merged change requests, extending the CRAPP-168 work which currently excludes them.

  • ChangeRequestConfiguration#isMergedChangeRequestRefactoringEnabled() (new default method, false) / DefaultChangeRequestConfiguration reads it from the refactorMergedChangeRequests property.
  • DocumentRenamedListener now only excludes MERGED change requests from refactoring when the option is disabled.
  • New checkbox "Refactor references in merged Change Requests" wired into the Change Request admin section (ConfigurationClass.xml, Configuration.xml, translations).

Clarifications

  • The underlying refactor operation (DefaultChangeRequestStorageManager#refactorTargetEntity) only clones the file change with a new target reference (XWikiDocument#cloneRename); it never touches the change request's content, so enabling this option cannot alter what a merged change request recorded.
  • Verified (and locked in with a test) that the change request's status is preserved through the refactor: ChangeRequest#cloneWithoutFileChanges() copies status verbatim, and the sole production caller wraps the call between ChangeRequestRefactoringEvent/ChangeRequestRefactoredEvent, which prevents FileChangeUpdatedListener from recomputing the status while it runs.
  • Default is false to preserve existing behavior; nothing changes unless an admin opts in.

Executed Tests

  • mvn -B -ntp -T 1C install (full reactor: api, discussions, default, notifications, ui, replication, xip) — green.
  • mvn -B -ntp -Pintegration-tests,docker test-compile on application-changerequest-test-docker — compiles, 0 Checkstyle violations, license check green. The new/extended RefactoringChangeRequestIT#refactoringMergedChangeRequestWhenConfigurationEnabled was statically verified only (not run against a live Docker instance).
  • Added DefaultChangeRequestStorageManagerTest#refactorTargetEntityPreservesStatusOfMergedChangeRequest, verified to actually catch a regression by temporarily breaking cloneWithoutFileChanges() and confirming the test failed, then reverting.
  • mvn -B -ntp xar:verify on application-changerequest-ui — green.

Expected merging strategy

Prefers squash: Yes


Generated with Claude Code

@surli surli self-assigned this Sep 2, 2026
* Add a new `refactorMergedChangeRequests` configuration (off by default) allowing merged change
  requests to have their page references refactored when the concerned page is renamed or moved,
  without altering their content or status
* Wire the new option into ChangeRequestConfiguration/DefaultChangeRequestConfiguration and the
  admin configuration page
* Update DocumentRenamedListener to only refactor merged change requests when the option is enabled,
  skipping the filtering pass over the change requests entirely when the option is enabled
* Add a regression test locking in that the status of a merged change request is preserved when its
  file changes are refactored
* Add/extend a Docker integration test covering the refactoring of a merged change request,
  including a page creation, a page deletion, a live edit performed after the merge, and validation
  of the resulting diff

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant