Changing page type causes history to not load

[barrykeenan]

Using silverstripe/versioned 1.7.2

A page with existing history loads correctly. When I change the Page type in the CMS page Settings, the history does not load, with the following error in the console:

{
    "data": {
        "readOnePage": { "ID": "3923", "Versions": null, "__typename": "Page" }
    },
    "errors": [
        {
            "message": "Cannot view versions on Page",
            "locations": [{ "line": 4, "column": 5 }]
        }
    ]
}

The problem seems to be in Versioned::canViewStage() which is called by SilverStripe\Versioned\GraphQL\Operations\ReadVersions to get the history.

When the current page type is different from an older version, line 1733 in Versioned::canViewStage() returns null

$versionFromStage = DataObject::get(get_class($owner))->byID($owner->ID);

Even though the ID is there, the classname does not match, so the history cannot be viewed.

[oddnoc]

Our team have just independently rediscovered this issue. Oddly, if the old class name is a class that no longer exists in the codebase, then history succeeds.

[davejtoews]

I've just reproduced this error on multiple codebases as well. Will add a bit of info in case it is useful.

On attempting to load the history tab, a request to /admin/graphQL returns the following response:

{
    "data": {
        "readOnePage": {
            "id": "358",
            "versions": null,
            "__typename": "Page"
        }
    },
    "errors": [
        {
            "message": "Cannot view versions on Page",
            "code": 0,
            "file": "/var/www/html/vendor/silverstripe/versioned/src/GraphQL/Resolvers/VersionedResolver.php",
            "line": 79,
            "trace": false,
            "locations": [
                {
                    "line": 4,
                    "column": 5
                }
            ]
        }
    ]
}

(This is with SS_ENVIRONMENT_TYPE="dev" for extra details)

In all cases I tested, both the original page class and the updated page class were namespaced subclasses of Page. I mention this because this issue seems similar to #363 , but it occurs in different circumstances, and the bug is still present when running version 4.11

[davejtoews]

In my case I was able to fix the history tab by removing all rows from the Page_Versions and SiteTree_Versions of the database which referenced versions of the page when it had a different class.