If you override checkPermissions() on the special page it can redirect to the login page (snippet below). This works fine, but the URL parameters should also be included. Also, if you don't have the permission when you're logged in you'll get stuck in an infinite redirect loop (at least until the browser gets tired) between the lexicon and log in pages.

public function checkPermissions() {
    if ( !$this->userCanExecute( $this->getUser() ) ) {
        $this->getOutput()->redirect("http://localhost:8080/w/index.php?title=Special:UserLogin&returnto=Special%3AEditLexicon");
    }
}

Using the returntoquery parameter on the login page to keep the parameters from the initial link. I'm not sure if it's better to just pass on all parameters or specify which ones should be kept. It should be fine either way, extra parameters won't do anything, but for some reason the array from WebRequest::getValues() includes 'title' => 'Special:EditLexicon'.

Looks like what I wanted was WebRequest::getRawQueryString. I was converting it into a string anyway.

Turns out that getRawQueryString() was tricky to get to work in the tests so I switched to getValues() and http_build_query() instead.

After logging in the user may still not have the right to edit the lexicon. In this case you can show a message for that by throwing ErrorPageError. This makes it look something like this (title should be added and the message can change):

@Lokal_Profil, we talked a bit about the situation where someone comes from another wiki and doesn't have the right and how to explain that. Do you think a message like this would be enough? We could add something like "If you came here from another wiki note that you may not have the same rights." I don't know if there's a way to "remember" that someone came from another wiki originally if you'd want to display a different message then.

After testing a bit I think what we want to have in the end is a general auto login for the lexicon page. The user doesn't have to necessarily come from a consumer wiki to trigger it. There should be a config variable to enable the auto login. I drew up a flow chart with the new functionality being dashed:

Change 957855 had a related patch set uploaded (by Sebastian Berlin (WMSE); author: Sebastian Berlin (WMSE)):

[mediawiki/extensions/Wikispeech@master] Redirect logged out users to login page if they lack right to edit lexicon

https://gerrit.wikimedia.org/r/957855

Change 957856 had a related patch set uploaded (by Sebastian Berlin (WMSE); author: Sebastian Berlin (WMSE)):

[mediawiki/extensions/Wikispeech@master] Gadget: Add an edit button to the toolbar

https://gerrit.wikimedia.org/r/957856

The patches are in, but due to updates to the version that the CI runs, they now fail due to unrelated code. When this issue came up earlier there was no easy solution. I think we managed to work around that in the end. I'll have to see if this is possible in this case.

It looks like the tests for ext.wikispeech.ui.addControlPanel aren't isolated. They cause mw.user.getRights to not work properly in later tests.

I managed to fix failing tests locally by using mw.Api.getUserInfo() instead of mw.user.getRights() (not sure why there's a difference). There still one failing test in the CI.

Looks like I've finally pinned down what the issue was: the link URL was different. Locally it's /w/index.php?title=Special%3AEditLexicon&language=en&page=1, which is what the test expects, but on CI it's /index.php?title=Special%3AEditLexicon&language=en&page=1 (without leading "/w"). It took a while to spot it since element parameters causes a lot of log output. I also missed that both expected and actual output was logged for the same reason.

Change #957855 merged by jenkins-bot:

[mediawiki/extensions/Wikispeech@master] Redirect logged out users to login page if they lack right to edit lexicon

https://gerrit.wikimedia.org/r/957855

Change #957856 merged by jenkins-bot:

[mediawiki/extensions/Wikispeech@master] Gadget: Add an edit button to the toolbar

https://gerrit.wikimedia.org/r/957856