When a poll is created or voted on (and presumably terminated) in a group, the MessageReceivedV2 DBus signal is emitted with an empty body string and no poll-related fields in the extras dict. The daemon log correctly parses and displays the poll data (question, options, selected indices, vote number), but this information is not available to DBus consumers.
Request: expose poll create and vote data in the MessageReceivedV2 extras dict, similar to how isViewOnce and expiresInSeconds are currently exposed. For poll creates, this would include the poll question, options, and type (single/multi). For poll votes, this would include the referenced poll timestamp, selected option indices, and vote number. For poll terminations, it would do the obvious thing.
This would allow DBus-based bots to handle poll interactions programmatically without resorting to log parsing.
When a poll is created or voted on (and presumably terminated) in a group, the MessageReceivedV2 DBus signal is emitted with an empty body string and no poll-related fields in the extras dict. The daemon log correctly parses and displays the poll data (question, options, selected indices, vote number), but this information is not available to DBus consumers.
Request: expose poll create and vote data in the MessageReceivedV2 extras dict, similar to how isViewOnce and expiresInSeconds are currently exposed. For poll creates, this would include the poll question, options, and type (single/multi). For poll votes, this would include the referenced poll timestamp, selected option indices, and vote number. For poll terminations, it would do the obvious thing.
This would allow DBus-based bots to handle poll interactions programmatically without resorting to log parsing.