Make UserEntity a setting

[christianberkman]

Hello,

Just starting to implement Shield for the first time.

Followed the example to add first_name and last_name columns to migration and custom user model, worked out fine.
I also wanted to customise the user entity, which I also managed but I found out that the User entity is hard-coded in RegisterController (and probably elsewhee). Fot me to change that I needed to extend the RegisterController and add custom routes.

This works well, but woul it be an idea to make the UserEntity a setting, just like UserProvider?

I'd be happy to start a pull request.

[datamweb]

Hello,

Thank you for your thoughtful and valuable suggestion!

We’re pleased to hear that you successfully added first_name and last_name to your custom user model and managed the customization of the user entity. Your idea to make UserEntity a configurable setting, similar to UserProvider, is indeed interesting and could be quite beneficial.

Currently, it is possible to customize the user entity, although it might be a bit time-consuming. That said, your suggestion could greatly enhance the process of working with Shield.

<?php
// app/Controllers/RegisterController.php 
declare(strict_types=1);

namespace App\Controllers;

use App\Entities\UserMe;
use CodeIgniter\Shield\Controllers\RegisterController as ShieldRegister;

class RegisterController extends ShieldRegister
{

    protected function getUserEntity(): UserMe
    {
        return new UserMe();
    }
}

<?php
// app/Entities/UserMe.php
declare(strict_types=1);

namespace App\Entities;

use CodeIgniter\Shield\Entities\User;

class UserMe extends User
{
   
    public function MethodMe()
    {
        return 'Ideas';

    }
}

// app/Config/Routes.php
service('auth')->routes($routes, ['except' => ['register']]);

$routes->get('register', '\App\Controllers\RegisterController::registerView');
$routes->post('register', '\App\Controllers\RegisterController::registerAction');

If we were in the early stages of the release, I would definitely support this idea. However, considering that many versions of Shield have already been released and encouraging users to update their config file to include a new variable could be challenging, I’m currently hesitant about implementing this change.

Your suggestion remains valuable and could be revisited for future improvements. Additionally, you might want to gather feedback from others on this matter and consider their perspectives as well.

Thank you once again for your great idea and for contributing to the project!

[christianberkman]

Hi @datamweb

I had not considered the config issue. What about the following (code written from head, not tested)?

// UserModel.php
protected function getReturnType()
{
   return $this->returnType;
}

// RegisterController.php (and other places)
protected function getUserEntity(): User
{
   return new ($this->getUserProvider)->getReturnType();
}

Coule even include a fallback option to User()?

[datamweb]

It seems that we get what you need with the following refactor.

// Refactor CodeIgniter\Shield\Controllers\RegisterController
protected function getUserEntity(): User
{

-$provider = model(setting('Auth.userProvider'));

-assert($provider instanceof UserModel, 'Config Auth.userProvider is not a valid UserProvider.');

-return $provider;

+$getUserProvider = $this->getUserProvider();
+return (new $getUserProvider->returnType);
}

After that, the user should set the value of $this->returnType in her custom model as follows:

<?php
//app\Models\UserModel 
declare(strict_types=1);

namespace App\Models;

use CodeIgniter\Shield\Models\UserModel as ShieldUserModel;

class UserModel extends ShieldUserModel
{
    protected function initialize(): void
    {
        parent::initialize();

        $this->allowedFields = [
            ...$this->allowedFields,

            // 'first_name',
        ];
+$this->returnType = 'App\Entities\UserMe';
    }
}

[christianberkman]

Exactly. I do believe this would would benefit devs without impacting much of anything? Should I open a PR?

[datamweb]

Yes, if you believe this change can help developers and have a positive impact, opening a Pull Request (PR) is a good idea. The project team will review it and provide feedback if needed.

Looking forward to your PR!

[datamweb]

Please make sure to include any necessary documentation in your PR.

[christianberkman]

Will do!