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
Currently when listing observations through the web API we return associated tags with that observation. Some presets (categories) don't have tags which means a hard to categorize observation. Ideally, observations returned by the API should include the presetRef resolved (so, not returning the id, but the whole preset doc).
A thing to decide is if the preset itself resolves its references, since a preset has fieldRef and iconRef.
It would be useful as a first feature (if its possible) to just resolve the fieldRef, iconRef doesn't seem a priority at a glance.
If the complexity of solving this is big, a compromise would be to just return the name of the preset
The text was updated successfully, but these errors were encountered:
FYI presets/categories should always have tags, and each preset/categories tags should be different. We need to enforce that when building presets and/or reading presets. It's necessary for exploring / filtering and exporting data in the future.
Description
Currently when listing observations through the web API we return associated tags with that observation. Some presets (categories) don't have tags which means a hard to categorize observation. Ideally, observations returned by the API should include the
presetRef
resolved (so, not returning the id, but the wholepreset
doc).A thing to decide is if the
preset
itself resolves its references, since apreset
hasfieldRef
andiconRef
.It would be useful as a first feature (if its possible) to just resolve the
fieldRef
,iconRef
doesn't seem a priority at a glance.If the complexity of solving this is big, a compromise would be to just return the
name
of the presetThe text was updated successfully, but these errors were encountered: