Seems like the more logical check. Also, the previous code makes it feel
like there is a potential vulnerability where one could get an email change
object in a realm where email changes are disabled, and then open that link
while logged in to a different realm.
While we're at it, remove the unnecessary check that the user is
logged in when clicking the confirmation link; that creates
unnecessary trouble for users who use multiple browsers.
Removes an assert, which at this point is there just for readability, since
the second argument to
get_object_from_key(confirmation_key, Confirmation.EMAIL_CHANGE)
ensures that the returned object is of the correct type.
Add a spinner for when a stream is being created to show that
an operation is being performed, while also disallowing users to
modify the form in the meanwhile.
Commit modified by Brock Whittaker <brock@zulipchat.com>.
Fixes: #5268.
This commit allows clients to register client_gravatar=True, and
then we recognize that flag for message events. If the flag is
True, we will not calculate gravatar URLs and let the clients do
it themselves. (Clients can calculate gravatar URLs based on
emails with just a little bit of code.)
This change prepares us to have the server send avatar_url
of None when somebody wants a gravatar avatar (as opposed
to a user-uploaded one).
Subsequent commits will change behavior on both the server
and client to have this happen. So this commit has no-op
code for now, but it will soon use the fallback-to-gravatar
logic.
This refactoring doesn't change behavior, but it sets us up
to more easily handle a register setting for `client_gravatar`,
which will allow clients to tell us they're going to compute
their own gravatar URLs.
The `client_gravatar` flag already exists in our code, but it
is only used for Django views (users/messages) but not for
Zulip events.
The main change is to move the call to `set_sender_avatar` into
`finalize_payload`, which adds the boolean `client_gravatar`
parameter to that function. And then we update various callers
to supply that flag.
One small performance benefit of this change is that we now
lazily compute the client message payloads in
`event_queue.process_message_event` now, so this will improve
performance if all interested clients have the same value of
`apply_markdown`. But the change here is really preparing us
for the additional boolean parameter, which will cause us to
have four variations of the payload.
The i18n.t function already escapes HTML, so we should avoid
calling jQuery's text() method, which double escapes the HTML.
The symptom reported here was that if you changed your
timezone to something like like America/Mexico_City, you'd
see `/` instead of `/`.
Most callers to the `ui_report` functions clearly call `i18n.t`
on the messages with code like this:
ui_report.success(i18n.t("No changes to save!"), status);
There are some exceptions:
blueslip.js: has really long hard coded messages
reload.js: mostly says "Reloading...", which perhaps we should
translate
settings_account.js: uses helper functions
settings_lab.js: uses local variable
settings_org.js: i18n happens in property_types
ui.js: uses generic_embed_error (unaffected by this change)
Fixes#7280
This commit is easy to revert if we want to tone down errors
to warnings for the short term, while our codepath still does
proper handling for adding users when they come in messages.
This logic used to be in extract_people_from_message(), but
we are deprecating extract_people_from_message(), whereas
the maybe_incr_recipient_count() function has logic that we
want to keep.
This change is the first step in making it so that we load
non-active users at page load time in the webapp.
Before this change, we would reactively handle deactivated
users when we saw them as senders in messages. Subsequent
changes will make it a warning if we see unknown senders
in messages.
Brock Whittaker
Rishi Gupta
sagar-kalra
Angelika Serwa
Tim Abbott
Rhea Parekh
neiljp (Neil Pilgrim)
YJDave
Cynthia Lin
rht
Steve Howell