This button will allow users to avoid a distracting red banner across
their screen, while they wait for their sysadmin to do the upgrade
work.
Fixes: #18359
Since we don't process private messages yet, we don't
need to re-render when we receive a new private message
as it doesn't change any data related to recent_topics.
As we change the icon for Group PMs in #18160, the docs related
to it is now outdated. This commit removes the documentation part
that is outdated from status-and-availability section.
Move `get_setup_webhook_message` to
`zerver/lib/webhooks/common.py` so multiple integrations can use this
rather than just those which import `zerver/lib/webhooks/git.py`. Also
added the documentation for this.
Since the invariant we're trying to protect is that every realm has an
active owner, we should check precisely that.
The root bug here, which the parent commit failed to fix properly, is
that we were doing a "greater than" check when we clearly originally
meant a "less than" check -- lower role numbers have more permissions.
Django's default SMTP implementation can raise various exceptions
when trying to send an email. In order to allow Zulip calling code
to catch fewer exceptions to handle any cause of "email not
sent", we translate most of them into EmailNotDeliveredException.
The non-translated exceptions concern the connection with the
SMTP server. They were not merged with the rest to keep some
details about the nature of these.
Tests are implemented in the test_send_email.py module.
* Move the extended documentation of code blocks to a separate page.
* Merge "code playgrounds" documentation to be a section of that page.
* Document copy widget on code blocks.
* This commit changes how we refer to "```python" type syntax for code
blocks. Instead of being called a syntax highlighting label, this is
now referred to as a "language tag", since it serves both syntax
highlighting and playgrounds.
* Remap all the links.
* Advertise this new page in various places that previously did not have a link.
Currently users that try to deploy Zulip through docker has errors
because LDAP group search configuration can't be automated.
Reverts a hunk of f5197518a9.
This will allow us to avoid duplication of array filtering
logic of the form-
`Array.filter((user_id) => !muting.is_user_muted(user_id))` and
`Array.filter((person) => !muting.is_user_muted(person.user_id))`
We want to exclude 1:1 PMs from muted users everywhere
except in `pm-with/<muted_user>`.
This method will help us determine whether we are in such
a narrow.
* We show a "Click here to reveal." hyperlink in the hidden
message dialog for user to click on and read a hidden message.
* The "reveal" action is temporary, in the sense that a revealed
message will again be hidden once the broswer tab reloads or
if the user renarrows.
* When a message is revealed, we make sure to show the sender
of that message, even if it isn't the first message of it's group.
This is because the first message of that message group (which
would have otherwise shown the sender) can still be hidden.
* Reactions and background color after revealing a message are
the same as if the message hadn'e been hidden at all in the
first place.
* We hide the sender and reactions on messages sent by muted
users, and replace the content with a "This message was hidden"
dialog.
* Ideally, we should collapse a series of consequetive
messages sent by muted users into one such dialog, but
that could break the cursor behaviour and `near/<message_id`
links, so we as of now show one dialog per muted message.
* Because we hide the sender, there is a chance of the first
hidden message in a group looking like it was sent by the
author of the message above it. To tackle this, we intentionally
make the hidden message dialog float-left, so that it is clear
that this is a special type of message.
* For context, we still show the timestamp of the message.
* Starring, editing, deleting etc a message still work just like
before.
A further commit will add the ability to reveal a
hidden message.
This new pages accomplishes several interrelated things:
* Documents that Zulip Cloud runs master and how that works.
* Documents policies on how long client apps are expected to support
old releases in our compatibility matrix.
* Removes the 3-years-stale roadmap article.
* Provides a central place to talk about different versions in Zulip.
* Provides a better place to link to from our "you need to upgrade" nag.
This content is not intended to be final, but should be finalized in
the next week or so.
Fixes#18322.
We were not considering the owner role in `sort_role` function
which was leading to improper sorting when sorting the users
list according to role. This commit fixes this bug by considering
role in `sort_role` function.
As discussed in the comment, this is a critical scalability
optimization for organizations with thousands of users.
With substantial comment updates by tabbott.
We also add a check to see if `message_feed_container` is visible,
since it is possible that recent topics could be visible which
was not a possibility when this logic was written.
This page is documentation for our participation in GSoD, which was a
few years ago. We can resurrect it if we participate in the program
again, so there's no need to keep it as a live page.
Linked the Help Center document in places like
- zulip.yaml (/events, /register/, realm/playgrounds,
/realm/playgrounds/{playground_id})
- /help/format-your-message-using-markdown (Linked to make
users reading the markdown code block style, aware of this
feature)
- /templates/settings/playground_settings_admin.hbs (Linked
as a reference to read more about playgrounds before
configuring one)
Also showcase the feature on /features and /for/open-source.
The typeahead suggests a human-readable `pretty_name` for the
`language` field in the add-playgrounds form.
The suggestions are sorted based on the popularity of these
languages.
E.g: A `py` prefix would match with `Python` first before
matching with others like `Python 2.x` based on priority.
The UI makes use of an onclick on the trash icon to call
DELETE /realm/playground/{playground_id}. The id is
extracted from the data attribute `data-playground-id`
set on that element.
The design of the form is similar to the linkifiers page
and is styled similarly.
The introduction text for "Code playgrounds" is improved
with more details and examples.
Also, we can remove the hardcoded playground and the fix
we had previously done to prevent breaking the hardcoded
playground.
This was accidentally removed in 27e4f5da92
as the initial idea was to have another parameter `stream_id`
for stream type messages instead of sending it in this `to` parameter.
Also fixed a description of `to` for `stream` type.
This is a prep refactor, instead of creating Confirmation
object and using `confirmation_url` for generating confirmation
link/url, using `create_confirmation_link` would be a cleaner
approach, also this can help us avoid failing test in case
Confirmation model is changed.
Part of #16359.
Tim Abbott
Riken Shah
Anders Kaseorg
Aman Agrawal
Nikhil Maske
Adam Birds
LoopThrough-i-j
Alex Vandiver
pletinckxc
Alya Abbott
SaikaIslam
Flávio Prado
Abhijeet Prasad Bodas
sahil839
Mateusz Mandera
Sumanth V Rao
Dinesh
shanukun