-
-
Notifications
You must be signed in to change notification settings - Fork 671
Add ultra basic support for the SubMessage-based polls feature #3205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This is the beginning of implementing zulip#3205 We currently do not do anything with the received data, but acknowledge the existance of the `submessages` property in the `Message` type.
This is the beginning of implementing zulip#3205 We currently do not do anything with the received data, but acknowledge the existance of the `submessages` property in the `Message` type.
@timabbott To clarify some aspects that seem to be true:
|
yes.
yes; the client can ignore any other submessage until if/when we change that.
currently, yes, though that could change in the future.
yes. |
This is the beginning of implementing zulip#3205 We currently do not do anything with the received data, but acknowledge the existance of the `submessages` property in the `Message` type.
This is the beginning of implementing zulip#3205 We currently do not do anything with the received data, but acknowledge the existance of the `submessages` property in the `Message` type.
This is the beginning of implementing zulip#3205 We currently do not do anything with the received data, but acknowledge the existance of the `submessages` property in the `Message` type.
@borisyankov @gnprice how close are we to merging this? We've been getting complaints from users about the frankly poor situation that polls are invisible in the mobile apps. |
@timabbott we have the #3220 ready to merge. It visualizes a placeholder that says we do not support 'widgets' yet though. I have started the next phase in a PR that is very WIP and far from done. To clarify where I think the effort in implementing it fully lies:
When talking with Rishi about the widgets (not directly this PR) he said we consider it less of a priority, maybe compared to the effort to implement. Thus I have been a bit unclear if we should push on this or other issues. |
I chatted with Rishi about this. I think this is a P1 issue, specifically for just the So we should prioritize improvements beyond "/poll isn't supported on mobile" (maybe with a link to open that page in the webapp) to the extent that finishing the rest of /poll is easier than finishing out other P1 issues (of which I feel like we have a ton with an open PR). |
Small update: I just merged #3220 , so we'll now show
(The main part of this issue remains open.) |
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (c174a0) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (c174a0) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (c174a0) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (c174a0) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (c174a0) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (c174a0) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (c174a0) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (5046781) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Widgets support has been in great demand from users (as it was implemented in the webapp first, and we haven't supported its display since support was added to the API). You will also see a `Poll Widget` marker in the bottom right of the box which shows it. This commit adds the `poll` widget support, and modularises widgets so it will be easier to add other widgets if required. It uses the newly introduced (5046781) `getOwnUser` to get the `user_id` of the current user in order to check it against the `key` provided in submessages (which are only widgets for now) of type `vote`, to see if the current user has voted on the `option` in that `poll`. Styling has been duplicated from and merged with `.reaction`, while the borders of the `.widget` class has been changed to match the `.static-timestamp` class. Fixes zulip#3205.
Any update on polls in mobile app? I am still getting "Interactive message -- To use, open on web or desktop". |
Thank you! |
Zulip has an experimental "polls" feature, which uses the special SubMessage table in the database for its storage (https://zulip.readthedocs.io/en/latest/subsystems/widgets.html#poll-todo-lists-and-games). You can create one on web by sending a message with
/poll
as the content. The UI is currently pretty janky; we have a separate issue on web (zulip/zulip#11010) for improving that.The polls feature has been getting a decent amount of interest from folks who want it in Zulip Cloud, so we need to take steps to make them display in a not-totally broken fashion on mobile.
Structurally, the
widgets
/submessage
feature has some important properties for mobile: The API only sends and receives JSON, viasubmessage
events (or the.submessage
field on a message object fetched from the server). The client is completely responsible (and empowered) to render the data as it pleases, as well as enabling UI.In terms of staging, I think there's a few levels of mobile-side support for this widget (or any other widget for that matter, though the others are more prototypes and don't have a lot of demand so we shouldn't worry about them).
poll
submessage/widget entry as the most immediate hack to detect and say "This message is a poll, which is not supported on mobile yet.".The text was updated successfully, but these errors were encountered: