Closed riker09 closed 5 years ago
yeah had similar thoughts about eval(), how about supporting both, means leaving the decision to the user to go for the higher "risk" eval or use "prefix" and/or "suffix" ?
That will make everybody happy. The documentation should reflect this and warn the user that the displayed data will pass through eval
and that it should be avoided, yaddah, yaddah... :slightly_smiling_face:
Affirmitive!
prefix
, suffix
and align
for cell-text-alignment.modify
will be kept for maximum flexibilitymodify
go and get it :smile:
Seems to work for me. :slightly_smiling_face:
But note the mis-aligned header of the Diesel
column:
sort_by: diesel_sort_col+
columns:
- attr_as_list: stations
modify: x.brand
name: Tankstelle
- attr_as_list: stations
id: diesel_sort_col
modify: Math.abs(x.diesel)
hidden: true
- attr_as_list: stations
modify: Math.abs(x.diesel).toFixed(2)
id: diesel_price
suffix: ' €'
align: right
name: Diesel
- attr_as_list: stations
modify: Math.abs(x.e5).toFixed(2)
suffix: ' €'
align: right
id: e5_price
name: Super
- attr_as_list: stations
modify: Math.abs(x.dist).toFixed(1)
align: right
id: distance
suffix: ' km'
name: Distanz
entities:
include: sensor.gas_prices
max_rows: 10
title: Spritpreise
type: 'custom:flex-table-card'
ok, so this looks fixed for me, the format issue inside the
if this persists, can you please open another ticket for this, maybe also with some insight what happens if you "inspect" this element and start to play with it's css attributes...
When displaying external sensor data (e.g. fetched from an API) the usage of
eval
will execute malicious code in the context of the trusted HA user interface. I know that this probably very far-fetched but I strongly support the plan toAnd drop
eval
completely.