This will allow us to re-use this logic later, when we add support for
re-checking notification settings just before sending email/push
notifications to the user.
Also, since this is essentially part of the notifiability logic,
this better belongs to `notification_data.py` and this change will
hopefully reduce the reading complexity of the message-send codepath.
This commit basically updates the frontend code to directly use
delivery_email field instead of functions like show_email or
email_for_user_settings at places where we want to show email.
We can do this change since we recently updated the server code
to always pass "delivery_email" code in the user objects with its
value being null if the real email is not accessible.
Showing email or "hidden" or nothing at various places in UI like
in users list, subscriber list, user profile popover and modal is
same as before.
Major points -
- Removed show_email and email_for_user_settings functions since we
directly use delivery_email field now as explained above.
- While sorting by emails in the users list, users with real emails
hidden are always shown in last when sorting alphabetically and at
the top when sorting reverse alphabetically. Also, those users with
real emails hidden, are sorted by name among themselves. As we did
before, we do not allow sorting by email when all emails are hidden.
- There is no change in typeahead behavior at this point. We either
hide the email completely or show the real or fake email based on
user level setting.
- Added code to handle delivery_email events and appropriately add/remove
delivery_email field from person objects.
This commits update the code to use user-level email_address_visibility
setting instead of realm-level to set or update the value of UserProfile.email
field and to send the emails to clients.
Major changes are -
- UserProfile.email field is set while creating the user according to
RealmUserDefault.email_address_visbility.
- UserProfile.email field is updated according to change in the setting.
- 'email_address_visibility' is added to person objects in user add event
and in avatar change event.
- client_gravatar can be different for different users when computing
avatar_url for messages and user objects since email available to clients
is dependent on user-level setting.
- For bots, email_address_visibility is set to EVERYONE while creating
them irrespective of realm-default value.
- Test changes are basically setting user-level setting instead of realm
setting and modifying the checks accordingly.
Previously, user objects contained delivery_email field
only when user had access to real email. Also, delivery_email
was not present if visibility setting is set to "everyone"
as email field was itself set to real email.
This commit changes the code to pass "delivery_email" field
always in the user objects with its value being "None" if
user does not have access to real email and real email otherwise.
The "delivery_email" field value is None for logged-out users.
For bots, the "delivery_email" is always set to real email
irrespective of email_address_visibility setting.
Also, since user has access to real email if visibility is set
to "everyone", "delivery_email" field is passed in that case
too.
There is no change in email field and it is same as before.
This commit also adds code to send event to update delivery_email
field when email_address_visibility setting changes to all the
users whose access to emails changes and also changes the code to
send event on changing delivery_email to users who have access
to email.
These being possibly `display: block` in some settings resulted in
them taking up visible space oddly if the asset failed to load.
tabbott could not reproduce the original bug, perhaps because changes
in the emoji CSS do `display: inline-block` on div.emoji, but the
logical intent for this component suggests it should be a span in any
case.
Fixes#23516.
The previous logic incorrectly tried to map elements of the list of
user IDs beyond 4 senders to their `.id` fields, which were undefined;
the correct thing to do is just use the list of user IDs that we
already have.
Due to `max-width: min-content` being used and `min-width: max-content`
not being applied since it is not present outside of development
environment, the text wrapped after every word.
The intention of this CSS was to restrict the max-width of the
`white-box` and I think 800px is a good max-width after which
content should wrap.
These hooks are run immediately around the critical section of the
upgrade. If the upgrade fails for preparatory reasons, the pre-deploy
hook may not be run; if it fails during the upgrade, the post-deploy
hook will not be run. Hooks are called from the CWD of the new
deploy, with arguments of the old version and the new version. If
they exit with non-0 exit code, the deploy aborts.
In commit 0d373e574b, the use of `common.status_classes` was
removed from `compose_actions.js`, so there is no longer a need
to mock it in the related node test.
In commit 6f9e97921, the last use of `pm_list_data.is_all_privates`
was removed when we restructured how private messages are shown
in the left sidebar. Removes the function since it is now no longer
relevant.
This allows us to import typeahead from people.ts with types. This is
possible since #22586 was merged.
And since "sort_emojis" is always supposed to be called with valid emoji
objects that have "reaction_type" with an optional "emoji_code", we add
a check before we see if the emoji is popular to avoid poking
popular_set with an undefined value.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
The implementation of the emoji sorter relies on the presence of the
"is_realm_emoji" property. We want to be consistent with this
assumption.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This avoids the type narrowing problem when we call "is_unicode_emoji"
on an emoji object and access "emoji.emoji_code", which might be
"undefined".
In places where these helpers are accessed, we expect that
"reaction_type" is always present so that we can later correctly type
narrow Emoji into UnicodeEmoji. This updates the test cases to
respect that.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
"get_item"'s default value is not type-safe as we require its return
value to always be a "string". Note that since the mobile app does not
rely on this function directly, it is sufficient to only refactor the web
app for this transition.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Corepack manages multiple per-project version of Yarn and PNPM, which
means we have to maintain less installation code, and could help us
switch away from Yarn 1 without making the system unusable for
development of other Yarn 1 projects.
https://nodejs.org/api/corepack.html
The Unicode spaces in the timerender test resulted from an ICU
upgrade: https://github.com/nodejs/node/pull/45068.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This is helpful for debugging -- generally these tasks are in a worker
queue because they take a long time to run, so knowing what long task
is about to start before it does, rather than just after, is useful.
The loading message that occurs at the top of the narrow when first
loading the Zulip app (posted to the right of the centered Z spinner)
looked misaligned on smaller screen devices.
We fix this by just removing the 'Loading...' message, since the text
was unnecessary to communicate the idea that we're loading content.
(The text was also missing translation tags).
We add a box shadow at top of the recipient bar to hide message
text that are partially visible above the recipient bar. At 100%
zoom, this issue is not visible but it has been reported by a user
at 150% zoom.
Following this change we don't need to do change any of our JS
calculations since `y` position of header remains the same
and when determining if a header `is_sticky` that is the only
thing we verify.
Alex Vandiver
Anders Kaseorg
Abhijeet Prasad Bodas
David Rosa
Alya Abbott
Sahil Batra
Ujjawal Modi
Tim Abbott
Aman Agrawal
Lauryn Menard
Zixuan James Li
evykassirer
Sahil Singh