Closed jvaughan closed 3 years ago
Hi @jvaughan, thanks for your issue report! Currently available columns are found through inspection of the returned model type, rather than the underlying table. However, I see this is a real requirement.
The table column inspection is only used as a fallback when the collection model type is a generic object (only used for backend grid collections).
My current idea is to inspect the Select instance for for flat-table collections instead of only looking at the main table for generic entity types. This should then cover your case, as well as support joined tables for the generic type collections.
Thanks for the response (and great module!)
Would the array source be the way to go to have these fields included for the time being?
I've just released 1.1.5 - it would be super cool if you could update to that version and try if that works for you with a collection provider! I'll leave the issue open for a while until I hear back from you.
Wow, thanks.
Yes the column does now appear.
I am seeing an issue with boolean filtering on the (smallint) column but will raise a separate issue for that.
Thanks! One issue at a time is a good way forward!
I have a grid configured as
I have added some columns to the sales_order table and they are correctly populating and accessible with
\Magento\Sales\Model\Order::getData()
.However if I add them to
<columns><include></include></columns>
I get the errorWhat I think is happening:
I can see that the module tries to find all column names in the db in addition to finding the getter methods through reflection.
However,
\Hyva\Admin\Model\GridTypeReflection::getDbTableColumnKeys
calls\Hyva\Admin\Model\TypeReflection\TableColumnExtractor::getTableColumns($tableName)
with"Magento\Sales\Model\Order"
as the parameter value.The check therefore fails: the value for
$tableName
that\Hyva\Admin\Model\TypeReflection\TableColumnExtractor::describeTable
ends up checking for doesn't work as the value should besales_order
(the actual table name).