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
Resolve topic should mark topic as unread only for participants #19709
Comments
Hello @zulip/server-message-view members, this issue was labeled with the "area: message-editing" label, so you may want to check it out! |
@zulipbot claim |
Hello @mitanshu001, it looks like you've currently claimed 1 issue in this repository. We encourage new contributors to focus their efforts on at most 1 issue at a time, so please complete your work on your other claimed issues before trying to claim this issue again. We look forward to your valuable contributions! |
ERROR: You have not claimed this issue to work on yet. |
@timabbott will have more insight into whether this is a good beginner issue. |
This is probably accessible to someone good at using Except that's probably awkward, since the participants are rare (So in a 10K user stream, you'll be passing 10K-7 users around). So probably we want a new I expect it won't merge quickly, as we'll need some iteration (e.g. we may refactor it 2-3 times after getting something basic working that has tests), but it's an OK thing to work on for someone experienced in development in general but not the Zulip codebase specifically. |
Thanks, Tim for the explanation |
@zulipbot claim |
Welcome to Zulip, @collinwhitlow! We just sent you an invite to collaborate on this repository at https://github.com/zulip/zulip/invitations. Please accept this invite in order to claim this issue and begin a fun, rewarding experience contributing to Zulip! Here's some tips to get you off to a good start:
As you work on this issue, you'll also want to refer to the Zulip code contribution guide, as well as the rest of the developer documentation on that site. See you on the other side (that is, the pull request side)! |
ERROR: You have not claimed this issue to work on yet. |
@zulipbot claim |
Hello @collinwhitlow, it looks like we've already sent you a collaboration invite at https://github.com/zulip/zulip/invitations, but you haven't accepted it yet! Please accept the invite and try to claim this issue again afterwards. We look forward to your contributions! |
@alya my invitation expired before I had a chance to get started on it. Do you have any idea how I can go about getting a new one so I can successfully claim this issue? |
We may need to manually cancel and resend it? I'm not sure. CC @timabbott |
Sent a new one. |
Thank you, @timabbott |
Hello @collinwhitlow, it looks like you've currently claimed 1 issue in this repository. We encourage new contributors to focus their efforts on at most 1 issue at a time, so please complete your work on your other claimed issues before trying to claim this issue again. We look forward to your valuable contributions! |
@timabbott Since I am new to contributing to Zulip, do you happen to know which files would be the most beneficial to start with for this issue?? Thank you! |
@collinwhitlow please take a look at the (recently updated) Zulip contributor guide to learn more about how to get help. Also, keep in mind the following guideline:
I will go ahead and unassign this issue, and you should feel free to re-claim it once you have figured out how to approach it (or pick a different one if you prefer). |
That's understandable. I spent some time reviewing that link, and I am now more confident I am in a position to succeed. I'll give this another shot. |
Cool, let me know when you have a draft PR ready for review; this is one of the issues I'm tracking as important to include in the upcoming 5.0 release (final likely in January, but we want to merge as many things like this as we can before then). |
Hello @collinwhitlow, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 14 days. You can reclaim this issue or claim any other issue by commenting Thanks for your contributions, and hope to see you again soon! |
Previously, users found it annoying that the automated "Resolve topic" notifications triggered an unread for everyone in the stream; this discouraged some users from using the feature on older threads for fear of being annoying. We change this to a better default, of only users who participated in the topic (via either messages or reactions) being eligible for the new message being unread. We will likely want to create global and stream-level notifications settings to control this behavior as a follow-up -- some users, like me, might prefer the simpler "Always unread" behavior in some streams. Note that the automated notifications that a topic was resolved will still result in the topic being moved to the top of the left sidebar. This would be somewhat difficult to change, since the left sidebar algorithm just looks at the highest message ID in the topic. Fixes zulip#19709.
I opened #20977 to cover this. |
Previously, users found it annoying that the automated "Resolve topic" notifications triggered an unread for everyone in the stream; this discouraged some users from using the feature on older threads for fear of being annoying. We change this to a better default, of only users who participated in the topic (via either messages or reactions) being eligible for the new message being unread. We will likely want to create global and stream-level notifications settings to control this behavior as a follow-up -- some users, like me, might prefer the simpler "Always unread" behavior in some streams. Note that the automated notifications that a topic was resolved will still result in the topic being moved to the top of the left sidebar. This would be somewhat difficult to change, since the left sidebar algorithm just looks at the highest message ID in the topic. Fixes zulip#19709. Tests added by Aman Agrawal (amanagr@zulip.com).
Previously, users found it annoying that the automated "Resolve topic" notifications triggered an unread for everyone in the stream; this discouraged some users from using the feature on older threads for fear of being annoying. We change this to a better default, of only users who participated in the topic (via either messages or reactions) being eligible for the new message being unread. We will likely want to create global and stream-level notifications settings to control this behavior as a follow-up -- some users, like me, might prefer the simpler "Always unread" behavior in some streams. Note that the automated notifications that a topic was resolved will still result in the topic being moved to the top of the left sidebar. This would be somewhat difficult to change, since the left sidebar algorithm just looks at the highest message ID in the topic. Fixes zulip#19709. Tests added by Aman Agrawal (amanagr@zulip.com).
At present, resolving a topic marks it as unread. This can be annoying to users, as it unnecessarily bumps the topic, when in fact the intent is to clearly mark it as being "done". However, participants in a topic may want to be alerted when a topic is resolved, e.g. to make sure that they agree with the decision to resolve it.
To balance between these needs, resolving or unresolving a topic should create new unread messages only for users who have participated in the topic. For all others, the resolve/unresolve messages should automatically be marked as read.
When Follow topic is implemented in #6027, this behavior should be altered so that resolving/unresolving topics creates unreads for anyone following the topic.
This change is important for resolve topic workflows, so we should consider it a release goal.
CZO discussion thread
The text was updated successfully, but these errors were encountered: