-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
settings: Fix "message content in message notification emails". #27543
base: main
Are you sure you want to change the base?
Conversation
Hello @zulip/server-settings members, this pull request was labeled with the "area: settings UI" label, so you may want to check it out! |
0fbbde0
to
610570e
Compare
Thanks for working on this, @kartikbhtt7 ! Please fix the failing tests and post a comment requesting a review. |
You will also need to include a screenshot showing the tooltip. |
610570e
to
41e42da
Compare
@alya |
Thanks! The tooltip should be on the disabled setting itself. We don't want a separate |
ed6ab14
to
8b83f4b
Compare
@alya |
8b83f4b
to
4048ea3
Compare
Thanks! The screenshot looks good to me now. @sahil839 could you review this one when you have time (not an 8.0 goal)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Posted couple of comments.
const settings_is_disabled = { | ||
message_content_in_email_notifications: | ||
!page_params.realm_message_content_allowed_in_email_notifications, | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can directly pass message_content_in_email_notifications_disabled
as an argument below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in the latest commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I was thinking of something else, but then I noticed that we use a loop to render the email notification settings. Hmm, I am not sure this is the right way to do this. We probably need to refactor some code in settings_config.ts
that handles all these notification setttings.
We have show_push_notifications_tooltip
which gives the status of whether the setting is disabled or not, but that is currently used only for mobile push notification related settings. We can probably rename it to something like disabled_notification_settings
and then add message_content_allowed_in_email_notifications
in that object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A temporary workaround could be to disable the settings in JS rather in doing it in handlebar templates, but I guess the above approach seems good for long-term. Tbh I was confused why we use show_push_notifications_tooltip
object to check whether the setting is enabled or not. @timabbott your thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think renaming this object to disabled_notification_settings
would probably suffice.
appendTo: () => document.body, | ||
onHidden(instance) { | ||
instance.destroy(); | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tooltip is shown even when the setting is not disabled. Please look at existing examples in the codebase where we show tooltip only for disabled cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in the latest commit
4048ea3
to
737cd99
Compare
Hello @kartikbhtt7, it seems like you have referenced #27262 in your pull request description, but you have not referenced them in your commit message description(s). Referencing an issue in a commit message automatically closes the corresponding issue when the commit is merged, which makes the issue tracker easier to manage. Please run An example of a correctly-formatted commit:
To learn how to write a great commit message, please refer to our guide. |
@kartikbhtt7 are you planning to address the feedback on this? I've tagged it as something other developers can pick up since it's been quite a while. |
sure I'll address the feedbacks. |
737cd99
to
61c5dbe
Compare
addressed the feedback |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few points -
- There are some unrelated changes which should be fixed.
- Can you also implement the changes discussed in https://github.com/zulip/zulip/pull/27543/files#r1438156860. Would be good if there is a separate commit for renaming the object in
settings_config
and then the commit which disables the setting. - Please update the commit message to mention the issue number there is no need to mention the PR number. And it should be written as "Fixes part of Changes to "Allow message content in message notification emails" #27262.", since the issue should still remain open.
ig these are some changes that got introduced by the ./tools/lint command will implement rest of the changes as mentioned. |
I don't think that would be the case. Will most probably be fixed by rebasing onto main. |
Heads up @kartikbhtt7, we just merged some commits that conflict with the changes you made in this pull request! You can review this repository's recent commits to see where the conflicts occur. Please rebase your feature branch against the |
This PR fixes this issue.
Fixes: #27262
Self-review checklist
(variable names, code reuse, readability, etc.).
Communicate decisions, questions, and potential concerns.
Individual commits are ready for review (see commit discipline).
Completed manual review and testing of the following: