Clarifies that the alert is shown if the current time displayed by
the time zone configured on the user's device differs from the
time displayed for the users's profile time zone.
Removes incorrectly having web_suggest_update_timezone as a separate
field returned by the POST /register response. It will only be a
field in the user_settings and realm_user_settings_defaults objects.
Refers to the setting as the "profile time zone" to help clarify
that this user setting is used for displaying the user's local
time to other users.
Adds links to the help center article about this user setting.
More consistently notes the format of the string that's being
returned is an IANA identifer of the time zone.
This implied by its name that users could have more than one key.
They cannot, currently; make the code clearer by switching to the
explicit column access.
Only prefetching `realm` and `bot_owner` means that the cache values
filled by this process differ from the cache values that would be
stored on a cache miss -- leading to extra database queries for those
objects.
Use the same `base_get_user_queryset()` to ensure we get the same
related prefetches.
These were likely mistakenly left off of 6098c2cebe, leading to
1847086044 likely not switching to `base_get_user_queryset` for this
function because the list differed.
These two endpoints make up ~85% of requests to Zulip servers; since
presence is also a performance-critical endpoint, having them share
the same cache increases how hot it stays in memcached, in addition to
making the presence endpoint faster.
This comes at the very slightly cost of one extra field. Checks
for the `is_bot` column are switched to the equivalent `bot_type`
check, since the columns are slightly duplicative, and we can get away
with only checking bot_type.
Tornado requests try hard to not make SQL queries -- and if they're
necessary, to minimize the number of them. Specifically, both session
objects and user objects are cached in memcached, and we expect that
both of them will have been filled there by Django before any requests
are made to Tornado.
In the event that memcached is flushed, or data is otherwise evicted,
we perform two database queries -- one for the session, and one for
the user. However, the *width* of the latter query has grown
significantly over time, as the Realm object grew more fields, and
recently with the addition of role groups, which require multiple
joins each. This leads to a query which is over 12k of text long, and
results in 319 columns. In the event of a memcached flush, this can
result in a *significant* amount of SQL traffic, as nearly every
active Tornado request will make that query.
We do not wish to narrow the default query for Django; we instead tag
the request in the REST wrapper, and use that to use a much narrower
user cache entry. That narrower cache entry is filled before the
queue is created in Django; we also use it to explicitly set the log
data, so the second "half" of the continued Tornado request does not
need to fetch any user data either when writing its log line.
Because they use different cache keys, this only affects the
session-based `/json/events` endpoint, which caches by user-id; the
`/api/v1/events` endpoint, which uses an API-key cache, keeps its wide
user object. The former is 50% of the total request volume, whereas
the latter is only 2%, so adding an additional cache for it is
unnecessary complexity.
The previous logic over-wrote the requester with the old value if it
had been set to anything in the new request, which it never could have
been. This logic likely stems from confusion in the hasattr
introduced in `89394fc1ebee`.
Always copy the `requester_for_logs` from the first half of the
request.
1ea2f188ce mistakenly introduced a `_rate_limit` member of the
request, which was dutifully transcribed in 3f9a5e1e17. However,
`_rate_limit` was never read from, nor written to -- `_ratelimit` (with
no middle `_`) was the dict that contained rate-limiting data. This
`_ratelimit` dict was later renamed to the `_ratelimits_applied` list,
in e86cfbdbd7, which became the `ratelimits_applied` request note
field in 03693cd27e.
Remove the entirely unused `rate_limit` note, and properly copy the
`ratelimits_applied` data into the new request.
This commit updates the traditional url of a channel-topic narrow
to topic permalink upon arrival of new message in the narrow, by
using the `with` operator on it.
The requirement for this change arises when we navigate to an
empty topic. Since it has no messages yet, we fallback to the
traditional channel-topic links. However, when a new message
arrives to this empty topic, we want the url to live update to
a permalink of the narrow.
This is done as an effort to make sure channel-topic narrows
always contain `with` term.
Clicking the "Channel color" label in the stream settings did not
open the color picker, unlike other settings where clicking the label
triggers the same action as clicking the value. This commit adds an
event listener to the label that triggers the associated button's
click event, ensuring consistent behavior across all settings.
Fixes#33446.
Before submitting a candidate custom linkifier, the web app now
validates it locally using `python_to_js_linkifier`. This prevents
invalid linkifiers from reaching the server, as the server may
support some linkifiers that the web app does not.
To achieve this, `python_to_js_linkifier` is exported from
`linkifiers.ts`, and a try-catch block is added in
`settings_linkifiers.ts`. If the web-app does not support
the linkifier, the app displays an error message
and prevents submission.
Fixes:#33238
Now that we introduced an URL for serving permalinks redirecting to
docs in #33444, the docs_url mechanism is no longer needed, as we can
have a URL that's safe to hard-code in register_server.py.
The HostnameAlreadyInUseBouncerError.docs_url has been merged in main
briefly enough, that this should be safe to remove.
This is a regrettable adjustment, necessary for how certain
browsers (especially Safari on both iOS and macOS) present a
larger, non-adjustable gap between the list marker and the list
item's text.
This commit updates the topic links obtained from clicking
the topics in the left sidebar, recent view and inbox, and
those obtained from "Copy link to topic" to use the new
topic permalinks.
Fixes part of #21505.
Avoids displaying the upgrade banner in upgrade_tip_widget.hbs and attachments stats banner in 'Uploaded files' UI when the user is logged in as a guest. This ensures that guest users do not see upgrade-related links that do not apply to them and cause 404 errors.
Fixes#20630.
This commit adds typing indicators for message editing in stream
as well as in dm, if the send typing notification
for corresponding is enabled.
Based on earlier work in #28585.
Co-authored-by: Rohan Gudimetla <rohan.gudimetla07@gmail.com>
Fixes#25719.
The comment was incorrectly placed and misleadingly suggested that
`long_term_idle` subscribers were excluded from `subscription_query`,
whereas they were not.
Earlier, it was not possible to configure the user that the forwarded
email will be sent by.
This commit updates the 'Generate channel email address' modal to
make sender configurable when generating channel email.
Fixes#31566.
Previously, the button to generate channel email address was removed
for users without post permissions. Now, it is disabled and includes
a tooltip: "You do not have permission to post in this channel."
'can_access_stream_email' function determines who can
generate email to send message in a channel.
Earlier, the function was not considering channel post policy.
So, a user which doesn't have permission to post in
a channel as per channel post policy could generate channel email.
This commit makes sure to not show the "Generate email address"
button in such cases.
We show the button only if the current user or any of the bots
they control has the permission to post in the channel.
Fixes part of #31566.
- Offer more hand-holding at the start.
- Clean up dev environment setup steps.
- Move joining CZO later in the process.
- Move feedback section to feature suggestions page.
- Drop other non-coding info, as it exists elsewhere.
Previously, when description for a channel -- either during its
creating or when we change its description contained a topic
permalink (through #-mention), then it was not rendered. This
is because of lack of authorization to access the channel.
This is fixed by passing the acting_user through the methods
which update or add the description, so that permissions
of the acting_user could be used to determine whether to
render the #-mention in stream description or not.
Previously when system bots used to `#-mention` a private
channel's topics in cases like moving messages of a private
channel, then the #-mentions were not rendered by the
markdown. This was because the system bots did not have
authorization to mention these channels.
This is fixed by passing down an `acting_user` parameter
in code paths involving sending these move message
notifications so that permission of acting_user to mention
the topic is verified for rendering the markdown, rather
than that of the system bot.
