Add settings toggle for local frontend #899
Conversation
hmpf
added
enhancement
|
Hmm I don't think I like this. Without having thorouhly examined the implications of this PR it feels like it makes Argus more opinionated in how it wants to be used/configured. For example, we're not using the apps plugin system, which means that we're currently fully outside the flow of EXTRA_APPS and OVERRIDING_APPS. We have our own way of including argus_htmx. It feels like this PR wants to nudge us to a different method, and I fear we'll lose the flexibility we have now. We'd maybe want to set FRONTEND_APP to None to not have Argus include argus_htmx itself, but then Argus assumes we run the old fontend/api-only and that's also not what we want. Like I said, I haven't looked at the implications thoroughly, but this is my initial impression. I'd rather see Argus creating a new settings files that can be pointed to in prod that sets up argus for htmx usage rather than to include everything in pehaps the oauth functionality can become an app in and of itself than can be included/excluded at leisure |
|
Yeah I realized the oauth stuff can be split out into a different PR, BUT: the current, old-frontend oauth2 stuff is hardcoded to the vendored psa backend because of the loginwrapper. So in order to use ANY oauth2 we need to know that we are NOT using the old frontend, so we need a switch for that. FRONTEND_URL the setting is also used everywhere and with kubernetes it makes it easier to have the setting because django struggles to find what host it publicly runs on otherwise. (If we log with hostname from kubernetes we do not get a hostname but the node/pod-id. Much useful, very quality.) |
|
I thought this way of pulling in all the settings the frontend needs, while still supporting the old frontend, was quite neat. Every setting that argus_htmx must have is in argus_htmx.appconfig, and every setting can be overruled if necessary/as usual in a localsettings file. This is still compatible with (OVERRIDING|EXTRA)_APPS, and worst case it is always possible to clone base.py completely. The trick is, again, the site urls.py. But what root urls.py to use is still a setting. |
|
Oh I'm all for factoring out the hardcoded oauth stuff into a separate thing (eg app). My concern is with settings/base and site/urls. I'd much rather see that being more composable rather than behaviour basecd on toggles. That way we can each compose our own settings/urls as we see fit. IMHO Argus should become less opinionated on how it's used/integrated, not more. I think that requiring cloning base.py should only be done as a last resort, since we want to minimize code duplication. |
.. and due to this, move the overriding to the end of base settings
.. this makes it easy to change settings that are not app-specific, like LOGIN_URL.
.. make sure the examples are valid JSON
|
May be replaced with something else that depends on #904
Adds a setting to turn the new frontend on and the old frontend off. It is not possible to run both at the same time due to some hackery the old frontend needs for OAuth2.