Hash the salt, user-id, and now avatar version into the filename.
This allows the URL contents to be immutable, and thus to be marked as
immutable and cacheable. Since avatars are served unauthenticated,
hashing with a server-side salt makes the current and past avatars not
enumerable.
This requires plumbing the current (or future) avatar version through
various parts of the upload process.
Since this already requires a full migration of current avatars, also
take the opportunity to fix the missing `.png` on S3 uploads (#12852).
We switch from SHA-1 to SHA-256, but truncate it such that avatar URL
data does not substantially increase in size.
Fixes: #12852.
This commit fixes the bug where the "topic unresolved" notification
is wrongly triggered when moving a message between a resolved and
unresolved topic, except for when the topics have the same name.
To resolve this issue, the commit ensures that resolved/unresolved
notifications are not sent if a message has been moved to a new
topic. This is achieved by comparing the names of the old and new
topics without considering the "resolved prefix".
The commit also accounts for the scenario where `new_topic_name`
has been truncated, indicating that it was resolved and the name
had to change to accommodate the "resolved prefix".
This solution does not try to specially handle the possible case that
a stream has two topics with the same name, even if one is resolved
and another unresolved.
Fixes#29007.
This commit updates the code so that only the moved notification is
triggered when moving a message between a resolved and unresolved
topic in different streams or when moving a topic itself.
This change takes place even when both stream change and resolve
or unresolve a topic takes place in the same API request, as we
now consider it only a move operation.
This fixes a case where a message is moved between topics that
have the same name, but one resolved and another unresolved and
in different streams. Previously a resolved or unresolved
notification would also be sent. Now, this will not happen,
ensuring only the move operation is notified.
Fixes part of #29007.
This has been unused since it was introduced in
5bb10036b57bca36d531a74e8b03188d43ec7862; presumably leftover from a
previous version of the original PR.
When `sort_emojis` function was called from emoji_picker
module, the passed arguments did not contain `reaction_type`
field. As a result the first conditional of `is_popular` function
inside `sort_emojis` always failed -- hence the array
`popular_emoji_matches` was always empty`[]`. This compromised
search especially the order of filtered emojis.
Instead of checking for `reaction_type` === "unicode_emoji" -- we
check `is_realm_emoji` field is false. Since `is_realm_emoji`
field in always present and also results in easier types, this
should be prefered over adding `reaction_type` field to the passed
arguments.
Fixes zulip#30439
Previously, when a referrer's invitation to Zulip was accepted,
they got a notification from notification-bot indicating
their invitation has been accepted.
This commit adds an option for referrer to decide
whether he wants to receive the direct notification
from the notification-bot.
Fixes: #20398
Earlier, in left sidebar, clicking on followed topic icon would narrow
to the topic.
This commit introduces the ability to open topic status menu from
left sidebar from followed topic icon.
Fixes: zulip#28941.
Earlier, in recents view and inbox view, hovering over
`topic status button` didnot show `click to change notifications for this
topic` tooltip as it was supposed to.
This commit fixes the behaviour of tooltip not showing by adding a
tooltip for `recent_view` and `inbox-view` elements.
This commit refactors the `message_list_tooltip` for `recipient_bar_icon`
tooltip in message feed and scope it to `message_feed_container` class.
This is a preparatory commit for PR #30313.
Reformatted Grafana doc into 3 part sections. One for
creating the Zulip bot and webhook URL. One for setting
up Grafana version 8.3 and above and the last one for
setting up Grafana version 8.2 and below.
Part of #29592.
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
Earlier in typeaheads, empty query suggestions would highlight all
the available suggestions for person name and channel name.
This commit changes the behaviour so that empty query doesn't give
highlighted suggestions.
To improve onboarding experience following onboarding
messages are marked as starred:
* First message in each onboarding topic.
* Initial DM sent by Welcome bot
Note: The onboarding topic messages needs to be tracked
in 'OnboardingUserMessage' model to get starred.
Fixes#29298.
We give the user some messages in their feed, so that they can
learn how to use the home view in a realistic way.
For realms having older onboarding messages, we mark the very
most recent messages as unread.
This commit updates the logic to ONLY mark the tracked onboarding
messages (if present) i.e. messages tracked in 'OnboardingUserMessage'
as unread.
Fixes part of #29298.
This prep commit reorders code blocks in 'do_create_user'
to call the function 'send_initial_realm_messages' before
'process_new_human_user'.
This is required because for the first user (who creates realm)
we need to send the onboarding messages before adding message
history (performed by process_new_human_user) otherwise messages
won't be starred as required.
This commit also takes care of NOT marking the onboarding
messages as 'historical' for the realm creator.
This commit updates the 'send_initial_realm_messages' function
to create OnboardingUserMessage rows corresponding to the
initial realm messages we send.
It helps to distinguish new onboarding messages from the
onboarding messages in the old realms.
This prep commit adds a new OnboardingUserMessage model
that will be used to mark the new onboarding messages
for new users as unread and the first message of each
onboarding topic as starred.
This table won't include the old onboarding messages.
This commit adds the missing historical flag to recent
messages added in a new user's feed.
Reason:
* User didn't receive when they were sent, so semantically
the 'historical' flag should be present.
* It helps to avoid the "You (un)subscribed to.." bookend
while reading older messages.
The bookend appears whenever the historical flag flips
between adjacent messages. Earlier, the bookend was visible
between 'recent messages' and 'older messages'. This makes
sure that the bookend is visible only at the moment new
message is sent by the user after account creation.
This commit renames the constants:
MAX_NUM_ONBOARDING_MESSAGES to MAX_NUM_RECENT_MESSAGES
MAX_NUM_ONBOARDING_UNREAD_MESSAGES to MAX_NUM_RECENT_UNREAD_MESSAGES
ONBOARDING_RECENT_TIMEDELTA to RECENT_MESSAGES_TIMEDELTA
The term 'onboarding' is preffered to be used for the
new messages sent during realm creation or new user creation.
These constants are related to already present recent messages.
Adds a linter rule for markdown files so that new cases of "e.g."
without a comma wont be introduced to user-facing documentation.
Fixes the remaining cases of "e.g." in markdown files that are not
followed by a comma.
Fixes position of unsubscribed icon so that it appears in the same line
as the list item of the typeahead and prevent typeahead to increase in
width when the icon is shown.
The space above and to the left of the recipient area is now matched
to the space below it, and this is also the space above and on the sides
of a collapsed compose row.