The `unless` step errors out if /usr/bin/psql does not exist at
first evaluation time -- protect that with a `test -f` check, and
protect the actual `createuser` with a dependency on `postgresql-client`.
To work around `Zulip::Safepackage` not actually being safe to
instantiate more than once, we move the instantiation of
`Package[postgresql-client]` into a class which can be safely
included one or more times.
Clarifies that the `all` field in the `op: "add"` event is only
relevant for the `"read"` message flag, and that it will be false
for all other specified flags in theses events.
Deprecates the `all` field in the `op: "remove"` event and document
that it is false for all specified flags.
Updates the deprecated `operation` field description and makes
a few other small revisions to the event text for clarity and
accuracy.
When changing name of users, the name was updated corectly
in the "Users", "Deactivated users" and "Bots" list but
it removed the "<a>" element, used to open the user
popover, and instead changed it to plain text.
This commit updates the code to just update the text inside
"<a>" tag so that the popover can still be opened by clicking
on the name.
We refactor the tests to check if a multi word query's result is
correctly highlighted (multi word highlighting fixed in
e2c23b656e).
The test case was already present, but the setup was not correct, and
has been corrected now to safeguard against regression in the future.
This commit adds a dropdown and custom input element to set the
`realm_jitsi_server_url` when the video call provider is Jitsi. This
allows organization administrators to add a custom Jitsi server as the
organization's video call provider.
Fixes#17914.
Co-authored-by: Gaurav Pandey <gauravguitarrocks@gmail.com>
This commit adds a `jitsi_server_url` field to the Realm model, which
will be used to save the URL of the custom Jitsi Meet server. In
the database, `None` will encode the server-level default. We can't
readily use `None` in the API, as it could be confused with "field not
sent". Therefore, we will use the string "default" for this purpose.
We have also introduced `server_jitsi_server_url` in the `/register`
API. This will be used to display the server's default Jitsi server
URL in the settings UI.
The existing `jitsi_server_url` will now be calculated as
`realm_jitsi_server_url || server_jitsi_server_url`.
Fixes a part of #17914.
Co-authored-by: Gaurav Pandey <gauravguitarrocks@gmail.com>
Since `settings_org.update_dependent_subsettings` handles settings whose
value and state depend on other elements and video chat provider settings
is an independent setting moving it out of update_dependent_subsettings.
This test has been flaking for a couple months, and it hasn't felt
worth it for anyone to debug, so we should disable or delete it.
I chose deletion, since I don't think this settings panel is a
high-value place for end-to-end testing.
This does not adjust any of the padding from a float-based era.
It's entirely possible that the status-preview area especially
deserves some further tuning.
With no existing class to reach this selector, this change
introduces a new `.inline-status-emoji` class on the Handlebars
template and in the main Zulip CSS file.
Because of the inline styling in the message sender row, this
specific instance of a status emoji needs to be presented as
an inline flex: that keeps the avatar image layout clean, while
also introducing the `align-self: center` vertical positioning
of the status emoji adjacent the username, which is itself a
bare text node.
This change paves the way to update how actual status emoji are
presented in sidebars, pills, etc., care of flexboxes, which
is previewed here by the inclusion of the `align-self` property.
Previously, the text on the warning banner when the user is not allowed
to direct message is "Direct messages are disabled in this organization.".
While the text on the warning banner when the user is not allowed to
send message to stream is "You do not have permission to post in this
stream". These wording is inconsistent with each other and we should
change it to keep them consistent and aligned with each other.
Fixes: #21896.
After the changes in #25572, users were no longer able to start a direct
message with bots if the organization disabled direct messages. However,
we should allow direct messages to bots regardless of the policy because
it's a useful interface for users to interact with various classes of
bots.
user_ids_string_to_ids_array was also modified to prevent cases where
the split function returned an array of [0] rather than [] when dealing
with a empty id string of "".
Fixes: #21896.
To make the date change in recipient header more smooth, we
update it with throttled scroll event. This can cause some
performance regressions on slow computers during scrolling but
nothing I can notice even with 6x CPU slowdown on Intel i7 on mac.
This is an alternative to #25163 since implementing it seems harder
than expected. The date changing animation cannot be made smooth without
serious structural changes to how messages are rendered.
So that the user can still select and copy text from the body of the
linkifier rows. It might be helpful if we extend this behavior to other
draggable rows, like those for custom profile fields settings.
Fixes#26798
The unique index on `(user_id, message_id)` that is the
`zerver_usermessage` table is rather specific, and even the PostgreSQL
extended statistics are not enough for it to realize there is a
correlation between the `realm_id` in the message table and the
`user_id` in the usermessage table. This means that adding the
`realm_id` limit when there is a join to `zerver_usermessage` flips
the query plan from a nested loop of unique usermessage index-only
scan, with an index scan of the messages pkey -- to a parallel hash
join of the messages limit with a index scan of just the user_id limit
on usermessages. It thinks this is necessary because it thinks that
the `realm_id` limit may remove a large number of messages from the
usermessage set -- which is totally untrue.
Remove the `realm_id` limit if we have a usermessage join.
`make_query_highlighter` called `highlight_with_escaping_and_regex`
once for each word in the phrase, due to which only 1 word searches
could be highlighted. For example searching for `two wo` resulted
in no highlighting at all in `two words`.
One call per word in the phrase was also redundant since the called
function can handle a multi word query. So now the entire phrase is
passed to the called function just once.
Earlier mid word parts matching with the search query were also
highlighted (made bold), but since actual matching for showing search
suggestions is based on prefix matching, this highlighting logic is
now made to be in sync with the search suggestions matching logic.
Alex Vandiver
evykassirer
Lauryn Menard
Sahil Batra
N-Shar-ma
Anders Kaseorg
Hemant Umre
Tim Abbott
Karl Stolley
Karl Stolley
Aman Agrawal
David Rosa
Joelute
Zixuan James Li
Daniil Fadeev