I need to update the title of an item in my app when a user changes it in another view.
I see that there is a method called monday.listen, which takes “event” as an input. This listener gets triggered when a new item is added, or a column value is changed. But it is not fired for other common events like
Updating the title of an item
Removing an item
Is there a plan to add these, or an alternative workaround?
In our case, we have to poll for all the items in a board, and then do a diff with the previous response to see if some item was deleted. Which seems a bit tedious and network intensive. If we have a lot of simultaneous users, we could be hitting our API rate limits easily.
It would be amazing if these two events - title change and item deletion were also a part of the api specification. Hope these could be added in the near future.
What about using webhooks? Would that be a possibility for you?
You could create some webhooks in the board. One with the trigger "When an item is deleted, one with the trigger “When an item’s name changes” and maybe one with the trigger “When an item is archived”.
Since the listen api already exists, this could be extended to all other edit events on the board, like adding a new item, updating item title and deleting an item ( or subitem ).
I understand that title is not a column value. From the perspective of an app developer though, we would like to have a uniform api to listen to all edits or updates on the board. ( this could also include bulk updates )
The item name is not a column! Thats the underlying issue. Its a property of the item, not a column that belongs to the item.
(As weird as it seems, since you can get then name column existence back when you query a boards columns, and you mutate it like a column, you cannot get the actual value of the item name through column_values)
This is why it can’t be listened to.
I have opened a feature request to make the name a column_value. IF they can update the name through a column value mutation, it means the name is getting passed through the the column_values code to get back to the item. That means its entirely reasonable they could store then name as an actual column value and then forward the change also on to the item itself (as they do now). Would it be a bit of a change? Of course but it would really make the API/apps make a bit more sense since the name column is a column… sort of.