Model Settings for your Laravel app

Settings are merged with default settings in the AbstractSettingsManager.

/**
     * @return array
     */
    public function all(): array
    {
        $array = [];
        foreach (array_merge($this->model->getDefaultSettings(), $this->model->getSettingsValue()) as $key => $value) {
            Arr::set($array, $key, $value);
        }
        return $array;
    }

The issue with this logic is that we are merging two completely different kinds of arrays. The default settings are (or should be) a flat array with dot notation whereas the getSettingsValue may return a deeply nested array from json_decode. Merging both will result in overwriting nested defaults with the current empty value (especially a problem when adding new nested settings).

There are two simple approaches to solve this issue.

1. Use nested arrays on both sides and use array_merge_recursive
2. (Favorite) Flatten the settings value with dot notation before merging. Keep in mind that you cannot use Arr:dot for this purpose since it would also flatten non-associative arrays like ['array.0' => value] which results in poor merging.

You can use this instead:

/**
     * Check if array is associative and not sequential
     * @param array $arr
     * @return bool
     */
    static function isAssoc(array $arr)
    {
        if (array() === $arr) return false;
        return array_keys($arr) !== range(0, count($arr) - 1);
    }

    /**
     * Flatten array with dots for settings package
     * @param $array
     * @param string $prepend
     * @return array
     */
    static function dotFlatten($array, $prepend = '') {
        $results = [];
        foreach ($array as $key => $value) {
            // only re-run if nested array is associative (key-based)
            if (is_array($value) && static::isAssoc($value) && !empty($value)) {
                $results = array_merge($results, static::dotFlatten($value, $prepend.$key.'.'));
            } else {
                $results[$prepend.$key] = $value;
            }
        }
        return $results;
    }

Thanks in advance!

Hi,

I'm having this issue "Unknown field (settings) on table members". The field settings exist on the table members.

if I remove this code in Glorand\Model\Settings\Traits\HasSettingsField

if (!$this->hasSettingsField()) {
throw new ModelSettingsException("Unknown field ($settingsFieldName) on table {$this->getTable()}");
 }

it will work fine. I am using laravel 6.9.0 and this package version 3.5.4.

Anyone has this issue?

Is your feature request related to a problem? Please describe. This is a proposal to a new feature that could be implemented in this project.

Describe the solution you'd like Add a validation system when you're using the set() or update() methods to throw an exception when you break a rule.

Describe alternatives you've considered You could check the value before set or update a setting but, in my opinion, is long and boring...

Additional context This is an example of how it could be implemented:

class Chat extends Model
{
    use HasSettingsTable;

    public array $defaultSettings = [
        'news' => true,
        'language' => 'en',
        'max_size' => 12,
    ];

    // settings rules
    public array $settingsRules = [
        'news' => 'bool',
        'language' => 'string|in:en,es,it|max:2',
        'max_size' => 'int|min:5|max:15',
    ];
}

// set or update setting
Chat::find(1)->settings()->set('language','it'); // OK!
Chat::find(1)->settings()->set('news',123456); // throws an exception! - it must be a boolean

Hi. After updating to PHP 8.0, I get this exception:

Declaration of Glorand\Model\Settings\Traits\HasSettingsField::settings(): Glorand\Model\Settings\Contracts\SettingsManagerContract must be compatible with Glorand\Model\Settings\Traits\HasSettings::settings(): Glorand\Model\Settings\Managers\AbstractSettingsManager at ...vendor\glorand\laravel-model-settings\src\Traits\HasSettingsField.php:37

I recently came across a scenario where I needed settings for all the users in the collection. I tried to eager load it but unfortunately it doesn't work. I am using HasSettingsTable trait.

$users = User::with('settings')->get();

This returns an error: Call to undefined method Glorand\Model\Settings\Managers\TableSettingsManager::addEagerConstraints()

So I was wondering if there is any way to get this relation eager load? I have version 3.6.5 installed.

Modified the HasSettingsField.php to allow for reading the model's connection value (default or otherwise) as proposed on issue #62 Updated readme.md to document change

I'm using the table based setup, and I have a User model that has a setting named nickname.

Searching via a setting field blows up.

$user->with([
    'settings' => function($builder) use ($nickname) {
        $builder->where('nickname', $nickname);
    }
]);

Throws a Call to undefined method Glorand\Model\Settings\Managers\TableSettingsManager::addEagerConstraints() exception.

In the case of a multi-tenant application (or any model that uses a different connection to the default) it doesn't seem to adhere to the Model's $connection setting.

In the HasSettingField.php a method:

    /**
     * @return string
     */
    public function getConnectionName(): string
    {
        return $this->connection ?? config('database.default');
    }

And modify the hasSettingField to:

    /**
     * @return mixed
     */
    private function hasSettingsField()
    {
        return Cache::remember(
            config('model_settings.settings_table_cache_prefix') . '::has_field',
            now()->addDays(1),
            function () {
                return Schema::connection($this->getConnectionName())->hasColumn($this->getTable(), $this->getSettingsFieldName());
            }
        );
    }

[Illuminate\Database\QueryException] SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error i n your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'json not null,descriptionjso n null,detailsjson null,featuresjson nul' at line 1 (SQL: create ta bleproducts(idint unsigned not null auto_increment primary key,nam ejson not null,descriptionjson null,detailsjson null,featuresjson null,priceint not null,category_idint not null,extrasjson null,created_attimestamp null,updated_attimestamp null) default cha racter set utf8 collate utf8_unicode_ci)

Unfortunately MariaDB doesn't support column type of json :/. I changed to longText to make it work. But is that in all cases safe to do ?

Currently validated settings are discarded, and that's mostly OK, but sometimes it's not.

My case comes from using Excluding Unvalidated Array Keys.

It's possible to call validation for settings before they are set - but that kinda defeats the purpose of using a package :smile:

Describe the bug There is no support to add custom validation rules Reference: https://github.com/glorand/laravel-model-settings/issues/87#issuecomment-964529183

To Reproduce Add a custom validation rule. You'll get "expression is not allowed as field default value".

Expected behavior Convert the "settingsRules" property to a method like the "rules" method in Laravel FormRequest

Screenshots

As for getting multiple settings at once, currently what is supported is

//multiple
$user->settings()->getMultiple(
	[
		'some.setting_1',
		'some.setting_2',
	],
	'default value'
);

However, in my case, seeting_1 is true and setting_2 is false. I have tried:

//multiple
$user->settings()->getMultiple(
	[
		'some.setting_1' => true,
		'some.setting_2' => false,
	],
);

But it doesn't work.

Any workaround???

Is your feature request related to a problem? Please describe. Changing defaults currently requires code updates.

Describe the solution you'd like It would be great to have the ability to create, edit, and even delete defaults for models directly in the database so they can be changed without performing code changes, releases, or deployments.

I think just a default_settings table would probably keep things simple, with a model_type column that associates a model with a single row. The table schema structure would pretty much look the same as the model_settings table minus the model_id column.

Thanks for the awesome package, I'm loving it so far. 🙏