Registering Web Users from a Company Dashboard with FormLister

Some projects do not offer public user registration at all. Instead, a company account creates its own employee accounts from a protected dashboard. That changes the assumptions behind a standard registration controller and forces you to rethink the FormLister flow.

the discussion described exactly that case: one web user group created another group inside a private area. The default Register controller expected a public registration flow, so the developer tried to remove the guard that blocks already logged-in users.

The overridden render method

public function render()
{
    if ($id = $this->modx->getLoginUserID('web')) {
        $this->redirect('exitTo');
        $this->user->edit($id);
        $this->setFields($this->user->toArray());
        $this->renderTpl = $this->getCFGDef('skipTpl', $this->translate('register.default_skipTpl'));
        $this->setValid(false);
    }

    return parent::render();
}

Removing the guard is only the first half of the task. If the page simply reloads without creating a user, the next thing to inspect is the registration controller logic itself: redirects, permissions, user-group assignment, and the validation/report flow after submit.

Practical rule

• show the registration form only to the company role that is allowed to create users
• keep the new user in the target web group, not in the current session context
• log validation and controller errors explicitly so silent reloads are easier to debug

This pattern is still useful on internal dashboards, partner cabinets, and HR-style mini portals. The important part is not just bypassing the default render check; it is designing the registration flow as an admin-like action performed by an authenticated user with limited scope.