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
It would be nice to have a multiple-response poll which allows users to vote for all options even if the number of options in the poll is updated. Currently, if a multi-response poll is created via --vote=X (with X being the number of options), once a new option is added, a user who has spent all of their X quota, can never vote for the new option.
Describe alternatives you've considered
I'm a mere user with no experience in developing Mattermoist plugins. So, I have not tried anything personally, but these two different approaches come to my mind:
Extend the --vote=X feature to increase the maximum number of votes X by one as options are added (not recommended because it may not be the intended purpose),
Introduce a new boolean argument (something like --vole-all) that separates the --vote=X functionality from the vote for all feature.
AFAK --vote doesn't accept zero as an argument. So, assigning 0 to unlimited votes wouldn't clash with its functionality, and in principle a good idea.
Summary
It would be nice to have a multiple-response poll which allows users to vote for all options even if the number of options in the poll is updated. Currently, if a multi-response poll is created via
--vote=X
(withX
being the number of options), once a new option is added, a user who has spent all of theirX
quota, can never vote for the new option.Describe alternatives you've considered
I'm a mere user with no experience in developing Mattermoist plugins. So, I have not tried anything personally, but these two different approaches come to my mind:
--vote=X
feature to increase the maximum number of votesX
by one as options are added (not recommended because it may not be the intended purpose),--vole-all
) that separates the--vote=X
functionality from the vote for all feature.Additional context
#256 is relevant, but a different feature.
The text was updated successfully, but these errors were encountered: