This commit replaces the allow_community_topic_editing boolean with
integer field edit_topic_policy and includes both frontend and
backend changes.
We also update settings_ui.disable_sub_settings_onchange to not
change the color of label as we did previously when the setting
was a checkbox. But now as the setting is dropdown we keep the
label as it is and we don't do anything with label when disabling
dropdowns. Also, this function was used only here so we can safely
change this.
For this extraction, we need to move some context
parameter (from home_real in `views/home.py`) to extra
page_params parameter (of
build_page_params_for_home_page_load in
`lib/home.py`) so handlebars template can access them.
While moving I confirmed that these parameters are not
used elsewhere if some parameter is used elsewhere
(like `apps_page_url`) then I didn't remove it from the
context list, I just added it to the page_params list.
Fixes: #18795.
This is a prep commit to extract the gear menu as a
handlebars template.
We are renaming `enable_marketing_emails_enabled` to
`corporate_enabled` as it will be also used in the
handlebars template of the gear menu.
This results in moving the `zulip_merge_base` parameter to
page_params, so that it's available to JavaScript.
Since this is technically a tiny overlay, it needs to be initialized
before hashchange.js.
We only need to bump up indexes if inbound
events suggest that we have incremented our
personal index from another device.
We don't want somebody else's runaway index
to affect our index.
(For both widgets the sender_id is part of
the key, so uniqueness across all senders is
not required for the integer part.)
We now ignore question edits if the sender of the submessage
is not the message author.
The webapp UI prevents folks from editing the question for
somebody else's poll, but a determined person could use our
low level API to do it. We will add safeguards on the server
side for this, but this change is sufficient to protect the
webapp (and mobile when they upgrade the library).
The Microsoft browsers such as IE and Edge has their own
show password that is a bit bugy and also conflicts with
the show password in Zulip that was added in #17305.
This fixes the issue by making the display none for the
ms-reveal that comes in the input.
More details can be found at
https://chat.zulip.org/#narrow/stream/101-design/topic/Show.20password/near/1173890
This tippyjs event listener was active on 'add emoji reaction'
option in sender's popover menu of a message but it was only
intended for the add reaction button in message reactions bar
at bottom of a message.
Both of those having common selector `.reaction_button` caused
errors in tippyjs near `observer.observe` having wrong args.
Edited the css selector to be more specific to only target
add reaction button in reactions row of message.
This was introduced in 99e6f25.
Functions in pill_typeahead.js assumed the type of required pills
to be user by default. But this created several readability
issues with its code, as a result, this codebase appeared
hard to change because of hacky checks involved due to this
assumption.
To improve these we use `include_users` check wherever possible
and simplify the code to clarify the logic involved in typeahead
functions in this module.
Also updated existing stream_edit tests to adjust them with changed
code.
We remove the small CSS class, which set the font size as something
tiny, and also restructure it with a fixed height and more natural
markup for the reset link.
Previously, this used a slightly smaller font size than the default.
Given that it looks visually fine to use the default font size, it's
better to remove this inconsistency.
It's also worth noting that we plan to move this component to be
parallel to STREAMS in a way that is likely to also want the new font
size, so this is a step towards that goal.
This fixes a regression in 16bd6e6b1d
that caused the user profile modal to display "Last active: Last active: ...".
I'm not convinced these are the best visuals, but the whole modal
needs a visual refresh.
We split recent_topics module into recent_topics_(ui + data + util).
This allows us to reduce cyclical dependencies which were
created due to large list of imports in recent topics. Also, this
refactor on its own makes sense.
`user-profile-modal` is shown using `overlays.open_overlay` which
disables mouse pointer events. The user can't click anywhere while a
modal is present, except to close it.
We use `hide_all_except_sidebars` and `hide_all` to hide popovers.
But since the user can't interact while a modal is present,
closing it manually is redundant.
In d0f8515b50, it was noticed that
Bootstrap's `hide` and `show` calls can cause race conditions.
So, migrate to our `overlay` calls to handle Bootstrap modals.
This should make it more intuitive to add
new elements to the compose box (such as
banners), and it also makes it a bit more
clear for styling purposes that the same
geometry happens whether the compose box
is open or the buttons are visible.
I lifted the #compose_container div into
the server template. It's not totally
clear to me why we need both #compose
and #compose_container, but there are
some scary comments about 1400px that
made me too timid to address that quirk.
In passing I removed a clearly redundant
click handler.
For create stream icon specially, this is useful to allow user having
some extra space around the icon to click.
This fixes the bug that you can have the tooltip of "Add streams" and
by hovering at the bottom of `+` icon but clicking on it shows stream
search.
When message for which tooltip is active has reduced opacity in
an interleaved view due `.message-fade` class being applied to
it, then the tooltip used stack vertically under the recipient_row
which looked awful.
Appending the tooltip to document.body and manually fixing the
bug of tooltip persisting after the reference element is no
longer visible in DOM using MutationObserver does the trick
for us.
Instead of prepending the alert's content to the
navbar alert wrapper HTML it's better to pass the
rendered alert content as a parameter to the wrapper
template.
This is done so that it can be shared by more generally
by different filter widgets used in web-app. An extra parameter
is added to it that helps to get text representation of of items
to be sorted, as items passed to it could be of different format.
Instead of just depending upon clicks of certain buttons to
show the right section, we also show them when user is
creating a new stream or viewing settings of a specific stream.
This fixes a bug where user lands on `#streams/new` via url change
without clicking of any buttons and sees on left section of the
overlay in medium width (756px) devices.
We add a popover on click which allows user to create or browse
streams too.
Reason for doing so:
At present, it is hard to discover how to join streams
and create new streams. In particular:
Users have a hard time finding the gear in the STREAMS
header in the left sidebar and realizing that it's relevant for them.
Even once a user is in the STREAMS menu, the Create
stream button is hard to spot.
Fixes#18694.
The Help Center article talks about these using similar terms, which
may need further work, but it seems clear that undoing "set
unavailable" should be "set available", not "set active".
This moves this block of HTML templates, which are dynamically
rendered with some user data, to be managed by the frontend handlebars
template system.
This migration involves only displaying active alerts in the DOM, and
thus we no longer need navbar_alerts to have display: none by default.
This is important for showing popovers/menus with a light background
in Zulip's light theme.
We extend light-theme to show dark colours in night theme.
Rapidly clicking a button that shows a modal cause a race condition
in Bootstrap. Specifically, Bootstrap adds an "in" class to a modal
on the "shown" event and removes it on the "hide" event. Frequent clicks
cause the "hide" event to trigger before the "shown" event. Therefore, the
"in" class isn't removed. We use the "in" class to check if a modal is
active in overlays.js
For now, we manually remove it once the modal is hidden.
Newer versions of Bootstrap probably handle this better internally.
Look into removing this once it's upgraded.
Fixes#15463
In commit 9ce9c2f9db, we added `maybe_show_keyboard_shortcuts`
function which triggered through hotkeys.js when a user
presses the keyboard shortcut hotkey.
However, within commit 8b29c38e62, we migrated to use
hashchange.go_to_location method in order to open info_overlay, leaving the
`maybe_show_keyboard_shortcuts` function orphaned/dead.
This commit essentially removes the dead
`maybe_show_keyboard_shortcuts` code.
Rename poll_timeout to event_queue_longpoll_timeout_seconds
and change its value from 90000 ms to 90 sec. Expose its
value in register api response when realm data is fetched.
Bump API_FEATURE_LEVEL to 74.
This commit renames `delete_draft_after_send` to
`delete_active_draft` for two main reasons:
1) This function does the job of deleting the draft that we
are currently using in compose box and it is independent
of the message sending functionality.
2) This is prep refactoring for new drafts behavior where
we delete the draft if the compose box is cleared and
closed.
This changes the button text from "Reply" to "Reply to selected
message". Here's the thinking:
* The title "Reply" was a little confusing/inconsistent with the
button's label.
* If you're hovering over the button, it's because you want more
information about what it does -- not just a repeat of the button's
label.
* The "Message foo > bar" content of the button already cleanly
expresses what the button will do if you click it right now.
* The hover text "Reply to selected message (r)" explains to you what
that button's role is in all situation, not just with the current
selection, and thus documents the concept. And it also gives you
clarify if you're thinking "but how do I reply to something in
Zulip?" and try hovering over the buttons at the bottom to find out.
This commit divides the user_invite_restriction setting dropdown to
a checkbox and a dropdown.
The checkbox is used for 'realm_invite_required' setting and dropdown
for 'realm_invite_to_realm_policy'.
This separation of UI elements is fine as these two settings are
separate in database also and also helps in removing excess if-else
conditions and switch cases.
We do not require values of realm_create_stream_policy,
realm_invite_to_stream_policy, realm_private_message_policy
and realm_wildcard_mention_policy in the organization settings
templates, as we handle the dropdown values of these settings
in javascript code (settings_org.js) only and these values
are not used anywhere in templates.
Previously the logic to show save button considered only topic
and content edit. This commit fixes it to show the save button
when only stream edit is possible and content and topic edits
are not.
This commit only introduces a simple fix, in long-term we would
want to change the logic of get_editability to include stream
edits as well but it would also require discussion on when to
show the edit icons at different places, so it is better to do
it in a separate commit later.
The message-editing section of settings is moved from "Organization
Settings" to "Organization Permissions", which feels like a more
natural place for these settings.
Previously, we had this complicated layering where the right sidebar
logic would display "Last active: foo" but the user popovers would
just display "foo", which doens't make any sense, since the two
settings have equal context about the string.
We deduplicate that and also arrange that the "Last active:" prefix is
used when it's not clear what we're talking about; i.e. all the values
except for "Active now".
There is no clear reason to not use a button element here. According
to the spec pharasing content, which includes the <span> element,
are allowed in the button element.
Manually tested both buttons to make sure it works and made sure all
the selectors are updated by grepping all the selector classes/id in
the handlebars templates that are parents of the button or are
present on the button.
(One of the jQuery handler code got reformatted due to it fitting
the line limit due to one character deletion for the selector)
Modified resend_invite modal heading to remove the email
field to avoid it's duplication, since the email feild is
also displayed within the actual modal body.
Tested by the adding a console log to the handlers and typing Tab
and Enter in the group PM and stream compose box. This two event
handlers are attached to form#send_message_form which is the compose
box form.
The tests set keyCode to 42 previously, which does not represent a
valid key, so I assume they were trying to test a random key, and
replace it with "a".
There is no functionality change caused by this change. We turn the
event key to lowercase so hotkeys work even when Caps Lock is on as
it did before.
Tested by using the keybinds with and without Caps Lock in compose
box:
- "Ctrl + B" and "Ctrl + Shift + B",
- "Ctrl + I", and
- "Ctrl + Shift + L".
(Also tested that "Ctrl + Shift + I" and "Ctrl + L" do not work.)
Tested by doing the following in the compose box input for PMs:
- "Enter" works as expcected with and without input
- "Backspace" when there is no input deletes the last pill
- Left arrow in the input focuses last pill
- Comma works as expected for correct and incorrect input
- Left arrow, Right arrow and Backspace work correctly for pills.
We use e.key for our side of code and still pass e.keyCode and
e.which to the custom jQuery event we trigger. The event is handled
by our patched copy of outdated bootstrap and it still requires the
e.keyCode and e.which properties.
One of the places this widget is used is in the settings panel, at
Manage Organization > Organization Settings > Notifications > New
stream notifications. One of the handler is attached to the
dropdown menu items that shows up when you click the "#announce"
button. The other one is attached to the search button. The second
one triggers the custom jQuery event and passes the event data to
bootstrap unless the Up & Down arrow or Esacape is used. The first
event handler handles the Enter click on one of the items and saves
it. Verified that the widget works as expected.
Tested by making sure Enter is treated as click at one of the places
this function is used, recent topics view. Using the keyboard to
focus the mute or read button and click Enter treats it like a
click.
Tested by making sure pressing Enter in the input field of the
changed organization settings (the organization name for example)
clicks the save changes button if present.
This change fixes a bug where pressing Enter does not save the
changes as expected, due to an incorrect selector, when the
save/discard changes button shows up in settings. Tested by changing
the Organization name and pressing Enter at Manage Organization >
Organization profile > Organization name.
On small widths, add margin to right to action buttons so
that they don't they trigger scrollbar when clicked upon.
Make action buttons larger so that they are easier to click / tap on small
widths.
The Giphy SDK sends tracking pings when it loads; we don’t want those
to be sent for visitors who aren’t using Giphy.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We were passing new_stream_id as undefined in case of topic
edit as event.new_stream_id is undefined in that case.
We pass the correct stream_id to fix it.
The Event.which and Event.keyCode are deprecated as pointed out by
TypeScript intellisense based on the jQuery types. We use Event.key
instead which behaves similarly to Event.which & Event.keyCode for
our use case.
The only difference in functionality by this change is that the vim
keys won't work when Caps Lock is on. This is because, in this case,
the key property will be "J" instead of 'j'. We can fix this by
adding a mapping for this, however, I think we don't want to handle
this case so I left this change out. Tested by trying out the
everywhere keydown_util is used.
Finally, we also turn off the new-cap rule for tests since I think
it fine to only enforce it on real code and exempting test code is
fine.
This commit disables the button and shows a loading spinner on
the button when signup request is being processed to avoid race
conditions caused by user clicking on the button multiple times.
The fix is done observing that for the case when form is invalid
the whole page is rerendered and thus we do not need to remove
the spinner and enable the button again and for other errors
we redirect to some other page.
And for the validation taking place in client-side, the button
is disabled and spinner is shown, only is form is valid, by
using "$('#registration').valid()".
We live update the "Add subscribers" UI on subscribing/unsubscribing
the stream and the field sub.can_add_subscribers is used to check
whether user is allowed to add subscribers or not.
The sub object used here is not the complete sub object and thus
sub.can_add_subscribers is undefined. We need to use the updated
sub obejcts with all the setting fields that we can get from
'stream_settings_data.get_sub_for_settings' before rendering UI.
This calculation of additional fields was done previously by
'stream_data.update_calculated_fields', but in d50462568b
call to 'updated_calculated_fields' was removed with the aim to
call 'get_sub_for_settings' before updating UI which was missed
in this part of UI update.
Fixes#18616.
Source in pill_typeahead, was intialized in a
very tricky way. In this cleanup, we refactor it
to clearly reflect how source is initialized for
different cases. These changes do not change its
behavior for its current use and solve potential
issues, so that it could be safely used at places
that do not require user pills at all.
In options that we pass to pill_typeahead.set_up we
specify if we want typeahead to support stream or
user_group pills, and use users as source by default.
Using users for source by default, can have unnecessary
suggestions in typeaheads where only user_groups or streams
are needed.
So to solve that, we specify if we want users pill in the input.
This is then utilized in further commits, to clean up hacky code
that deals with intializing source for typeahead.
We make the typeahead a little more nicer but only showing one alias
per language. For example if the user searches for prefix "j", then
the typeahead list should contain "javascript" only, and not "js" and
"javascript".
When muted user's message is revealed, popover should have
an option for hiding the message again. But in case if the
popover is already open while message is being revealed then
option for undo reveal in the popover could be out of sync.
To avoid this, we hide the message actions popover before
revealing muted user's message.
Tooltips in message action buttons for failed message were
not shown properly because they were initialized two times
first because of general tippy-zulip-tooltip class and then
because of message_control_button class. So to avoid showing
an extra empty tooltip for failed message icons we return
false from onShow() method of message_control_button class
initialization of tooltip.
This check was not needded as it is possible to have even zero
edit message buttons in cases when a message is fails. So it
raises unncesary errors on hovering over icons of those failed
messages.
Since this is currently only useful to interpret presence data, we
send this only if presence is requested.
I'm not sure that server_timestamp is the right name for this field,
but ultimately it should match the main presence API format.
When quoting a reply or mentioning a person having full name matching
wildcard mention, in such case, `get_mention_syntax` doesn't return
mention syntax of format: **full_name|user_id**.
As a result, a normal user can't mention such users and users who
can mention them may unwillingly trigger wildcard mention.
This commit fixes such issue.
Prior to this, we restricted to show any user group suggestions
if silent mention syntax is used. But with the addition of
user group silent mentions, there are cases where one may want to
refer to some user groups without actually notifying them.
So, we add typeahead logic for such cases.
Test cases for silent syntax (@_*) and non-silent syntax (@*)
are added.
In the old regex, there was no 4th capturing group, hence
cap[4] always gives `undefined`. It is removed now.
Also, we were capturing the whole pattern which is not needed
as it is by default captured in the group with the 0th index.
The regex could have match a bunch of characters including `>`
and hence end up matching across multiple adjacent spans in
a weird way. This commit fixes such an issue.
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.
sahil839
Aman Agrawal
Wesley Aptekar-Cassels
Riken Shah
Ganesh Pawar
Steve Howell
Signior-X
Dinesh
m-e-l-u-h-a-n
Tim Abbott
Vishnu KS
aryanshridhar
Anders Kaseorg
Gaurav Pandey
Priyank Patel
akshatdalton
Robert Imschweiler
Siddharth Asthana
Adam Birds
Nikhil Maske
Sumanth V Rao
slefforge
PIG208
rht
Abhijeet Prasad Bodas
Ryan Rehman
Alya Abbott
Ken Clary
mandepsingh
pilgrim2308