The emoji dir is present in the data from our export tool. This was
added in 468afe4840.
This comment hasn't been updated since
c4b886d8ae, so probably we just forgot to
refresh it when custom emoji export was added.
Fixes warnings like “ResourceWarning: unclosed file <_io.FileIO
name='/srv/zulip/var/044e5d44-87aa-4c43-abbb-28a144fa6654/test-backend/run_1238680/worker_0/test_uploads/files/thumbnail/2/1e/jmUuDhQC8WlaSRCuc0zQyx7D/img.tif/100x75.webp'
mode='rb' closefd=True>” with warnings enabled.
deque(…, 0) is an efficient way to consume an iterator documented at
https://docs.python.org/3/library/itertools.html#itertools-recipes
under consume.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Previously, if someone changed the font-size or line height
settings to some value other than the legacy values, we set
dense_mode to False if it was True. This commit changes the
code to require clients to pass dense_mode as False in such
cases and raise an error otherwise.
We should flush the cache after commiting changes to DB to
make sure that the cache does not contain stale data when
updating multiple settings in a single request.
Instead of the PUSH_NOTIFICATIONS_BOUNCER_URL and
SUBMIT_USAGE_STATISTICS settings, we want servers to configure
individual ZULIP_SERVICE_* settings, while maintaining backward
compatibility with the old settings. Thus, if all the new
ZULIP_SERVICE_* are at their default False value, but the legacy
settings are activated, they need to be translated in computed_settings
to the modern way.
This is a small optimization to avoid DB queries if the bot owner
is not changed.
This also helps in avoiding showing the error message in UI if
anything other than the owner is updated for a deactivated bot.
Ideally if the bot owner is not changed, the bot_owner_id field
should not be passed in the request, but we would handle that
later given this is anyways a small nice optimization and we
follow this pattern at other places as well in the API.
Adds a header to the section of changes notes about new and
deprecated narrow filters, so that it's easier to directly
link to the relevant content in the construct a narrow article
from the main API changelog and endpoint documentation.
The HookPress plugin has been unavailable since July 2019, so it
doesn't make sense to continue supporting these events in the
WordPress webhook integration.
Tornado ≥ 5 uses AsyncIOLoop and AsyncIOMainLoop automatically when
appropriate. Fixes “DeprecationWarning: make_current is deprecated;
start the event loop first” with warnings enabled.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In an interleaved view when composing a message we fade messages
which the user is not replying to, to reduce the chance they send
a message to a recipient they didn't intend to.
Also, it reduces the visual/cognitive processing required
to figure out where their message is going to go.
But, it's not necessarily clear to users that what the
fading means, so this commit adds a one-time compose banner
to explain what's going on the first time this comes up.
Fixes part of #29076.
In a non interleaved view when composing a message to another
conversation we fade messages which the user is not replying to,
to reduce the chance they send a message to a recipient they didn't
intend to. Also, it reduces the visual/cognitive processing required
to figure out where their message is going to go.
But, it's not necessarily clear to users that what the
fading means, so this commit adds a one-time compose banner
to explain what's going on the first time this comes up.
Fixes part of #29076.
A new table is created to track which path_id attachments are images,
and for those their metadata, and which thumbnails have been created.
Using path_id as the effective primary key lets us ignore if the
attachment is archived or not, saving some foreign key messes.
A new worker is added to observe events when rows are added to this
table, and to generate and store thumbnails for those images in
differing sizes and formats.
SHA1PasswordHasher will be removed in Django 5.1. MD5PasswordHasher
will remain for the purpose of speeding up tests.
Followup to commit ac5161f439 (#29620).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Imports (including conversions from Slack, Hipchat, etc) do not write
the `.original` of the file (nor the still versions, for animations),
only the thumbnailed (and possibly animated) version. Looking for
`.original` would thus fail, and overwrite the (working) emoji with
the "?" and disable it.
In the event that we do not find the `.original`, fall back to the
bytes from the non-`.original`, to handle these import cases.
This commit improves the assert statements to verify
that the table name is not "usermessage' instead of
verifying that table name doesn't include a substring
"usermessage".
This prep commit will help to avoid assertion error when
importing "onboardingusermessage" table.
Earlier, the export tool was logging a warning:
"??? NO DATA EXPORTED FOR TABLE zerver_onboardingusermessage!!!"
This bug was due to not configuring a Config object for
'OnboardingUserMessage' in 'get_realm_config()'.
This commit fixes the bug to export the table properly.
This is needed for the command to work in docker-zulip, where the zulip
user may not have write permissions to the parent directory of the
secrets file. By default, crudini creates a temporary file, which makes
the command fail under those conditions.
With --inplace, the secret file gets written to directly without
creation of temporary files.
Adds server and web app support for processing the new `with`
search operator.
Fixes part of #21505.
Co-authored-by: roanster007 <rohan.gudimetla07@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
bulk fetch query of UserPfrofile against which
user_ids are validated, instead of looping
over user_ids and fetchingeach UserPfrofile resulting
in O(n) queries.
We use a truncated SHA256 of the id and a server-side secret to make
emoji have non-guessable filenames, while also making collisions
unlikely.
We also adjust the Slack import to use the same SHA-based name,
instead of taking the same name as it had in Slack.
We thumbnail and serve emoji with the same format as they were
uploaded. However, we preserved the original extension, which might
mismatch with the provided content-type.
Limit the content-type to a subset which is both (a) an image format
we can thumbnail, and (b) a media format which is widely-enough
supported that we are willing to provide it to all browsers. This
prevents uploading a `.tiff` emoji, for instance.
Based on this limited content-type, we then reverse to find the
reasonable extension to use when storing it. This is particularly
important because the local file storage uses the file extension to
choose what content-type to re-serve the emoji as.
This does nothing for existing emoji, which may have odd or missing
file extensions.
Aside from updating the doc structure, this commit
also rephrases step 4 to make it read better. The
list of supported events in step 5 is also removed.
Part of #29592.
We use the already existing server level setting to only allow
settings to be set to system groups, not a named user defined
group as well, in production. But we allow to settings to be set
to any named or anonymous user group in tests and development server.
"can_mention_group" setting can be set to user defined groups
because some of the realms already do that in production.
The existing server level setting is also renamed to make it clear
that both user defined groups and anonymous groups are not allowed
if that setting is set to False.
This commit also changes the error message to be consistent for the
case when a setting cannot be set to user defined groups as per
server level and setting and when a particular setting cannot be set
to user defined groups due to the configuration of that particular
setting. For this we add a new class SystemGroupRequiredError in
exceptions.py so that we need not re-write the error message in
multiple places.
Besides "RE:" and "FWD:", "AW:" (from German "Antwort" for answer) is
another common prefix in email subjects. Let email_mirror automatically
remove it as well.
When using the sub-expression purely for filtering, and not for
accessing the value in the resultset, .alias() is potentially faster
since it does not pull the value in as well.
This commit adds an 'transaction.atomic' decorator to the
'add_subscriptions_backend' view thus making the db operations
within the view atomic and helps to avoid race between events sent.
In tests where we make POST requests to this view, we have
wrapped the API calls with a transaction.atomic() context
manager. It helps us with NOT rolling back the entire test
transaction due to error responses.
In 'test_subs' we were making POST request to add
subscrption using 'self.api_post'.
This commit updates the code to use the test helper
function 'common_subscribe_to_streams' instead.
This prep commit will also help us to avoid adding
'transaction.atomic' context manager to these API calls
individually in the case of error response in the next commit.
Previously the bot sent bot commands whenever an undefined message
was sent by the user. This commit intends to fix the problem so that
the bot will only respond to the first message it does not understand
and not reply to any future undefined messages.
Fixes part of #30049.
The reply given by welcome bot when it does not understand a message,
sent by the user is changed, so that the bot is more clear to the user.
Fixes part of #30049.
The previous message that welcome bot sent with
the bot commands has been removed in order to be more
clear and concise to the user. Previously weclome bot
also sent bot commands in intial message, this commit
intends to remove those commands.
Fixes part of #30049.
migrate the following endpoints from @has_request_variables
to @typed_endpoint :
- upgrade()
- remote_realm_upgrade()
- upgrade_page()
- remote_server_upgrade()
Updates the instructions for `{settings_tab|invitations}` to work
like the deactivated users link, and updates the one article that
currently uses it: `help/invite-new-users.md`.
Using an if block when {!event-filtering-additional-feature.md!}
is used implied that we plan to have this in all webhook doc .md
files.
But, it actually makes sense to only use this macro when the
webhook integration actually supports event filtering.
In a2ef1d7e93, we made changes so
that when you send a message, your view jumps to the conversation
where you sent it.
For some users it was an improvement, few reported that it
disrupts their workflows.
This prep commit adds a setting which will be used to allow users
to decide whether to automatically go to conversation where they
sent a message.
This commit updates the Welcome Bot's initial
direct message content.
We inform about the tracked onboarding messages
via direct message only if it exists.
Fixes#30051.
This commit renames the "Huddle" Django model class to
"DirectMessageGroup", while maintaining the same table --
"zerver_huddle".
Fixes part of #28640.
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.
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
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>
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.