Currently we show the PMs list align with the Private
messages header that make them no difference between
header and its elements list and it may confuse the user
to notice that PMs list is expanded or not. We follow
a trend of shifting the child elements slightly towards
right from the parent header element in stream-topic list.
Maintaining this trend we fix this issue similarly, the
PMs list is shifted by 10px towards the right.
Replacing the group PMs icon with "fa fa-group" icon
drops the color class "fraction_present" logic. As there
is no more use of fraction_present class this commit
cleanups its all existence from the codebase.
It is difficult to distinguish group PMs from 1:1 PMs, so to
improve the UI it is better to show different icon for group
PMs. Here we are using fa fa-group icon for group PMs.
Fixes#18069.
As of now, editing a widget doesn't update the rendered content.
It's important to ensure that existing votes or options added later on
don't get deleted when rendered.
This seems more complex than it's worth.
For now, we just prevent edits to widgets.
This commit makes the UI clearer that editing widgets isn't allowed.
See also:
https://github.com/zulip/zulip/issues/14229https://github.com/zulip/zulip/issues/14799Fixes#17156
Introduce a new class "table-sticky-headers" in the settings
and organisation settings HTML table tags and it is used
to make the table headers fix at the top. This commit also
add the background-color and hover properties to the
settings and organisation settings table to make them look
similar to the recent_topics_table.
Currently, when there are some old starred messages
in a topic, it is possible that some of them won't be
unstarred on doing "Unstar all messages in topic".
This happens when those messages haven't been fetched
yet from the server, and we have no way to verify if
they actually belong to the topic.
This commit fixes that by changing this mechanism to
first fetch all starred messages in the topic from
the server, and then send their IDs back to the backend
to unstar them.
While doing this, we assume that the user does not
have more than 1000 starred messages in that topic.
Note that, we still depend on the local data to
decide whether or not the "Unstar all messages in
topic" option should be shown in the topic popover.
A method similar to the above cannot be used here, because
making server requests before opening the popover
could visually slow down the popover opening.
Using local data for the topic popover would probably
not be a big problem, because users would want to
unstar all messages in a topic probably after noticing
that there are a lot of them, meaning there was at least
one starred message from that topic which was already
fetched, which is sufficient for us to conclude that
we need to show the option in the topic popover.
Fixes#17790
The dialog now shows `stream > topic` instead of
just the topic.
This creates a new tiny widget for this purpose,
which can be reused in other places too.
The `undefined` case is probably very unlikely, but
if the `stream_id` is bad, after the user confirms,
the request will fail on the backend, which could
confuse the user, since there will be no changes to
the starred messages in view.
So, we don't open the confirmation dialog at all in
such cases.
There is no need to store this field (and make sure
that it's the same in both the message_list and
message_list_data objects) on message_list objects,
because we can anyways access it easily with
`message_list.data.excludes_muted_topics`, and storing
it just on the data object seems more intuitive.
This also simplifies the constructor for the `MessageList`
class.
We hide a conversation from the top-left corner PM list if
it is-
* A 1:1 PM where the other user has been muted, or
* Huddle where all users have been muted.
This commit adds code for live updating the role field of person
object on receiving role change event from server and thus enables
live update of role in users list of settings overlay.
This commit adds code to live update page_params.is_moderator and
person.is_moderator on receiving role change event.
The code for changing role to moderator and from moderator to any
other role was added in previous commit.
This commit modifies the code to show "Moderator" correctly for
realm moderators.
As, we show role using settings_config.user_role_values object and
the same is used for showing options in changing role dropdown, this
commit also adds the moderator option in that dropdown and thus allows
the user to change role to moderator and from moderator to any other
role from frontend.
But the code for live updating page_params.is_moderator and
person.is_moderator will be in further commit.
This commit adds 'admins and moderators' option in frontend for
invite_to_realm_policy.
The logic for moderator for checking whether user is allowed to invite
others or not was added in previous commit as we use common helper
user_has_permission for all policies.
But the test user_can_invite_others_to_relam is updated for including
moderator role in this commit.
Since, we now have role value in the person objects sent from server
we can directly use that to set the value of dropdown used for
changing user role, instead of using multiple if-else conditions
for checking is_admin, is_owner, etc.
Since, we now get role value in person objects sent from server, we
can simply user user_role_map to display role in different places
instead of having multiple if-else conditions to check flags like
is_admin, is_guest, etc.
There were some changes that were lost/added by mistake
during a rebase of #17707 after #18154 was merged.
Fixes the GIF icon being hidden / displayed incorrectly
with respect to the settings.
These changes were originally part of
67527a2517 but
were lost during the rebase.
This commit adds 'user_can_create_streams' helper which is
used to check whether user can create streams or not and
replaces all the instances of 'page_params.can_create_streams'.
This change helps us to remove the complex logic of updating
'page_params.can_create_streams' for 'realm_update' event in
'server_events_dispatch.js', as we will always get the updated
values from the added helper for checking whether the users can
create streams or not.
This commit adds 'user_can_subscribe_other_users' helper in
settings_data.js amd this helper will replaced all the
instances of page_params.can_subscribe_other_users.
We also remove the incorrect code in server_events_dispatch.js
where we were updating page_params.can_invite_to_stream which
is actually not used in other parts of code and instead of it
page_params.can_subscribe_other_users is used to check whether
user is allowed to subscribe others or not. This code was
added in 272ed9068.
Though this could have been done in a different commit, but as
we are adding the code to use the correct updated value in this
commit only, this has been fixed here.
There is also no need of adding that complex logic to update the
correct 'page_params.can_subscribe_other_users' field on
'realm_update' event, as we are using user_can_subscribe_other_users
helper and thus we always use the updated values to check whether
the user is allowed to subscribe others or not.
This commit adds 'user_can_invite_others_to_realm' function
in settings_data.js which replaces all the instances of
'page_params.can_invite_others_to_realm'.
This change makes it possible to remove the complex logic of
updating 'page_params.can_invite_others_to_realm' on
'realm_update' event as we are using above added helper instead
of using page_params object and thus we always use the updated
value to check whether user can invite others or not.
The 'user_has_permission' helper will be used by functions added
for create_stream_policy and invite_to_stream_policy in further
commits and will help in avoiding code duplication.
This commit replaces different objects - create_stream_policy_values,
invite_to_realm_policy_values and invite_to_stream_policy_values,
with a single object common_policy_values.
Though invite_to_realm_policy do not use other fields of objects like
description, order, etc. but we can keep it as it is for now as we
would separate this setting from "Are invitations required...."
dropdown and these fields will be used then.
This is a prep commit for commits that will add helper functions in
settings_data for these policies replacing the usage of page_params
object.
When notifications panel is open at the top, the buddy list and
streams-filter container gets truncated due to max-height exceeding
the necessary value. The commit fixes the issue by subtracting the
panels height when it is visible. The logic to do so is already
present, but we need to ensure that we trigger the full resize code
when we get into this situation.
Fixes: #18221Fixes: #17823
This prevents the regex from requiring multiple spaces between
adjacent alert words by using lookahead and lookbehind (rather than
the before/after checks each needing to eat a whitespace character) so
that consecutive alert words (if any) can be highlighted.
With a frontend test covering adjacent corner cases by tabbott.
Fixes#17320
setTimeout doesn't work all the time especially when trying to
hide and display the popover at once, like when you press
to open giphy popover in message edit form while another giphy
popover is open from the compose box.
MutationObserver works reliably, hence we choose to use it
instead.
We use an icon which is more clear for what it stands for.
Increase allowed size of message-control-buttons slightly so
that they are clearly visible. This is more important for
GIF icon to be visible properly than any other icon here.
In fe66aef0ad, this call to
blueslip.fatal was ported incorrectly to `throw new Error` despite the
latter not supporting the extra_data parameter.
We address this by just doing blueslip logging with the extra data first.
Fixes#18273.
This function requires two arguments; checking for the event being
undefined is code leftover from a previous implementation.
Fixes an issue reported in #18273.
For unknown reasons, 6f7b973d3b
introduced an invalid semi-duplicate call to ui_report.error that
passed the wrong number of parameters.
We should just call `ui_report.error`, which already had logic to
handle the distinction between 40x and 50x errors.
Fixes an issue reported in #18273.
Fixes#18052
When we select a draft with no stream, topic of
drafts gets disappeared. This commit fixes this bug.
In the restore_draft function of drafts.js, we were
explicitly removing the topic of the draft when the stream is
not set.
This was bit reluctant to me, like why we're removing
the topic when the stream is not set. After discussing this on
the Zulip organization chat, I came to know that all code for
drafts is added in commit 1929cc5190.
And as this is a big commit, this microcode would not have
gotten much scrutiny and might get missed.
So removing this feature is not an issue. Also, it may be a bad
design decision to delete topic when we restore drafts. So we should
remove this feature.
When we select a draft with no topic, we typically got navigated to an
empty narrow, because the topic field was empty. Rather than
navigating to a view that will show "Nothing's been sent here yet!",
we should not navigate at all.
Initially, in the restore_draft function of the drafts.js
we were only checking that stream is empty or not,
now we also check for the topic, and if both are set,
we navigate to related context; otherwise, we don't navigate.
Previously, we used to do a kind of "local echo"
whenever the user muted/unmuted a topic. Meaning,
we used to do most of the UI update work before making
the API call to mute the topic, instead of after
receiving the `muted_topics` event. This behavior
has been so since the beginning of time
(b4b6fa14d3) and isn't ideal because:
1. If the request fails on the backend, the UI
could end up in an incorrect state.
2. Adds code complexity.
3. Makes it difficult to catch bugs related to
live-update (like the one fixed by
f725711ff2).
4. Isn't consistent with other parts of the
codebase, which do the UI update while handling
events.
This commit makes it so that all the UI update
work is done only after recieving the `muted_topics`
event.
The only possible issue with this strategy could
be users sending another duplicate request in the small
time span before receiving the event. But that isn't
a big problem, because all requests involved here are
idempotent, and the worst that can happen is a HTTP 400.
This commit adds support for a `None` option in the dropdown menu
of `Notification sound`. When this option is selected, no audible
notification is sent to the user.
`None` will appear as the first option in the dropdown menu, since
this is not categorized as a playable audio.
This new option is added so that folks can disable audio notifications
without losing their other notification configuration (like for PMs, mentions).
Necessary test case is added for this new option.
Fixes#16090.
Item field is added to the pill items, this is done to utilize
it wherever possible, to distinguish between diffrent types
of pill items(stream|user_groups|users).
It is also a preparatory commit to support expanding of stream
and user group pills.
Since it was introduced in 5ce0db9f43,
we've had alt text for the hotspots illustration with an invalid
translation tag.
Fix this by removing the alt text, since the image has no functional
effect and so the right answer should it fail to load or the user is
visually impaired is to ignore it.
Deduplicate control buttons by re-using the
compose_control_buttons.
A link to `help` overlay was added to `message_edit_form`
as a part of this process.
This fixes a bug that when video provider is set to `Jitsi`
from `none` in organization settings while message_edit_form
is open, the video icon is not displayed since
it was not present in the message_edit_form DOM even if
compose.update_video_chat_button_display tries to display it.
It is fixed since the `.video_link` element is always present
in DOM of `message_edit_form` now.
We convert the following elements to use a class instead of
id for accessing them across the codebase:
* markdown_preview
* undo_markdown_preview
* markdown_preview_spinner
* message_edit_content
* preview_content
Converted them together since changes to one impacted the other in
some modules like click_handlers.
Also, added a function in rows to get `message_row`.
We use `.compose_upload_file` across compose and message_edit_form
for file upload icon. This will help us share common code between
`compose` and `message_edit_form`.
In both compose and `message_edit_form` we use `file_input`
class to identify the file `input` element. This will help
to more easily share common elements between compose and message_edit.
Since we can have multiple instances of `message_edit_form`, it
makes sense to have it as a class.
We track the message_edit_form by setting an id to
`form` element dependent on message_id.
This commit makes it so that muted users never appear
in the right sidebar buddy list, filter text or not.
The hiding is done in the frontend only, and we still
recieve presence data from the server as before, so
no extra work is required on unmuting someone, other
than to rerender the user list.
Long term if we find that there are too many muted users,
we may want to optimize how we send presence data, but
that is unlikely to happen.
The other less extreme option is to gray out muted users,
but that cannot be done because it would conflict
with the graying out we do for non-recipients when the
compose box is open.
This makes the naming more intuitive and gives us a
single place to add more conditions on filtering
user_ids, with the current motivation being filtering
muted users, the logic for which will be added in further
commits.
This is a direct code move which puts all the functions
related to `user_id` lists near the bottom of the file.
This will make the file slightly easier to read.
Long labels like "Yes, Unsubscribe this stream" 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".
Fixes#17926.
Previously, realm emojis can override default emojis in emoji-picker,
if the user sets an exisitng emoji name to his/her custom emoji.
For clear understanding--
If a user sets an realm emoji with name `smile`, this leads to the
newly realm emoji override the existing default emoji `smile`.
To address such behaviour, Added a warning modal which requires
the user confirmation before overriding the default emoji.
Fixes#16913.
Moved `admin_user_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Fixes#18227
Moved `admin_user_group_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_tab` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder instead.
Moved `admin_settings_modals` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_profile_field_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_linkifier_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_invites_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder instead.
Moved `admin_human_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_export_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_emoji_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_default_stream_list` template to `/templates/settings/`
folder as earlier, it was inaccurately placed within the `/templates`
folder and should have been within the `/templates/settings` folder
instead.
Moved `admin_bot_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and `settings` folder is specifically for storing administrative
UI templates.
This involves in two changes for styling.
1. The alert class is moved from alert.css to app_components.css as this
class serves nothing but to default .alert elements to be hidden. This
is only required in the webapp but not portico pages (where .alert
elements are preferred to be shown by default).
2. The import statement for alert.css is moved from app.js to common.js,
so that both the webapp and the portico pages can share the styles. This
will be fine to share the styles as .alert-display, .alert-animations,
.alert-box are more specific then .alert and they use nested class to
define styles for inner elements.
Undoes #17936 properly.
This improves the UX of creating a stream for atleast 1000+ users
realm by showing the the stream creation form much faster than
before.
Search, user addition, scrolling worked smoothly on 15k+
users realm as tested on dev setup.
Also, simplebar is used to replace the default scrollbar.
Fixes#16805
When moving a topic within a stream that is deactivated, the stream
may not be present in stream_data. Avoid throwing an exception in
this situation by leaving stream_name as undefined; existing logic
seems to anticipate that as a possibility, so we don't need a broader
change.
Longer term, we may want to just send to clients basic data about
archived streams that the user has access to.
Fixes: #17271
This commit adds a helper function: `mute_or_unmute_topic`
in `click_handlers.js` to mute and unmute a topic. This function
is called when a user mutes/unmutes a topic from its recipient bar
or `recent topics`.
This is a prep commit for `Allow unmuting of a topic from its recipient bar`.
Related issue: #15223.
The bug happens in the case when the topic name is not set and the
user clicks on always_visible_topic_edit button results into unusual
behaviour of the always_visible_topic_edit button. To fix this, this
commit fix the behaviour by hiding and showing the
always_visible_topic_edit button in the appropiate situations, at the
same time we hide/show similar buttons.
Fixes#17813.
This allows us to use different "Show password" and "Hide password"
for these labels, which is more consistent with how other products
implement this.
It also lets us delete N duplicate copies of these strings in the HTML.
The "Save failed" standard text is appropriate for many of our
settings, but for changing one's password, we can go with just the
"Wrong password" part provided by the server.
The show password feature is a functionality to
toggle the visibility of the password fields in forms
so that one can check if they have entered the correct
password or not. We implement this using an eye icon
toggling which converts input field type from password
to text and vice-versa.
Fixes part of #17301.
This allows us to hide tooltips automatically when the
parent container is hidden while tooltip is active.
In an overlay, when a tooltip is active and `esc` is pressed,
the tooltip will remain active without this commit.
This has side effects of some properties of parent applying to
tooltips if property is directly set to `div`. Through manual testing,
only area where this was found was fixed.
We destroy the tooltips for which `reference` was either removed
from DOM or is hidden.
We only need to do this for tooltips
contained in simplebar containers for which tooltips can
overflow the boundary of the simplebar container.
There are 4 approaches we could have done this:
1. Asked tippy.js maintainers to do this for us.
In https://github.com/atomiks/tippyjs/issues/938 the
maintainer said that it is the responsibility of
the user to do so.
2. Tracked whenever we update the DOM for such elements and hide
tooltips when we were hiding the `reference` elements. This had
various problems like it is hard trigger events when certain elements have
been removed from DOM when `html()` method is used to render
new content.
3. Run an `optimized` periodic job to destroy tooltips when
`reference` elements are hidden. This isn't a good method to
do this since it sucks power and adds latency.
4. Use a `MutationObserver` on the parent element and watch
for changes. This methods seems to work well with no bad
side effects. We use this approach.
Instead of inserting tooltip inside `body`, we directly insert
it inside the `reference` element. This helps us to automatically
hide the tooltip when we hide the `reference` element.
This avoids the bug of tooltip persisting when the message reaction
is removed while the tooltip is active.
To reproduce:
* React 👍 to a message.
* Hover over the reaction.
* Press `+` from keyboard.
You will see reaction tooltip persisting while the reaction is hidden,
also "Add emoji" icon is displayed with tooltip.
Doing the same for elements which are inside a simplebar container
and for which tooltips can span outside the simplebar container,
makes the tooltips not visible or cut at the edges of simplebar
container since simplebar containers have overflow set to `hidden`.
This is something that cannot fixed as per
https://github.com/Grsmto/simplebar/issues/347
So, for simplebar contained elements we insert the tooltip to
`body`.
`reference` element: Element for which tooltip is displayed.
Since the "mute users" feature isn't complete yet,
this UI is shown only in development setups.
Ideally we should have had this commit after the whole
feature was completed and merged, but doing so makes it
difficult to test and merge subparts of the feature one by
one (which is a better workflow, while we still decide what
exactly we want this feature to do).
This commit adds a new button in the user info popover
to mute or unmute the user, and uses a confirmation
dialog while muting, because muting a user accidently can lead
to the muter losing out on a lot of information.
TODOs when making this UI visible in production-
1. Make a /help page and link to it from the confirmation
dialog and the API docs.
This reverses the policy that was set, but incompletely enforced, by
commit 951514dd7d. The self-closing tag
syntax is clearer, more consistent, simpler to parse, compatible with
XML, preferred by Prettier, and (most importantly now) required by
FormatJS.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This extra commit adds support for creating user group pills
in cases that do not use typeahead like, pasting the group
name, copying it from the user group pill.
This completes the remaining work required to support
addition of all members of a user groups to stream.
Fixes#15186.
We update the pills typeahead logic to also include user group
results and pass the "user_group" key in `opts` to enable this
option for Add subscriber form.
The changes includes:
* Exporting the `query_matches_name_description` function, to
deduplicate the typeahead `matcher` logic.
* Creating a `people.is_known_user` function, to deduplicate
the typeahead `sorter` logic.
* Add a new `user_group_pill.js`, to allow adding user group
pills in input widgets that support pills.
This has been tested manually as well as by adding some new
node tests.
This commit removes`typeahead_helper.sort_recipientbox_typeahead`
which was introduced in 639ec9380a
for the private message recipient box when it used to accept comma
separated text input for recipients. All it doew was cleaning away
invalid recipients from string, like:
"a, , b" was cleaned to [a, b].
This can be now removed because it was now used only in
pill_typeahead.setup code path, and the pills code already handles
invalid cases by filtering out all falsy (invalid) recipients.
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.
Tim Abbott
Nikhil Maske
Ganesh Pawar
Aman Agrawal
Abhijeet Prasad Bodas
sahil839
Anders Kaseorg
Megamind
ligmitz
im-adithya
Adam Birds
100RABHpy
akshatdalton
Nyior
m-e-l-u-h-a-n
nikhilmaske-2001
aryanshridhar
PIG208
scjess
Mateusz Mandera
Sumanth V Rao
Wesley Aptekar-Cassels
ryanreh99
Vishnu KS
Steve Howell
Signior-X
Siddharth Asthana
majordwarf
tushar912
Aryan Shridhar
Rutvi Sharma
TylerPham2000
guptaprakhariitr
yasiruRathnayaka97
Riken Shah
Dinesh
Kenny