The test was successful in PR#513 launched on the master branch Nov 3, 2020, but failed in PR#515 launched on Nov 5.

The failure coincides with the installation of the package freeipa-fas on the test machines.

Issue tracked in freeipa-fas as https://github.com/fedora-infra/freeipa-fas/issues/131

Opened issue in freeipa-pr-ci in order to avoid freeipa-fas package installation in PRCI tests:
https://github.com/freeipa/freeipa-pr-ci/issues/400

Hey folks! This is caused by a Javascript issue that I'm not sure how to solve. The freeipa-fas extension defines a plugin that has 'freeipa/menu' in its defined requirements at the top of the file. It works in the main UI, but it fails on the reset_password.html view because it tries to load a ui/js/freeipa/menu.js file which does not exist. I suppose it works in the main UI because the freeipa/menu component is already loaded, so the plugin loader does not try to load an additional file (I don't know Dojo, this is just what I can gather).

Could you advise me on the API to use to make the plugin work both in the main UI and on the reset_password.html view? Thanks.

@stsymbal could you help @abompard? thanks.

The freeipa-fas package is not installed any more on the test machines, (we can see a successful run in PR 533 for instance), hence closing as fixed:

Passed  test_webui/test_loginscreen.py::TestLoginScreen::test_reset_password_view

I'd still be interested in knowing how I can extend the UI without breaking the reset password page, if you can spare some time to point me in the right direction. Thanks.

@abompard

I see only one possible quick fix there. Before the plugin is loaded there can be added a check:

function (phases, IPA, menu, reg) {
  var page_name = location.pathname.split('/').pop() || "index.html";
  if (page_name != 'index.html') {
    return;
  }
  // ...
}

On FreeIPA level we can't filter any plugin, because to get some info about the plugin we need to load it first. On that stage there are some phase subscriptions, so later this code would be executed anyway.
So only one way to avoid such behaviour is keeping the stub on the start of the plugin init function.

I tried that but it still fails, since freeipa/menu is still present in the define list (1st argument), the plugin loader still tries to load a freeipa/menu.js file which does not exist.

Here's what the beginning of my script looks like when I added your change:

define([
        'freeipa/phases',
        'freeipa/ipa',
        'freeipa/menu',
        'freeipa/reg'
    ],
    function (phases, IPA, menu, reg) {

        var page_name = location.pathname.split('/').pop() || "index.html";
        if (page_name != 'index.html') {
            return;
        }

        var exp = IPA.fasagreement = {};

        var make_spec = function () {
[...]

This seems like the same problem I noted with the migration page being blank. Is a fix in the works?