This is a first stab at getting a workflow set up to configure the initial administrative user account on a fresh install. Currently, the whole "register an account" functionality is missing and it'll just fatal, but I'm planning to build that out pretty soon here 😬
- rSIM4416423945cb: Initial user registration workflow
Ran locally and saw the application crash and burn when it realized I didn't have an account. Then added the appropriate redirect and saw things get redirected to the approriate /auth/register route.
This implementation is also wrong atm. Properly, I'll need to use some flask wrapper function for this since __init__ by definition can't actually return anything (the implication being that, short of raising an exception, we can't interrupt the normal course of action and say, "Return page Y instead of page X"). I'll fix this in a subsequent diff.
My rough plan following this diff is basically:
- Switch up how we're doing page rendering since that's kind of murky current in terms of how we distinguish between 'build a sanitized HTML element' and 'render a specific page'. That can be cleaned up pretty easily and it's probably best to do that now while the codebase is still small
- Build out the UI for the initial user registration flow. I think this will be the same deal as for a generic user registration, just with a 'this user is an admin' flag toggled
- Build out some infrastructure around password management and credential checking. This'll be a "fun" learning adventure for me.
- Build out the ORM piece so we can actually register a user and store their info to the database
where did you use APP_ROOT?
So for the first pass, since self.issues is empty, we will jump to line 47. If there is any issues, we will start appending issues?
priority is always 1? what is priority for?
Questions about this class.
Does this return a list of dictionary?
why do you have empty line on 21 and 29? What makes you decide whether the name should be upper or lower case?
do we want to set echo or echo_pool? pool_timeout?
Uhhh... Somewhere way downstream, I forget. You can use the "Pattern Search" option if you open up the repo in Diffusion to find where all it's used if you want. Not relevant to this revision, though
Almost. Basically, this is checking if all of the required variables to be able to establish a database connection have been set in the config files. If any are missing, it'll be impossible to check if the database is reachable because we don't have all the necessary info, so there's no point in even running this check until those other issues get resolved.
Haha I'm not really sure. I mean, right now it isn't used. But eventually I'd like to have some mechanism to determine "is this issue a stop-the-world, everything's on fire" type of deal, or just a "hey, maybe get around to this when you can" sort of thing.
NUX is New User Experience. Basically "do we need training wheels mode" or not.
Empty lines are just to break things up a bit, no real rationale otherwise as long as it's PEP8-compliant.
SHOUTY are constants; normal cased are ones that can be overwritten
No idea! I don't even know if I have pooling set up properly. It's on my to-do list to figure out.