We add a '?' icon besides the "GIPHY integration" label of
giphy settings dropdown.
The icon links to readthedocs page for setting up giphy API
key when api key is not set, and it points to help center
article of GIFs when the api key is added.
The extracted logic is in linkifier.js.
We have decided to name it linkifier.js instead of realm_linkifier.js
because in future when we will add stream-level linkifiers, we'll
likely want them to be managed by this same file.
We change the width of upgrade-tip to be max-content
such that it matches with the other elements in
settings overlay like dropdown, which are not of full
width.
We fix the code to show giphy icon live update only if the
updated setting is not disabled and API key has been added.
Though the dropdown is disabled,the setting can still be
changed using API, so this change is necessary.
Previously, we were not checking whether API key is there or
not and icon was shown on live update even if API key was
not there and then it went off on reload.
The command:
codespell --skip='./locale,*.svg,./docs/translating,postgresql.conf.template.erb,.*fixtures,./yarn.lock,./docs/THIRDPARTY,./tools/setup/emoji/emoji_names.py,./tools/setup/emoji/emoji_map.json,./zerver/management/data/unified_reactions.json' --ignore-words=codespell_ignore_words.txt .
The content of codespell_ignore_words:
```
te
ans
pullrequest
ist
cros
wit
nwe
circularly
ned
ba
ressemble
ser
sur
hel
fpr
alls
nd
ot
```
Previously, when a user hits 'Enter' key within a input
field it incorrectly triggers the dropdown_list_widget's
reset button.
This is because the reset button had the default type attribute of
'submit' which triggers the click event binded to it. Fixed it by
explicitly defining it's type attribute to be a button.
The inconsistent style between these three buttons looked bad.
We have to take some care with the "Starred messages" and "Edit" ones,
to make sure they live-update properly.
Previously, when the user presses 'Enter' within a input
field while keyboard focus in is in the topic edit textbox
it incorrectly opened the dropdown list widget.
This is because the dropdown button had the default type attribute of
'submit' which triggers the click event binded to it. Fix it by
explicitly defining it's type attribute to be a button.
Fixes#18415
Previously, the focus event tends to skip the first
element within the dropdown list when the user presses
the down arrow.
Added a stopPropogation event for keydown handler within
dropdown_list_widget which propoerly binds the focus
event to the dropdown list items.
We record Git details about the merge-base with upstream branches in
the zulip-git-version file, if the upstream repository is available.
Note that the first Git upgrade after merging the parent commit will
not include the merge-base details, since the upstream repository will
not have been available.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Previously, the "Move topic" option was only displayed to organization
administrators, despite the new setting making who can move topics
between streams configurable.
Making this migration requires us to remove the text on the previous
"Admin actions" divider, and just make it an hrule, to avoid confusing
normal users, while still providing a hint that moving topics is a
non-personal operation.
We also change the ordering for consistency.
This commit adds the dropdown in 'Stream settings' section of organization
permissions page to control who can move messages between streams and
also hides the stream-edit UI in message-edit form accordingly.
Fixes#14499.
This also handles a few other places missed earlier like
narrow headings, beacuse they use the same function.
We already rerender the PM list for events, so there's no
need to do anything special when someone is muted/unmuted.
`people.get_full_names` is now only used in the settings pages
while creating ListWidgets etc, so we add a new test for
it to ensure coverage.
Directly rendering the default view on pressing `escape` key will lead
to default_view being rendered on the current window hash. So, we set
empty hash to load default view and let hashchange handle it.
This fixes a bug introduced in
59a45d3521.
Long ago, we changed Zulip to inspect server-provided topic history in
our compose and search typeahead modules, but did not trigger a query
to the server to fetch data.
This could result in confusing experiences where someone thought that
a topic doesn't exist that just isn't present in recent history.
Once we merge this, we may want to adjust the messaging in typeahead
to advertise that the first option will create a new topic, since this
change may make it feel more like creating topics is a heavyweight
operation.
Fixes#9857.
We’re getting unexplained exceptions from URL.createObjectURL in
Firefox 88 (#18374); contain them to this function.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Previously, the hook to save drafts when closing the compose box was a
focusout on #compose-textarea. This mostly worked, and was essentially
invisible to users (because the animation to notify you about saved
drafts was in the close_compose_ui widget that is hidden), but you'd
end up seeing the tooltip appear (in the wrong place) if you closed
the compose box immediately after sending a message with Tab+Enter.
The correct fix is for the drafts hook to be just before we start
clearing compose box state, inside hide_box.
This was difficult to catch in a development environment, since one
doesn't use that flow with "Enter sends" enabled.
We were apparently not using the ListWidget API for replacing the
content of a widget without removing the whole thing from the DOM and
replacing it.
Unless ListWidget has unexpected bugs, this should have the exact same
result as the previous logic, with much a nicer user experience.
We use styling same as that of the number shown for overflow
(e.g "+3") which has a gray background.
To keep these avatars up-to-date, we need to rerender the
recent topics view after receiving a `muted_users` event.
Also update the user documentation to mention this detail.
We deliberately avoid mentioning "recent topics" because
this applies to mobile too.
This seems more consistent with what users would expect; Recent topics
may be a better default view in general, but if a user has picked
another default view, we should use that where the default view is
desired.
The default label for empty narrows depends on whether it's a
stream/topic narrow or a PMs narrow.
We leave some default text in compose.hbs for reply label
because it take some time for the js to display the
correct label.
The browser seems to autofill the `Name` field of the add-playground
form. Most likely this behavior is a result of value of the `name`
input field being `name`, causing the browser do to something weird
here. This name is now changed to `playground_name`.
The old logic, inline in the compose area, has produced a very weird
effect where the buttons would move to fit the notification, ever
since design changes to use the full bottom row space.
We address this by just using a Tippy tooltip instead.
Share code between `safe_full_names` and `get_display_full_names`
functions, and rename `safe_full_names` to `get_full_names_for_poll`,
because that was the only place where this was used earlier.
This also has the nice side effect of showing "Muted user" instead
of the muted username in poll results.
Instead of changing the hash to the default_view hash, we render
the default_view directly in case of recent topics and all messages.
This also fixes the bug that user is unable to go back in
browser window history.
We don't want to rely on browser hash to check if RT is visible
because soon we want to display default_view without any hash
and RT may or may not be visible in that hash.
Active stream's hash look like this - `#streams/1/announce`
Since the stream_id is present where typically hash section
is for all other hashes, get_current_hash_section should return
the same result.
The screenshot generating mechanism doesn't work for newrelic and
causes error because its configuration file doesn't exist. This
commit fixes the configuration and re-generate the screenshots.
New bot avatars are generated with this tool. Having the avatars generated,
we can run generate-integration-docs-screenshot to generate the doc
screenshots.
Fixes: #17792
Added a commit to bind vim keys with the SettingsPanelMenu,
allowing users to control the settings and organization tabs
using 'h','j','k' and 'l' keys.
vim_left('h') -> Switch between tab by shifting focus to the left.
vim_right('l') -> Switch between tab by shifting focus to the right.
vim_up('k') -> Move up.
vim_down('j') -> Move down.
Also link to it from the API documentation page,
other help pages, and the confirmation dialog for
muting a user.
With substantial edits by tabbott and alya.
* Revert "frontend: Remove hover effect from small messagebox."
This reverts commit 27d9643274.
* Revert "frontend: Use placeholder style for small messagebox text."
This reverts commit 8453aac260.
* Revert "frontend: Make "Reply" button look more like a textbox."
This reverts commit 9fdd7184c6.
To calculate the max-height of buddy_list_wrapper, we use
invite-link-height. This works alright if inviting is enabled
for all. However for users who aren't permitted to invite,
the element does not render, hence the logic uses `0` as
default value for subtraction in `get_new_heights` function
under resize.js. This leads to the keyboard-shortcut icon
rendered below the browser window. Hence use the parent div
`right-sidebar-shortcuts` height for the logic.
* Remove unnecessary json_validator for string parameters.
* Update frontend to pass right parameter.
Bump api feature level and highlight the fix for `emojiset`
parameter of `settings/display` endpoint in zulip.yaml file.
Fixes part of #18035.
* Remove unnecessary json validator for string validator.
* Update frontend to pass right validator.
* Update zulip.yaml to pass right parameter for curl request
in openapi.
* Update python_examples to pass right paramater.
Fixes part of #18035.
Commit ad76df25ac (#18405) uses Map
incorrectly. A JavaScript Map needs to be indexed with .get() and
.set(), not with [].
Also, clean up the API: ‘lookup_table’ is a meaningless variable name,
and there was no information in the array that wasn’t also in the Map.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The previous `top_offset` calculation didn't include the height
of the panels which led the calculations to be performed as if
a portion which was hidden behind the searchbox, was visible to
the user.
The new formula is corect as the frb_top calculation in
panel.resize_app also uses panels_height.
Note that the documentation cannot fully use our macros, because
Uptime Robot requires an & of the end of the URL, because of how it
passes its payload.
Fixes#13854. Fixes#13939.
A modal is added to edit the realm linkifier which
supports ui_report error.
Puppeteer tests to verify linkifier update and an
invalid test to verify that linkifier error messages
are reported on the modal are added as well.
This commit adds `title` attribute and removes
`aria-hidden` attribute in `Delete` button in
linkifiers table.
`aria-hidden` attribute is used only for icons on buttons
that have a plain-text label.
Implemented dropdown_list_widget in Move topic popover which enables,
the functionality to search for streams while moving a particular topic.
The aim is to reduce the user effort by having an input
typeahead instead of haivng a dropdown list of streams.
Closes#14860.
Previously, the focus event was triggering on a hidden
dropdown input field, which caused it to not gain focus when
clicked on dropdown button.
This is so because focus events cannot be triggered to
hidden elements or elements that aren't visible in DOM.
Added a fix by explicilty triggering the focus event to
dropdown input field only if the input field is visible in the DOM.
Followup of zulip#17926.
Basically, the aim is to concise modal texts
to use 'Confirm' instead of long labels since they can
tricky for translators and can also create bad strings
having long words.
This is good to do in general for these type of event handlers
and this also fixes a bug where pressing on reply button in
the recent topics will open compose with a new line since
browser assumed enter was pressed on compose_textarea since
process_enter_key returned false.
Since we support hooking up code playgrounds for custom languages
outside of the list of languages supported by Pygments, we display
an option to select a "Custom language" in the typeahead.
The `pygments_name` field typeahead shows a list of human-readable
`pretty_name`to pick from. However, the Pygment aliases which are
used for code highlighting within a code block are different from
these. This mismatch might be confusing for folks unfamiliar with
technical details of the "code playgrounds" feature.
To bridge the gap, we now include the Pygment aliases within
parenthesis along with its human-readable name, in the typeaheads.
E.g: Python 2.x (py2, python2).
Added a fix to bind vim_up(k) and vim_down(j) keys
with the draft section, allowing users to scroll
between the drafts using 'k' (scroll up) and
'j'(scroll down) keys.
Fixes#18397
Previously, we relied on the browser placeholder text style, but this
makes it impossible to style text to look like a placeholder.
Chrome uses `color` to set the placeholder, while Firefox uses
`opacity`. This commit sets both, since setting one without the other
will lead to strange behaviour.
We pick the color for the light and day themes to ensure that we meet
WCAG standards for accessibility.
Added Help link widget within account settings for
deactivate account UI modal which redirects to
/help/deactivate-your-account within the user documentation.
Previously, we used to hide 1:1 PMs with muted users everywhere
in the UI. This commit makes it so that such messages will now be
visible in `pm-with/<muted_user>` narrows, meaning these will not
be excluded from message lists, but will still be hidden under
the "This message was hidden." dialog implemented earlier.
* We hide 1:1 PMs from and to muted users throughout
the UI, because doing so will not lead to loss of
conversational context. The "to" part is also important,
because the last few messages sent to a user before
muting them would probably be asking them to stop
spamming.
* After this change, we will need to do filtering for either
user or topic muting in pretty much all narrows, so we need
to keep the `_all_items` list in MessageListData always
up-to-date.
* A further commit will relax this and make it possible to
view these messages only when in a `pm-with/muted_user`
narrow.
This basically reverts 4bd7ec7c36 and
3a9dfc02e6.
The plan earlier was to have compeletely different codepaths
for user and topic muting, so that we could call seperate
functions in the message list class on receiving the respective
events.
However, this cannot be done, because if we, for example, on
receiving a `muted_users` event, filter `_all_items` based on
just user mutes, and store the result in `_items`, then, that
result may still contain topic-muted messages, which is
undesirable. Hence whenever we filter messages, we must do so
based on both user as well as topic muting.
(The code for the former will be added in further commits.)
So, we will have a single function which will handle updating
the message lists for muting.
We were losing scroll position after re-render because there
were not enough rows present in the table to focus back to
the same position. With this commit it is possible now since we
always render with enough rows to do so.
We save the scroll position of the user by keeping the topic
row at the center of the visible scroll container in focus. The
avoids focus being reset to first topic row when recent topics
renders. Thus, this improves the UX of recent topics.
Add a function which is called before every render to
get the number of items it can render. This can be used by
instance to load custom number of items as per its state.
We allow ListWidget instances to pass functions in opts that can
be called after scrolling to determine when to render.
Also, allow a callback function to be called pre render.
We move compose from being a part of message feed to
being a part of middle column which is a common parent of recent
topics and message feed. This allows us to use a common compose
box for both the views. Fortunately, compose actions were
independent of this change so there weren't any evident
side effects.
Fixes#17543
* Remove unnecessary json_validator for string parameters.
* Remove unnecessary JSON encoding in frontend calls. Structurally,
JavaScript does correct encoding without explicit JSON encoding.
Fixes part of #18035.
The `.refresh-failed-message button` was registering clicks even
while the button was spinning (has already been clicked once).
Thus a network request was sent for every subsequent click which
raises an exception that the local id is not found in the message
store as it had already been reifyed by the first request.
Fixes#18375.
In this 009b7bca24 commit `before_punctuation`
regex was updated to use lookbehind feature of regex.
This caused a regex error in some browsers (reported in
Safari) because lookbehind feature is not yet supported
on all the browsers (https://caniuse.com/js-regexp-lookbehind).
This commit fixes that error by reverting to stable regex which
works on all the browsers.
Thumbor and tc-aws have been dragging their feet on Python 3 support
for years, and even the alphas and unofficial forks we’ve been running
don’t seem to be maintained anymore. Depending on these projects is
no longer viable for us.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Leave the Intel build as the prominent default, since it will run on
both platforms. (I would have liked to detect the appropriate
platform, but Apple seems to have put significant effort into making
that impossible for anti-fingerprinting reasons, which is probably an
overall good.)
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Due to spaghetti CSS that should be fixed but isn’t fixed here, the
<span> wrapper is still needed so the hover effect is applied.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This button will allow users to avoid a distracting red banner across
their screen, while they wait for their sysadmin to do the upgrade
work.
Fixes: #18359
Since we don't process private messages yet, we don't
need to re-render when we receive a new private message
as it doesn't change any data related to recent_topics.
* Move the extended documentation of code blocks to a separate page.
* Merge "code playgrounds" documentation to be a section of that page.
* Document copy widget on code blocks.
* This commit changes how we refer to "```python" type syntax for code
blocks. Instead of being called a syntax highlighting label, this is
now referred to as a "language tag", since it serves both syntax
highlighting and playgrounds.
* Remap all the links.
* Advertise this new page in various places that previously did not have a link.
This will allow us to avoid duplication of array filtering
logic of the form-
`Array.filter((user_id) => !muting.is_user_muted(user_id))` and
`Array.filter((person) => !muting.is_user_muted(person.user_id))`
We want to exclude 1:1 PMs from muted users everywhere
except in `pm-with/<muted_user>`.
This method will help us determine whether we are in such
a narrow.
* We show a "Click here to reveal." hyperlink in the hidden
message dialog for user to click on and read a hidden message.
* The "reveal" action is temporary, in the sense that a revealed
message will again be hidden once the broswer tab reloads or
if the user renarrows.
* When a message is revealed, we make sure to show the sender
of that message, even if it isn't the first message of it's group.
This is because the first message of that message group (which
would have otherwise shown the sender) can still be hidden.
* Reactions and background color after revealing a message are
the same as if the message hadn'e been hidden at all in the
first place.
* We hide the sender and reactions on messages sent by muted
users, and replace the content with a "This message was hidden"
dialog.
* Ideally, we should collapse a series of consequetive
messages sent by muted users into one such dialog, but
that could break the cursor behaviour and `near/<message_id`
links, so we as of now show one dialog per muted message.
* Because we hide the sender, there is a chance of the first
hidden message in a group looking like it was sent by the
author of the message above it. To tackle this, we intentionally
make the hidden message dialog float-left, so that it is clear
that this is a special type of message.
* For context, we still show the timestamp of the message.
* Starring, editing, deleting etc a message still work just like
before.
A further commit will add the ability to reveal a
hidden message.
We were not considering the owner role in `sort_role` function
which was leading to improper sorting when sorting the users
list according to role. This commit fixes this bug by considering
role in `sort_role` function.
We also add a check to see if `message_feed_container` is visible,
since it is possible that recent topics could be visible which
was not a possibility when this logic was written.
Linked the Help Center document in places like
- zulip.yaml (/events, /register/, realm/playgrounds,
/realm/playgrounds/{playground_id})
- /help/format-your-message-using-markdown (Linked to make
users reading the markdown code block style, aware of this
feature)
- /templates/settings/playground_settings_admin.hbs (Linked
as a reference to read more about playgrounds before
configuring one)
Also showcase the feature on /features and /for/open-source.
The typeahead suggests a human-readable `pretty_name` for the
`language` field in the add-playgrounds form.
The suggestions are sorted based on the popularity of these
languages.
E.g: A `py` prefix would match with `Python` first before
matching with others like `Python 2.x` based on priority.
The UI makes use of an onclick on the trash icon to call
DELETE /realm/playground/{playground_id}. The id is
extracted from the data attribute `data-playground-id`
set on that element.
The design of the form is similar to the linkifiers page
and is styled similarly.
The introduction text for "Code playgrounds" is improved
with more details and examples.
Also, we can remove the hardcoded playground and the fix
we had previously done to prevent breaking the hardcoded
playground.
This commit displays the loading animation and hides other
avatar options as delete_user_avatar is called and as we get
response from the server, we show the options back and hide
the loading animation.
These two blocks of code has incorrectly placed or implemented
conditionals for the rare corner case of Zepyhr mirroring
organizations.
Longer-term, we'll want to refactor this further to directly reference
can_render_subscribers, making the logic more general.
The previous commit remove an obsolete form laying within
subscription_table_body.hbs. However, doing so broke the functionality
of triggering the stream-creation modal using the 'Enter' hotkey.
This commit re-introduces the functionality of loading the stream
creation modal only if the user has the permission to create streams.
At the same time, we make sure it's still possible to subscribe to
streams within zephyr mirroring organizations.
The 'reply' button shows the stream>topic or recipient(s) of the
selected message, for better UX. It also expands to fill the
remaining horizontal space in the button bar -- this should help make
it easier for new users to figure out how to reply.
Finally, it uses "Message" instead of "Reply", to better match the
compose box.
Fixes#17940.
Followup of #17926.
Basically, the aim is to concise modal texts
to use 'Confirm' instead of long labels since they can
tricky for translators and can also create bad strings
having long words.
Earlier, a user can only mute a topic from its recipient bar but can't
unmute it from there (and in fact we displayed an option to mute even
if the topic was already muted!). This commit fixes that bug and
allows a user also to unmute the topic from its recipient bar.
There are two core issues here;
* We did not have code, an icon, etc. for the "already muted" case in
the recipient bar logic at all.
* We did not rerender messages in !excludes_muted_topics views when
muting state changed.
See: 660475bd0c for background on when
we started only rerendering the streams with excludes_muted_topics
after muting changes. Rerendering of newly muted topics are important
for live rendering if a user is narrowed to that topic itself, which
are essentially all excludes_muted_topics narrows anyway.
Hence, now, we rerender by calling the `rerender` function for muted
topics (which is done just before we update the items for muting via
the function: `update_items_for_topic_muting`).
Tweaked by tabbott to add comments explaining the reasoning and
long-term plans.
Fixes#15223.
We are restricting the feedback widget (confirmation pop-up)
to be visible to the users if they have muted the topic using
the hotkey: `M`, because if the users have muted the topic in
some other way then it is known to them about their activity.
In fact, the confirmation pop-up was intrusive to some users
(see #2367).
While using the hotkey they can unknowingly mute the topic. Hence, in
such a case, it is necessary to acknowledge the users about their
action.
Since we don't have content for GIPHY popover at the time
popover is rendered, we need to render with some fake
content otherwise popover library doesn't allows for us
to show the popover.
This came into notice after 5adc6d7297
broke show popover behaviour for GIPHY but didn't break it for
emoji popover as emoji popover already renders with some content.
Prior to this commit, popover library used `title` as content for
GIPHY popover.
In the source realm selector, when we select a realm from which we want
to import the data, we pass the source realm's string_id. The problem
with this approach is that the string_id can be an empty string. This
commit makes the source_realm pass the realm's id instead of string_id.
Now, the source_realm's value will either be an integer or "" (empty
string) when we don't want to import settings from any realm.
Currently only enabled in development, since the exact details don't
seem right..
Co-Author-By: Signior-X <b19188@students.iitmandi.ac.in>
Co-Author-By: Aman Agrawal <amanagr@zulip.com>
Implements UI for #8005.
This avoids slightly glitchy looking behavior in certain scroll
positions where there just isn't enough space above link to make it
look like it's top of the other element.
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.