This is both more correct and also fixes this element having had a
name very similar to message_control_button, which refers to an
element in the message_controls section of a rendered message.
We move compose.html to compose.hbs file while keeping
`#compose` still in `home.html` as a hanger
where append rest of the elements.
This will provide us with two benefits:
* We could share common elements between message_edit_form and
compose.
* We can insert compose directly in any element. We may decide to
do it for recent topics.
Adds a setting UI to list all configured playgrounds
in a realm. The filter functionality can be used to
search playgrounds by its name or language.
Default sort is provided on the 'pygments_language'
field.
Front tests added to maintain server_event_dispatch
coverage. The `settings_playgrounds.js` file is added
to coverage exclusion list since it is majorly UI
based and will be tested using puppeteer tests (in
following commits).
To prevent breaking of the hardcoded playgrounds, we resort
to checking if realm_playgrounds is empty and falling back
to the hard-coded list if so. This logic is removed in the
followup commit which introduces the UI to add a playground.
This is in preparation for moving this code to @zulip/shared for use in
the mobile app, where we will want to use Sentry for reporting errors,
rather than blueslip.
The way I've done this only allows for reporting one type of error
(currently, blueslip.warn), but seeing as we only have one place we
report an error, that seems like something we can fix if we want more
error levels at a later date.
The unicode horizontal ellipsis is visually nicer.
b40e50f295 removed many of these,
by changing the text itself.
This commit handles the remaining few.
Since all the message reactions are inserted before the
add reaction button, if it is the first child, we can safely
remove it.
We changed this from `only-child` to be `first-child` because
we append tooltips as siblings of `reaction_button` but since
they are appended, they are always appended after the `reaction_button`.
Thus, if there were tooltips present the reaction_button won't hide.
This reduces the complexity of our dependency graph.
It also makes sub_store.get parallel to message_store.get.
For both you pass in the relevant id to get the
full validated object.
This breaks an indirect dependency of stream_data
on the channel module.
It's a verbatim code move, apart from the one-line
helper `has_history_for`. It's not totally clear
to me why the original code doesn't call into
`is_complete_for_stream_id` to early-exit, but
figuring that out is outside the scope of my
change.
It's possible that we will eventually just subsume
this tiny module into topic_list once we finish
breaking all dependencies, but we may want to
reuse this for something like Recent Topics
or other similar UIs.
It's also possible that we'll want to rename
stream_topic_history -> stream_topic_history_data
sometime soon, possibly after we clean up its
dependency on message_util soon.
I have added a documentation page for the GitHub Actions integration to
`/integrations/doc/github-actions` with a link to the Zulip GitHub
Actions repository.
Tweaked by tabbott to add cross-links with the main GitHub integration.
I have updated any missing bot avatars after running the tool whilst
creating integrations. These needed adding otherwise the tool creates
them whenever it is ran.
We only update the `.private_messages_header` here since
unread_counts of `.expanded_private_message` are updated
via `pm_list.update_private_messages`.
This fixes the bug of PMs in `.expanded_private_message` having
the same unread count as `private_messages_header`.
Since we rerender the DOM of `.expanded_private_message` every
time we update unread count of PMs, we don't need to manually
update them here. Also, we always keep them on display since
there is no real need to toggle them. They are not visible
when they have 0 unread counts via `.zero_count`.
While rest of the app has ported to the new system of updating
unread_counts `activity` was not ported. This resulted in
unread count in buddy list not being updated when new
PMs arrive.
The series of commits to consolidate CSS classes
for the various unread-count spans across our app
created a bug where the stream_list.js code's selector
starting capturing the unread spans in topic list items.
Suppose you had a stream with these topics:
Foo 10
a 3
b 3
c 4
If another unread came in, you would briefly see:
Foo 11
a 11
b 11
c 11
Now we just use subscription_block to find the
element that we want to tweak.
I remove a convoluted node test here. Part of the
reason the node test was convoluted was that the
original implementation was overly complex. I will
try to re-introduce a simpler test soon, but this
is a bit of an emergency fix.
This reduces our dependency on message_list code (via
message_util), and it makes moving streams/topics and
deleting messages more performant.
For every single message that was being updated or
deleted, the previous code was basically re-computing
lots of things, including having to iterate through
every message in memory to find the messages matching
your topic.
Now everything basically happens in O(1) time.
The only O(N) computation is that we now lazily
re-compute the max message id every time you need it
for typeahead logic, and then we cache it for
subsequent use. The N here is the number of messages
that the particular sender has sent to the particular
stream/topic combination, so it should always be quite
small, except for certain spammy bots.
Once the max has been calculated, the common operation
of adding a message doesn't invalidate our cached
value. We only invalidate the cache on deletes.
The main change that we make here from a data
standpoint is that we just keep track of all
message_ids for all senders. The storage overhead here
should be negligible. By keeping track of our own
messages, we don't have to punt to other code for
update/delete situations.
There is similar code in recent_topics that I think can
be improved in similar ways, and it would allow us to
eliminate functions like this one:
export function get_messages_in_topic(stream_id, topic) {
return message_list.all
.all_messages()
.filter(
(x) =>
x.type === "stream" &&
x.stream_id === stream_id &&
x.topic.toLowerCase() === topic.toLowerCase(),
);
}
We use an inverted color scheme to what we use for unread messages, so
that one's eyes scan these as different from unreads.
We also need to introduce a 1px offset because the border takes up space.
Fixes#17938.
In an effort to use a common class to display unread counts across
the app, we simplify the elements used to show unreads and use a
single `span` with `unread_count` class to do so.
This commit replaces the "echo_data.orig_raw_content" with
"echo_data.raw_content" in "message_edit.js". If the user is editing
a message and it fails, all the edited data used to get lost. Now, the
new edited content appears so that the user does not lose his edited
content.
This bug has been present since the original #12145, where a
refactoring error resulted in using the pre-edit data.
Fixes#18142.
If you have two emojis of the same name, we were
trying to render the non-realm emoji without an
emoji_code, since the condition that I changed
here was erroneously just seeing if the name was
among the realm emojis.
This fix prevents a funny symptom that is reported
in #18135. The symptom is that the non-realm
emoji causes us to render the top-left emoji in
our sprite sheet, since we didn't put emoji_code
into the args.
This doesn't fix the fundamental problem that
having two emojis of the same name is extemely
confusing. Our markdown parser obviously can't
distinguish ":thank_you:" from ":thank_you:". For
the the typeahead case I suppose we could add some
kind of suffix.
So, this fix only simplifies debugging; it doesn't
get to the root of the problem.
We had a mix of the two names, and "video call provider" both feels
more professional and more clear about precisely what it does.
We don't change the API fields, since it doesn't seem worth an API
migration.
Moves documentation about using zoom as video call provider
to /integrations. This documentation was earlier present
at /help/start-a-call and is moved as asked in issue #17588.
Moves documentation about using Big Blue Button as video call
provider to /integrations. This documentation was earlier
present at /help/start-a-call and is moved as asked in issue #17588.
Moves documentation about using jitsi as video call provider
to /integrations. This documentation was earlier present
at /help/start-a-call and is moved as asked in issue #17588.
KaTeX makes use of a "span.overlay" element for the little vector
arrow symbol on top of a `\vec` object. This conflicts with Zulip's
CSS for our overlays, which are divs with the `overlay` CSS class.
While KaTeX may rename their class
(https://github.com/KaTeX/KaTeX/issues/1456), we can work around this
issue by scoping our own overlay CSS and click handlers to
"div.overlay" rather than ".overlay".
Fixes#18068.
This commit adds a helper function named `handle_linkifier_api_error`
to `static/js/settings_linkifiers.js`. As the name suggests, this
function handles the error returned from the API, specifically
for operations on linkifiers (like adding linkifier).
This is a prep commit for `Add setting to edit linkifiers`.
Related issue: #10830.
The main motive to add this helper function is to avoid copying
substantial blocks of code, as it tends to result in someone later
fixing bugs in only one of the two places.
This commit adds a "Create your own" button on the integrations page. It
redirects to "api/integrations-overview" page and is placed by the side
of "Request an Integration" button.
Fixes#7935
There was no proper documentation to guide user to request an integration.
The following changes documents the whole process and links it from the
`/integrations/` page making it visible to the end-user.
Fixes#7935
This reverts commit f81cc16a0f (#17999).
The {{#tr}} helper now includes the functionality that we wanted from
this.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This modal is rendered on demand and inserted into
revoke_invite_modal_holder. We don’t need another hidden copy here,
and having one just causes id conflicts.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We don’t extract either of these strings correctly at present, but I’m
about to replace the entire frontend extraction system.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Previously, when viewing the source of a locally-echoed (pending)
message, if one tried to copy-paste using the copy button, the
"Copied!" status was displayed but the message was not copied.
This was because as we use message ids with a . in then for locally
echoed messages, which ClipboardJS considered an error (invalid
selector).
To solve this
* Remove the data-clipboard-target attribute of copy button.
* Dynamically set target in ClipboardJS config
the based on message id using querySelector
with the message id written with CSS.escape.
Fixes#18053.
* This introduces a new event type `realm_linkifiers` and
a new key for the initial data fetch of the same name.
Newer clients will be expected to use these.
* Backwards compatibility is ensured by changing neither
the current event nor the /register key. The data which
these hold is the same as before, but internally, it is
generated by processing the `realm_linkifiers` data.
We send both the old and the new event types to clients
whenever the linkifiers are changed.
Older clients will simply ignore the new event type, and
vice versa.
* The `realm/filters:GET` endpoint (which returns tuples)
is currently used by none of the official Zulip clients.
This commit replaces it with `realm/linkifiers:GET` which
returns data in the new dictionary format.
TODO: Update the `get_realm_filters` method in the API
bindings, to hit this new URL instead of the old one.
* This also updates the webapp frontend to use the newer
events and keys.
This commit fixes the issue of error message not getting
displayed when the `Full name` field, in bots settings, is given
a duplicate name of an already created bot with the same name.
We were closing the modal each time whether the request is
successful or not. Hence, we now close the modal only
when the request is successful and error is displayed on
the modal otherwise.
Fixes#18091.
Previously, you had to request the `stream` event type in order to get
the stream-level parameters; this was a bad design in part because the
`subscription` event type has similar data and is preferred by most
clients.
So we move these to the `realm` object. We also add the maximum topic
length, as an adjacent parameter.
While changing this, we also fix these to better match the names of
similar API parameters.
Previously, clicking the codeblock copy button also
triggered the compose box to open.
This is because of the fact that ClipBoard.js lacks the
ability to stopPropogate the event when clicked.
Rectified by explicitly defining the copy click event
within `is_clickable_message_element`, which disallows
the triggering of reply box.
Effectively a workaround for
https://github.com/zenorocha/clipboard.js/pull/475.
Fixes#17861.
We'll get the same result by letting jQuery stringify these; so
explicit JSON encoding here is likely to just encourage contributors
to cargo-cult JSON-encode strings in the future.
* Don't require strings to be unnecessarily JSON-encoded.
* Use check_capped_string rather than custom code for length checks.
* Update frontend to pass the right parameters.
With a much simplified populate_data_for_request design suggested by
Anders; we only support a handful of data types, all of which are
correctly encoded automatically by jQuery.
Fixes part of #18035.
The comment explains the reasoning, but this should make it a lot
easier for users to visually focus on the menu items in the sidebar.
Changed by tabbott to use the same width as the right sidebar itself.
Inspired by #17169.
As zulip is tranfering its tooltip to tippy the
tooltips for subs sort options are tranfered to
use tippy instead of title. Placement is bottom.
Refer https://github.com/zulip/zulip/pull/17434.
If we are changing_hash, it means `window.location.hash` is the
new_hash, so we don't want to change hash further now.
This used to create a loop of changing hashes as we used to close
and open overlays if `hash_before_overlay` was an overlay.
Fixes#18011
This gives us information that browser hash has already changed
and now we are just showing the correct overlay. This can help us
make informative decision that if we want to change the hash back
to the last hash after closing the overlay or not.
With a tweak from tabbott to not use tippy on the entire message
content; this was a correct port of the apparent old bootstrap-tooltip
logic; however, that logic didn't actually work, so we just had
`title` behavior.
Given that showing a tooltip when hovering over the entire message
body feels wrong, we preserve the weird title behavior (which also
feels a bit off, but less so).
Since we need to use number values for these breakpoints directly
in some places, having `px` values exported for them is not
great as we have to write weird looking code to convert it into
number.
Long labels like "Deactivate xyz" or "Delete xyz" can
be confusing for translators and it can also create bad
strings that can end with like 4 long words in German.
It is better to have the simple options like "Confirm"
and "Cancel". This commit fixes this issue by changing
the text to "Confirm" in their respective template files.
Fixes#17926.
Long labels like "Unstar messages" can be confusing for
translators and it can also create bad strings that can
end with like 4 long words in German. It is better to
have the simple options like "Confirm" and "Cancel".
This commit fixes this issue by changing such text
to "Confirm" as default in confirm_dialog_modal.
Part of #17926.
Tippyjs automatically places it to bottom.
NOTE: placement of tooltip is changed from 'bottom' to `auto`.
Custom css was set here to avoid tooltip being partially hidden
on small screens. This change automatically takes care of it
by showing the tooltip on right side of message_reaction on
small screens if it is partially hidden from the left or
vice versa.
We no longer need to add_tooltip_to_left_panel_row since
tippyjs.delegate will automatically do that for us.
Tippyjs automatically places it to left on small widths and bottom
for large widhts.
We don't want to import tippyjs module here
along with its dependencies, so we just copied
over tippyjs defaults here. They should be
work fine for /stats page even if we decide to change
defaults for the app in tippyjs and forget to do
it here.
Hiding and instantly showing a modal causes a race condition in
Bootstrap since `hide` and `show` calls are asynchronous.
See https://getbootstrap.com/docs/4.0/components/modal/#methods
Instead, use `overlays.open_modal` which prevents background
mouse events when a modal is present.
This prevents a user from maybe accidentally clicking on another deactivate
button while a modal is present. This also prevents a black screen
caused due to this race condition.
And since a user can't click on the button while the modal is present,
it doesn't make sense to hide it before showing it.
So, remove the `hide` call.
Fixes#17297
This color picker did not hide even after exiting stream settings.
Fix by adding logic to auto-close any open color pickers when closing
stream settings.
Tweaked by tabbott to use the existing on-close handler, which is
important if one clicks outside the modal or otherwise navigates
another way.
Fixes#17334.
Commit d84727ce7f (#17970) slightly
decreased the apparent size on some platforms depending on which font
was in use before, and some users complained that it was a bit hard to
read. Based on experiments with multiple platforms and monitors and
resolutions, this appears to be a good compromise that increases the
rendered height without increasing the width more than necessary.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
When the user's full name is long, the full name + `(you)`
in the buddy list starts to truncate, but when hover, the
tooltip displays the full name but not `(you)`.
This commit fixes this by adding `(you)` in the tooltip.
"Narrow to topic" option do exactly the same thing as
clicking the topic name does. So therefore decided to
remove that option from the popover. This commit removes
all the code related to .narrow_to_topic including it's
template code, on click event and a function used for it.
Fixes#18027.
We should disable the stream message retention dropdown for owners
of realm with limited plans. The behavior is correct in other
places, will also just explain the behavior in other places -
For limited plans-
1. Owners can see the dropdown in stream creation form but others
cannot, and in stream privacy modal, the modal is visible to all.
But the modal is disabled in all cases since the realm is on
limited plan.
For standard plans -
1. Owners can see and edit the dropdown in both stream creation
form and stream privacy modal. Non-owners cannot see the modal
in stream creation form but they can see the dropdown in stream
privacy modal and it will be disabled.
Thus, the only change in this commit is to disable the dropdown
in the stream creation form for owners and in limited plan realms.
The other behavior mentioned above was already there.
There is a bug where invite button is not enabled again after sending
invite is failed, but it is enabled on successful completion of invite.
I am not able to figure out why it is behaving differently in success and
error cases, even when the code to enable button is in complete() function
and it is called in both the cases.
But, I can confirm that adding .button('reset') fixes this bug as button
is disabled using the .button('loading') call and this is according to the
bootstrap docs only. But the bootstrap docs mention that the .button(string)
method has been removed in v4.0 as mentioned here
https://getbootstrap.com/docs/3.4/javascript/.
So, as we would want to avoid using depereceated or removed methods, this
commit simply changes the code to disable the button and set the loading
text using simple jquery and this also solves the above mentioned bug.
There was a bug where invite users link is shown in the Invitations
section of settings overlay, irrespective if the user is allowed to
invite or not based on the realm settings. So here we just use the
'can_invite_others_to_realm' field of page_params, that was added in
previous commit itself to hide the link accordingly.
Also added the code in server_events_dispatch.js for this field.
Though it doesn't do live update when the overlay is opened similar
to other policies like create_stream_policy, but it ensures that the
visibility of link is correct if the overlay is opened after the
settings has changed.
We should probably do the complete live update in future of the
elements related to such realm settings.
This commit replaces invite_by_admins_policy, which was a bool field,
with a new enum field invite_by_realm_policy.
Though the final goal is to add moderators and full members option
using COMMON_POLICY_TYPES, but this will be done in a separate
commit to make this easy for review.
Our aim is to use this library to remove use of bootstrap-tooltip
for showing popovers and tooltips. This will remove our
dependency on bootstrap for showing tooltips. Thus, bootstrap
can be upgrade more independently.
Since the base hash for org settings and user settings are
different (organization and settings), the hashchange module
gets confused that we are going from one overlay to other.
A reproducer for this flow is to visit the organization "Bots" page,
click on your own profile as the owner of a bot, and then click "Edit
profile" from there.
So, we fix this by making an exception for this particular case
in the module.
Fixes part of #18011.
Displays "Several people are typing..." when more than 3 users
are typing to avoid typing notifications in streams being too noisy.
A side effect is it shows the same message in pms too.
Muted users are stored in a map with key as user ID and
the value as the timestamp of muting.
Names can be easily fetched from existing functions
in `people.js` and hence not stored.
Within 9c9d74fd6d, page_params.is_realm_admin was incorrectly
stated while building popover which lead to admin actions not
being populated within popover.
This is so beacuse `is_realm_admin` is not a valid object
of page_params.
Rectified by renaming `is_realm_admin` to `is_admin`.
This is a prep commit for implementing mute users feature, which
renames this function to be more specific. This function cannot be
used as-is for user mutes, because for user-muted messages, we always
want to rerender the message list, irrespective of what
`excludes_muted_users` is.
In muting_ui.js, we also remove an unnecessary conditional that is
already handled by update_topic_muting_and_rerender itself.
Previously, the recent-topics view did not update when the webapp
received `muted_topics` events.
The final state was correct **only** on the client which was used to
mute/unmute the topic, because we update the UI even before sending
the request to the server to mute/unmute the topic.
This commit fixes that by rerendering the recent-topics table when the
client receives `muted_topics` events. While doing so can be
expensive, it is likely unavoidable, because we may want to even
remove the topic from the recent-topics table, and we don't know
exactly which topic was affected (we just get an updated list of all
muted topics from the event).
Even though rerendering is expensive, it should not affect the user
experience, because a rerender will be trriggered only in the clients
which did not do the (un)muting (and hence, the user was probably not
interacting with these clients when the event was received). The
`last_topic_update` variable makes sure that this is the case.
Previously, on clicking the "bell" icon from a recent
topics topic row, two click handlers were triggered-
1. The one for the bell in the recent-topics topic
row.
2. The one for the bell in the floating recipient bar.
This is intended to be triggered only when the user
clicks on the bell icon in the floating recipient
bar to mute a topic, but this was triggered on
clicking the recent-topics topic row bell too,
because it wasn't specific and we use the same
HTML class for both the bells.
Because both these click handlers were triggered,
the webapp sent back-to-back duplicate requests to
the server to mute the topic, which caused the sever
to throw "HTTP 400: Topic already muted" error.
This commit fixes this by making the recipient bar
click handler more specific, so that it is triggered
only when the recipient bar bell icon is clicked.
There is also the issue that the recipient bar bell
icon only allows a user to mute the topic, not unmute.
So, when someone mutes a topic, and then clicks on
the recipient bar bell icon, the webapp sends a
request to mute the topic again (not to unmute),
leading to the same error as above.
This commit does not fix that. See #15223.
Added a `include_current_item` parameter to dropdown_list_widget
which behaves as follows:
- Has a default value of `true`, which includes the current value
in the dropdown list items.
- If set to false, it excludes the current value from dropdown
list items.
This fixes a bug I introduced when merging
86eccfd20f, by not using the "new topic
button" trigger.
It would probably be wise to replace that "trigger" system with just
passing actual options, as it's pretty confusing.
This commit adds an option to create new topic in stream
popovers. Then adds a click listener on them which triggers
the compose start function with the stream specified.
Fixes#13480.
Fixes#2507.
We use GIPHY web SDK to create popover containing GIFs in a
grid format. Simply clicking on the GIFs will insert the GIF in the compose
box.
We add GIPHY logo to compose box action icons which opens the GIPHY
picker popover containing GIFs with "Powered by GIPHY"
attribution.
This change should make live-update code less brittle,
or at least less cumbersome.
Instead of having to re-compute calculated fields for
every change to a stream message, we now just compute
the fields right before we render stream settings UI.
This is mostly a pure code move.
In passing I remove an unneeded call to
update_calculated_fields in the dispatch code,
plus some tests that don't need them.
This maps pageup/pagedown/home/end to close compose when used in empty
compose box, matching the existing behavior for the Up/Down arrow keys.
Currently, these keys do nothing when used in an empty compose box.
Typically, a user intends to navigate when pressing these keys (and
with empty compose, they can't be expecting to navigate within the
compose box), so it makes sense to map them to navigate the message
feed just to save users from needing to hit `Esc` in these contexts.
Fixes#17917
The `copy_handler` function that this shortcut calls is not useful
unless the body of a Zulip message is selected, so we shouldn't try
running it in other situations.
This logic correctly prevents the hotkeys implemented below it from
being active when "Recent topics" is open. We expect to change some
parts of that soon (see #17685), but in any case, we should always
return false in the hotkey code when we don't process a key, so that
default browser behavior works.
This fixes browser shortcuts like Ctrl+C, Ctrl+V, etc. when recent
topics is loaded.
This bug was introduced in 1eafb1d8b3.
Thanks to ganpa3 for noticing this bug.
This sorts the members imported within each individual declaration; we
use import/order for sorting multiple declarations.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
"Copy link to message" is both a clearer label, and also more likely
to be what someone is looking for. (It also avoids adding the
"conversation" terminology to the product).
The previous label was also somewhat inaccurate, because it actually links
to a specific message in the conversation.
From the commit history, this typo has always been there; because it
had the same priority as the `opacity: 0.5` for that element,
it can be nondeterministic whether the bug appeared.
Fixes#17476.
This reverts commit 9c6d8d9d81 (#16916).
This feature has known bugs, and also wants some design changes to
make it customizable like linkifiers, so we’re retargeting this to
post-4.x.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For filter values which don't exist or are invalid in some
way, we return false to show user that there are no messages
in the filter user is trying to render. Our previous behaviour
was to show all the messages and ignore the filter which
isn't good.
The popup that appears when you mute a topic is a bit hard to read,
since nothing makes the topic and stream names jump out from the rest
of the paragraph. Fix this by using bold around the stream/topic and
also cutting a bunch of unnecessary verbiage.
Tweaked by tabbott to further simplify the language.
This reverts commit a00f5dd90e (#17801).
That commit introduced a regression in the portico pages as described
in commit 85b3157b47. Since that fix
introduced a regression of its own, we need to revert both commits for
now.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This reverts commit 85b3157b47.
This broke the × button on Blueslip alert boxes, because @extend does
not work across different PostCSS compilation units.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The start time of the last password change was the wrong time to use,
because we could start a password change, start another request,
finish the password change, and then observe that the other request
failed due to the password change.
We could use the end time, but a counter is more robust to
sub-millisecond race conditions.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
* We shouldn't use "Search" when we mean "Filter". Filter is correct
here, since we are just showing a subset of what's otherwise shown,
and won't find anything that's older (or whatever).
* The stream/topic wording was unnecessary; the things we're filtering
are topics (E.g. "Filter users" might look at name/email, and is the
right label, not "Filter name/email").
There can be several cases when we don't require a reset button
with the dropdown_list_widget.
Hence, Added an abstraction for dropdown_list_widget that
renders the button only if it's corresponding text is passed.
This commits adds on to 9884226f, which was added to
handle a rare race condition that occurs when the
session hash is not updated by the backend during the
password change process.
It handles a variant race situation where the request was initiated
before/during the password change event and completed after it was
completed. Hence, forcing the page to redirect to the login page.
In a00f5dd90e, we needed to move the
`alert-box` styles from alerts.css to be visible in portico pages.
However, when doing so, we incorrectly moved all of alerts.css, which
also has styles for `alert` and` alert-error` designed to make it
convenient to include hidden elements for potential errors in the
webapp settings UIs directly in the HTML template (and then use
show/hide to manage them).
We fix this by moving just the alert-box scope to the common
components.css module, which is designed as the place for styles
shared between the webapp and portico pages.
This fixes an issue where the error messages for wrong password and
the like were invisible :(.
This commit make compose_ui.autosize_textarea handle most of the autosize
logic of the textarea. It audits for any logic that is trying to do
autosize manually and replace it with compose_ui.autosize_textarea.
This allows to have better check for when the textarea is autosized.
Mainly done this so that we can have a check on #compose-textarea when
to autosize and when not to, thus helping to have all the logic in only
one function.
We now unconditionally enable backgroung events when 'hidden.bs.modal'
event is triggered on closing of modal. We do not need to handle them
separateley for closing modal by close_modal, data-dismiss or escape.
We handle this by single handler for modals in settings and subscription
overlay.
Fixes#16688.
This commit changes the code to not remove the modal element from DOM
after closing the modal for the deactivation stream modal and stream
privacy modal.
This is a prep commit for enabling background mouse events
unconditionally using 'hidden.bs.modal', because removing element
using '.remove' remove all events attached to it and this will also
remove the 'hidden.bs.modal' event which we do not want.
This remove behavior is inconsistent as we remove some of the modals
but do not remove some, so for now we are not removing the modal
after closing but it is anyway removed before opening a modal to handle
case of having two elements of same id and avoids any bugs.
This behavior of when to remove the element from DOM and when to not
remove needs to be discussed and may be modified in future.
We show a modal as a warning when unsubscribing a private stream
because it is a irreversible action and one cannot re-subscribe
tovit until added by other member of stream.
Fixes#9254.
This commit adds "close-modal-btn" class to cancel button in
the modal and cross icon.
We do this change because we would add a modal for unsubscribing
from private stream in further commit using confirm_dialog module.
We would need to avoid the unexpected closing of stream settings
on closing the modal which can be done by calling 'e.stopPropagation'
to prevent propagating of events in other elements.
Thus, adding this class will mean that the handler used for stream
privacy modal for this same task will be used for unsubscribe modal
also.
This commit adds 'close-modal-btn' class to cancel button and cross icon
in the deactivation stream modal.
This change is a prep commit for enabling background events on
'hidden.bs.modal' event. As we would enable background events in furhter
commit using the 'hidden.bs.modal' event, we would need to remove the
'hide.bs.modal' event of deactivation_stream_modal which removes the
element from DOM.
When we remove this event we would need a e.stopPropagation call to avoid
unexpected closing of stream settings which was not a problem previously
because the element was being removed from DOM before actual closing of
modal.
So instead of adding a different handler, we can use the handler used
for stream privacy modal here by adding this new class.
This commit renames the class of both cancel button and the cross
icon to close-modal-btn.
This change is a prep commit for enabling background events on
'hidden.bs.modal' event. As we would enable background events in
furhter commit using the 'hidden.bs.modal' event, we would need to
remove the 'hide.bs.modal' event of deactivation_stream_modal which
removes the modal element from DOM.
When we remove this we would need a e.stopPropagation call to avoid
unexpected closing of subscription settings, which was not a problem
before as the element was removed from DOM before the actual closing
of modal.
So instead of adding a separate `e.stopPropagation' call, we can use
the same handler that is being used for stream privacy modal and this
is the reason the class name of cancel button of privacy modal is
being changed.
We do not remove the stream row instantly from the subscribed list in
subscription overlay when unsubscribing from public streams in most
of the cases but we do so when unsubscribing using hotkey.
This commit makes it consistent by not removing the stream row on
unsubscribing using hotkey.
We also not remove the 'active' class as streams settings is still
open in the right seciton and this behavior is also consistent with
the other ways of unsubscribing.
Note that this behavior is only for public streams, we remove the
stream row in case the stream is private, as user cannot
resubscribe himself and this behavior is consistent across all ways
of unsubscribing.
- Rectifies broken label tag having a misleading 'for' attribute.
- Removed 'name' attribute from unlabelled span tag.
- Removed label expression from DropdownListWidget to built an,
abstraction for control group only.
Fixes#17311.
Restructured dropdown_list_widget template to unwrap label tag
from the control group, hence defaulting the edit_bot
dropdown items to their original text size.
We now consistently set the PM counts for the right
sidebar toggle in unread_ui, similar to what we
do for the overall counts in the left sidebar toggle.
(Use a thin window to see the code in action.)
This breaks a dependency cycle.
In passing I improve the test coverage for the
actual job that pm_list still does (updating its
own total count in the "Private Messages" section).
For messages which we don't have stored locally, we don't update
our data structures. This was actually our behaviour before
59e5f2d8fc, which introduced this
bug.
Not doing this caused a major bug where we ran into errors
moving messages for topics for which we didn't have all
the messages available.
This data structure has never been one that we actually render into
the DOM; instead, its role is to support clicking into view that
contain muted streams and topics quickly.
This downgrade makes that situation much more explicit, and is also
useful refactoring to help simpify the upcoming changes in #16746.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit fixes the 'Your account' settings page to show
correct role of organization owner. Previously it was
incorrectly displayed as administrator.
Commit message tweaked by sahil839.
I lift this function out of message_store to
break some dependencies, and it's also more
consistent with the rest of the codebase:
alert_words.process_message
pm_conversations.process_message
recent_topics.process_messages
recent_senders.process_message_for_senders
We can do further cleanup to make these names
consistent (and possibly have them all work in
bulk), but that's out of the scope of the current PR.
We move the message_store.add_message_metadata function
(and all its dependencies) into a new module called
message_helper and rename the function to process_new_message.
(It does a bit more than adding message metadata, such
as updating our message store.)
We also have a "protected" interface now in message_store,
so that message_helper can access the message store:
update_message_cache
get_cached_message
Because update_message_cache is identical to
the former create_mock_message, we just renamed it
in the tests.
Most callers should use these functions:
message_helper.process_new_message (setting)
message_store.get (getting)
It's slightly annoying that the setter interface
is in a different module than the getter interface,
but that's how you break a bunch of dependencies.
We also extract the tiny message_user_ids class:
user_ids()
add_user_ids()
All the code moves here are pretty trivial, and
the code that was moved maintains 100% line
coverage.
The module name `message_helper` is not ideal, but it's a single
function and it'll save time to just do the topology change now and
leave thinking through the right name to later.
This function should be named similarly to the well-named
end_inline_topic_edit; previously the main hint that this was the
inline code path was just that the recipient_row was the parameter.
Before this we did not have remove event in server_events_dispatch.js
for the user group delete event even though server had. This was
leading to blueslip errors. Extracted the logic which was used in
success() of channel.del for user_groups into the remove case in
server_events_dispatch. Also removed the redundant reload call as
we already do that in server events.
This is a mostly verbatim extraction.
I re-phrased one line of code to work around a lint
false alarm. (Look for `preamble` in the diff.)
There are about 8 lines missing coverage here, so
the new module might be a good candidate to get
100% line coverage on.
Before this change, you would need to remove 74
edges from our dependency graph to make it
acyclic. Now it's 72.
This change does not impact the overall complexity
of our dependency graph (at least in terms of the
number of edges that we would need to remove to get
a tree), but it does clarify the picture a bit.
Rename few functions referencing the "CHOICE" field to
instead use the new "SELECT" name. This is done so that they
can be reused in "SELECT_MULTIPLE" field.
When a user entered an invalid character (whitespace or characters not
present in a name), the cleaned-up array, and hence the query,
would be empty which resulted in an error.
Fixes#17542
We were loading filters from localstorage after rendering the
filters block which caused the incorrect icons being displayed
for filters.
Since usually recent_topics renders a couple times when it
is loaded directly and the filters were being loaded as part of
show_selected_filters after we rendered recent_topics filters,
it meant the correct filters were being displayed in the
second render.
But, when user loads any other narrow directly when Zulip is loaded,
and opens recent_topics, recent_topics is only rendered once,
hence the bug gets noticed.
Fixes#17496
Extend our markdown system to support mentioning of users
by id also. Following these changes, it would be possible
to mention users with @**|user_id** and silently mention
using @_**|user_id**.
Main intention for extending the mention syntax is to make
it convenient for bots to mention a users using their ids. It
is to be noted that previous syntax are also supported.
Documentation tweaked by tabbott for better readability.
The changes were tested manually in development server, and also
by adding some new backend and frontend tests.
Fixes: #17487.
We add support to shorten links and test their shortening in
well-organized, clean manner that makes it trivial to extend the
GitHub approach for GitLab and perhaps other services.
We only shorten basic types of GitHub links (issue, PR, commit) that
fit a set of simple common patterns; the default behaviour of Autolink
is kept for everything else.
Logic added in frontend and backend Markdown Processor is identical.
This makes easy to extend the logic for other services like GitLab.
Fixes#11895.
Aman Agrawal
Sumanth V Rao
Wesley Aptekar-Cassels
Abhijeet Prasad Bodas
Vishnu KS
Tim Abbott
Steve Howell
Adam Birds
Anders Kaseorg
Signior-X
m-e-l-u-h-a-n
akshatdalton
Siddharth Asthana
majordwarf
tushar912
Aryan Shridhar
Rutvi Sharma
TylerPham2000
guptaprakhariitr
Nikhil Maske
Ganesh Pawar
yasiruRathnayaka97
Riken Shah
sahil839
Dinesh
Megamind
aryanshridhar
Kenny
Mandeep Singh
Mateusz Mandera
Palash Singh Raghuwanshi
yashika
YashRE42
jagansivam28
PIG208
Gaurav Pandey
Nishant Mittal