Entity - allowedFields inconsistancy

@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.
https://forum.codeigniter.com/thread-79985.html
(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.