Welcome Guest, Not a member yet? Register   Sign In
Entity - allowedFields inconsistancy

I have been using CI4 models with entities.
I have found an inconsistency with model and entity behaviour and would appreciate some advice on whether this is a 'bug-like' feature and/or whether there is a work around for my use case.

Model Behaviour
The behaviour for models is that if you define $allowedFields...
protected $allowedFields = ['field1','field2','field3'];
Quote:Documentation => This array should be updated with the field names that can be set during save, insert, or update methods. Any field names other than these will be discarded. This helps to protect against just taking input from a form and throwing it all at the model, resulting in potential mass assignment vulnerabilities.
Great. Only allowed fields will be passed through to the db which is what the model is used for.

Entity Behaviour
For the first time, I want to use the Entity functionality but I don't necessarily want to commit the entity record to a db. I am using an Entity to consistently format some input and possibly output it to another api. ie. I want to take advantage of the Entity functionality but I might not need the database layer in this case. I setup my entity as per standard. I add the $allowedFields as usual.
protected $allowedFields = ['field1'=>NULL,'field2'=>NULL,'field3'=>NULL];
Then in the controller I reference the Entity:
$currentRequest = new \App\Entities\CurrentRequest();
I fill the Entity using the quick fill (from an input array sourced externally - not validated):
$currentRequest->fill( ['field1'=>'test1','field2'=>'test2','field3'=>'test3','field4'=>'test4','field5'=>'test5'] );
(I can use all the great Entity functionality stuff set() and get() etc and use entity functionality as you like).
Then I want to use my Entity, however as an example the output of:
outputs:   ['field1'=>'test1','field2'=>'test2','field3'=>'test3','field4'=>'test4','field5'=>'test5']

Effectively the Entity is embracing more input than the defined $allowedFields while Model does not.
  • Why doesn't Entity use $allowedFields consistently like Model and output ['field1'=>'test1','field2'=>'test2','field3'=>'test3']?
If this is not a bug or in the meantime...
  • How can I use the $allowedFields already defined in the Model to filter my output?
shows that the original definition is retained:
[original:protected] => Array
            [field1] =>
            [field2] =>
            [field3] =>
(ie. I don't know how to access [original:protected] so I could throw it back through a loop or array_filter or such...).

Thank you very much for your insight.

I don't think entities have an allowedFields property.

(08-29-2021, 04:39 PM)ojmichael Wrote: I don't think entities have an allowedFields property.
Thank you, sometimes the most simple answer is the best.

Despite what I typed in my question I actually had my entity setup with:
protected $attributes = ['field1'=>NULL,'field2'=>NULL,'field3'=>NULL];
Instead of:
protected $allowedFields = ['field1'=>NULL,'field2'=>NULL,'field3'=>NULL];
I tried the Entity using $allowedFields instead of $attributes and yeah it doesn't work.

So not a bug. However I think this is a useful piece of functionality so might raise it. Indeed where an entity is defined then the model should look to the entity to see what is allowed.

Thanks for your help.

I frequently find myself wishing Entity had its own attributing filtering and validation, and/or that Model applied its logic to *outgoing data* as well. I have a few different implementations but would be in favor of centralizing them into a library or even a framework feature. Let me know here if you end up reasoning this as an issue or feature request on GitHub!

@MGatner - I have concluded that it is not a bug. Entity does not allow allowedField out of the box. Hence I created another posting in the 'features request' forum.
(In that thread, I provided my extension of the entity class which provides an enabledField function that works similar to allowedField on a model.)
I assume that depending on demand that this sort of functionality would be embraced in core. IMHO we shouldn't need this enabledField/allowedField hack at an entity level, the attributes definition should act to filter entity output. If a field is not defined at a row level then it will not be transformed and should not be output.
IMHO from a design perspective
-I agree with you that where an entity exists all row based transformations should reside there rather than in the model. (For backwards capability this needs to continue to exist in model.)
-The model is where definitions on how and when to interact with an interface occurs (ie. the db).
* I would like to see model extended so that instead of solely being able to define db interactions that one could alternatively define other interfaces eg APIs using API Response Traits, Guzzle, MQRabbit etc
* I would foresee a model definition being unique to a specific connection (like a single db table today), however other API's using a model might have the requirement to refer to more than one entity depending on the action being performed so there might need to be a returnType [for SELECT like commands] and sendType [for INSERT like commands].
These are general design thoughts that someone brighter than I would have to opine on.
---> Sorry I'm going to try and stick to the 'features request' forum! Anyone reading please contribute there.
I consider this thread closed as a support item.

Theme © iAndrew 2016 - Forum software by © MyBB