Branding authn with indigo in a frontend-base world

[arbrandes (Adolfo R. Brandes)]

@mboisson

there are lots of !importanttags which are not under my control. Those are bugs in the apps ?

Yes, most definitely. There’s no justifiable reason to use !important in a coherently cascaded set of stylesheets, which ours aim to be.

I’m writing up an epic to get rid of all of them. With any luck, I’ll be able to get the fixes in by Willow. Thanks for the help in identifying the problem!

Even the @paragon layer defines some !important properties

Unfortunately. Those will have to be fixed, too.

[arbrandes (Adolfo R. Brandes)]

@mboisson

Is it because mfe-lms-production-settings is not the right place to add this ?

I’m not going to have time to look into this just now, but I’d start by exploring two things:

1. Does the frontend-base version of Authn still respect that setting? (By looking at the code.)
2. Does it respect it if you set it directly in site.config? (By running npm run dev in a checkout of frontend-template-site and not starting Tutor’s mfe containers.)

The point being to find out where the setting is getting lost in translation.

[mboisson (Maxime Boissonneault)]

@arbrandes

I’m not going to have time to look into this just now, but I’d start by exploring two things:

No worries. Not urgent.

@arbrandes

1. Does the frontend-base version of Authn still respect that setting? (By looking at the code.)

It does still appear in the code, it uses

useAppConfig().SHOW_REGISTRATION_LINKS === false

@arbrandes

2. Does it respect it if you set it directly in site.config? (By running npm run dev in a checkout of frontend-template-site and not starting Tutor’s mfe containers.)

I am unfortunately not setup to test that route. I’ve only ever run OpenEdX through tutor.

What is not clear to me is how do I change the config returned by useAppConfig() through tutor…

[arbrandes (Adolfo R. Brandes)]

@mboisson

MFE_CONFIG['SHOW_REGISTRATION_LINKS'] = False

This should work because of the runtime translation layer, but I suspect it might be getting overriden by the app itself. I’ll have to take a look at it, later.

[mboisson (Maxime Boissonneault)]

FYI, I have even found contradicting CSS rules within the app layer, in the learner-dashboard app:

[arbrandes (Adolfo R. Brandes)]

@mboisson

Is it because mfe-lms-production-settings is not the right place to add this ? or because it’s the wrong FRONTEND_SITE_CONFIG option to set ?

Ok, finally looked into it. This is what should work today: per-app config, which gets merged into the app’s own config and so overwrites the bundled default. In your mfe-lms-production-settings patch:

FRONTEND_SITE_CONFIG["apps"] = [
    {
        "appId": "org.openedx.frontend.app.authn",
        "config": {"SHOW_REGISTRATION_LINKS": False},
    },
]

Or the legacy equivalent, which the site config endpoint translates into exactly that: MFE_CONFIG_OVERRIDES["authn"] = {"SHOW_REGISTRATION_LINKS": False}. Both are runtime config, so no rebuild needed.

Why your attempts didn’t work: in frontend-base 1.x, App.config holds both the app author’s bundled defaults and operator-supplied config, and getAppConfig() resolves them as merge({}, commonAppConfig, appConfigs[id]). Since frontend-app-authn bundles SHOW_REGISTRATION_LINKS: true, anything in commonAppConfig loses to it. MFE_CONFIG fails the same way, because the endpoint translates those keys into commonAppConfig.

I realize the ergonomics here isn’t great… so we improved it: see App.config conflates bundled defaults with operator config · Issue #268 · openedx/frontend-base · GitHub. In the next release, bundled defaults move to a separate defaultConfig, which means your original commonAppConfig approach starts working, with apps[] still available when you want to target a single app.