You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we address assets a lot by their name (possibly because that is more user-friendly). This happens in our data model (aggregation class Resource is initialised with the name of an asset or an asset group), the UI (session variable "resource") and maybe the API (validator assets_required, which also works for weather sensors and markets, expects asset information encoded in the entity addresses, and that the ID for assets but the name for markets and sensors, so it's unclear what effort is required).
we have both display name and asset name, which can be set independently, and that can lead to confusing states (they can be quite different which would not be good and also the name needs to be unique if it is being used to identify assets, so we need good logic to ensure that).
In #20 I already attempted to make sure the display name is derived from the asset name (as I believed the asset name is the crucial functional field, the display name is for showing) but stopped when I realised how much code I would have to change.
We need a new policy here. Options:
Assets (and sensors and markets) will only have an ID and a name. The name can be freely chosen but is just for display. Simplifies the model, but requires UI work (always longer than you think), breaking API changes and the solution for aggregated asset levels is not clear.
Keep using asset.name but make it strictly dependent on display name (parameterised, so url-friendly), i.e. no user can edit it. Maybe rename it to ident_name or so.
In all cases, assets, sensors and markets should be modelled and treated in the same way (right now, markets and sensors have no id field for instance, but assets do).
The text was updated successfully, but these errors were encountered:
Can we mark this as resolved? Relevant database models and API versions are deprecated. All GenericAsset models have an ID now, and API version 3 uses only IDs to identify database models. Dashboard grouping of assets (by owner or GenericAssetType) also doesn't rely on the asset name anymore.
Right now we address assets a lot by their name (possibly because that is more user-friendly). This happens in our data model (aggregation class
Resource
is initialised with the name of an asset or an asset group), the UI (session variable "resource") and maybe the API (validatorassets_required
, which also works for weather sensors and markets, expects asset information encoded in the entity addresses, and that the ID for assets but the name for markets and sensors, so it's unclear what effort is required).The problems with this are that:
In #20 I already attempted to make sure the display name is derived from the asset name (as I believed the asset name is the crucial functional field, the display name is for showing) but stopped when I realised how much code I would have to change.
We need a new policy here. Options:
ident_name
or so.In all cases, assets, sensors and markets should be modelled and treated in the same way (right now, markets and sensors have no
id
field for instance, but assets do).The text was updated successfully, but these errors were encountered: