Related to this issue.

Problem description

With the current implementation of RouteChangedUpdater it is not possible to change the slug to an slug that already is in the route history.

In earlier versions of Sulu (v2.6.x) the admin UI did give an descriptive error, which is not the case anymore in the latest version. (screenshot below from older project)

Currently we have a project in which we are creating routes automatically based of information from a third party system. In this automatic process we can not clean up the history route manually. Our current workaround is an event listener (DoctrineListener) on preUpdate in which we 'reclaim' (delete) history entries which overlap with the new updated slug.

/**
 * Lets a route take back a slug from its own history.
 * Open Issue: https://github.com/sulu/sulu/issues/2480.
 */
#[AsDoctrineListener(event: Events::preUpdate)]
class ReclaimRouteHistoryListener
{
    public function preUpdate(PreUpdateEventArgs $args): void
    {
        $route = $args->getObject();
        if (!$route instanceof Route || $route->isHistory() || !$args->hasChangedField('slug')) {
            return;
        }

        $objectManager = $args->getObjectManager();
        $classMetadata = $objectManager->getClassMetadata(Route::class);

        $objectManager->getConnection()->delete($classMetadata->getTableName(), [
            $classMetadata->getColumnName('resourceKey') => Route::HISTORY_RESOURCE_KEY,
            $classMetadata->getColumnName('resourceId') => $route->getResourceKey() . '::' . $route->getResourceId(),
            $classMetadata->getColumnName('locale') => $route->getLocale(),
            $classMetadata->getColumnName('slug') => $route->getSlug(),
            $classMetadata->getColumnName('webspace') => $route->getWebspace(),
        ]);
    }
}

Proposed solution

Because of the handling in earlier versions of Sulu and the current client sided admin UI behavior of making sure the slug is unique, I don't know what the vision of the Sulu team for this specific behavior.

From our perspective the automatic reclaim should not be an issue and would be desired behavior for most people. In the Admin UI an additional warning could be displayed before executing the reclaim, to handle the edge cases in which the user does not want to lose this history.

Let me know what you think about this topic. I'm happy to create an PR for this change.