I can easily get a list of (at least some of) the board views using the API:
{
boards(ids: ["12345"]) {
name
views {
id
name
type
}
}
}
So I’d presumed that I’d be able to get a list of the item views in a similar manner:
### THIS DOES NOT WORK:
{
boards(ids: ["12345"]) {
name
item_views {
id
name
type
}
}
}
As item views only have one settings_str
object per board, then likely they would be best placed under boards rather than items.
Ideal structure…
I think that the ideal structure would be something along these lines:
### THIS IS AN EXAMPLE FOR FEATURE REQUEST PURPOSES
{
boards(ids: ["12345"]) {
name
views {
id # this is the `context.instanceId` from `monday.listen("context", ...)` in a board view
name
type
app { # this would be the `context.app` from `monday.listen("context", ...)` in a board view
...
}
}
item_views {
id # this would be the `context.instanceId` from `monday.listen("context", ...)` in an item view
name
type
app { # this would be the `context.app` from `monday.listen("context", ...)` in an item view
...
}
}
}
}
For this request:
-
Add
item_views
toboards
notitems
- This allows us to easily build a storage string for an item view along the lines
const key =`app:${appId}:board:${boardId}:item:${itemId}:instance:${instanceId}`
- This would meant that an automation could perform an action (say on item creation), then based on the
boardId
,itemId
&instanceId
of the item view, it could save a configuration value to monday.storage using:
…thus configuring a specific item view using only an automation.monday.storage.setItem(key, someValue)
- This allows us to easily build a storage string for an item view along the lines
-
Add the
app
to bothboards.views
andboards.item_views
- This means that you can filter by
app.id
or similar, so that our automation configuration could create a list of available item views based on a sharedapp.id
for an automation and item view in same app
- This means that you can filter by
This is a use case for automations that customers are requesting from us now.