There is a bug reported that registration of ClassicLinkRoute route (that is a special route that handles "classic" links like '/templates/page.aspxx?id=77') will brake Set access rights.

Thank you for your answer, Johan. What workaround can I apply to solve this problem?

Are there any alternatives/recommendations for installations wishing to keep their classic templates/page.aspx/?id=1234 functionality working without having to use the ClassicLinkRoute route? Or, do we need to create an HttpModule or Handler for intercepting requests before they are handled by EPiServer?

What you probably could do is to create your own class that inherits ClassicLinkRoute and then override GetRouteData as:

  public override RouteData GetRouteData(System.Web.HttpContextBase httpContext)
        {
           if (!httpContext.Request.Url.Path.StartsWith(EPiServer.Shell.Paths.ToResource("CMS", null)))
           {
               return base.GetRouteData(httpContext);
           }

           return null;
        }

and then register your own route instead of ClassicLinkRoute

I just implemented this. And it works like intended. 

I am now able to edit the "Set Access Rights" panel in Admin.

Still having trouble with the ClassicLinkRoute.

Even if I inherit the class, and in the GetRouteData method just returns null without any other code, some links in admin mode gets corrupted.

With the inherited class registered;

Dashboard url; http://site/?action=Index&controller=Dashboard&moduleArea=Shell

Addons url; http://site/?action=Index&controller=AddOns&moduleArea=EPiServer.Packaging.UI

Without adding the ClassicLinkRoute in registerRoutes;

Dashboard url; http://site/login

Addons url; http://site/login/AddOns

So, just by adding a class inherited by ClassicLinkRoute and returning null directly in GetRouteData will corrupt some admin urls. Other urls might be broken as well, I havnen't checked every corner of admin yet...

I hope EPiServer got some attention on this one, as it will be a major rewrite to workaround this at the moment. Is it possible for developers to get an insight into the bug registration site?

Any other ideas for us to try out?

Try override GetVirtualPath as well as:

public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values)
        {
            return null;
        }

Thanks, didn't try that yet! 

That did the trick, returning null kept the provider out of the loop.

Now, I am implementing the same rules in GetVirtualPath method, and first try looks promising.

Thanks for the help! When I have tested the code, I can post a reply with the implementation.