It's kind of silly to cache ListWidgets for subscriber
lists when we only ever update the most recent one.
This will save memory if you are managing a whole bunch
of streams, although I suspect the savings here is
mostly negligible unless you were doing something
crazy.
The main motivation here is just that it simplifies the
code.
Now our click handlers get stream_id directly from
e.target, and then downstream code is no longer
coupled to the event semantics.
Note that we'll probably just know the stream_id
more directly after future commits.
We also remove a little bit of redundant error
handling.
This is a fairly straightforward extraction.
It's good to test this with Iago, and then go into
Manage Streams and add/remove subscribers for a stream
like devel.
I copy/pasted two small functions that will soon
diverge from stream_edit. The get_stream_id function
will either use a module variable (since we're
generally only editing subscribers for one stream, and
we already have the singleton assumption with
`input_pill`) or a more strict CSS selector. And then
get_sub_for_target depends on get_stream_id. We may not
always need full subs, anyway, and when we adapt some
of this code for creating streams, things are likely to
change.
I stopped exporting a couple functions that have no
callers outside of this module.
The main entry point for the module is
enable_subscriber_management.
We continue to export invite_user_to_stream and
remove_user_from_stream, which should possibly be just
pulled into their own module to lessen some
dependencies, but they don't have too much baggage,
since they just wrap channel calls.
We handle "Theme settings" subsection separately in
get_subsection_property_elements as it contains unique
radio-button structure for emojiset setting.
This should have been fixed while reorganizing the section
to have color scheme and emoji related settings under same
subsection in adb612a0b4.
Fixes#20644.
This is a pure code refactor for readability.
Previously, we were relying on there being a side effect to
add_clean_reaction which was necessitated by the presence of an output
parameter, `message` (or more specifically `message.clean_reaction`).
Output parameters are confusing.
Hence, this commit changes to have a make_clean_reaction function that
returns a reaction.
The name here is accounting for future plans where
we will share code for both of these use cases:
* editing subscribers on current stream (now)
* editing subscribers on new stream (upcoming)
This has two long-term goals:
- avoid circular dependencies between
stream_ui_updates and stream_edit
- facilitate code reuse for adding subscribers
to a new stream (i.e. using same widget for
when you edit subscribers)
Previously, there was a bug where a failed message would only show the
`.message_failed` icons on hover, the intent was for them to always be
visible if a message failed to send.
The cause of the above bug was that in
e7b1de8ace we modified the html
structure of the icons such that each icon was inside its own div,
which possessed the `message_control_button` class, and both such divs
were inside a `.message_failed` div. The unintended consequence of this
change was that the rule `.message_controls .message_control_button`
would apply `visibility: hidden` to the icons.
Hence, this commit explicitly sets the visibility of
`.message_failed .message_control_button` to `inherit`.
We change the various "Up to N minutes" settings option labels to
"Custom", since the N is a little too mathy for some users.
Since the new prompts for the value of N are longer, we need to move
those prompts to the next line. Mainly this means switching from
`dependent-inline-block` to `dependent-block`, but we also need to
move the block out of the containing input-group for the CSS to be
happy.
Substantially rewritten by tabbott to use CSS for positioning and
change the message deleting copy of this issue.
Fixes#20177.
This avoids the somewhat confusing visuals of showing messages as
EDITED where the content had not been changed, which also obscured
situations where a message had both been edited and moved.
It's possible we could do better with some sort of fancier block-move
visual styling, but it's a bit tricky to do well given that we support
moving multiple messages at once.
Fixes#20451.
As noted in the TODO that we delete with this commit, we never
implemented live-updated for edit history when moving a message to
another topic.
Implementing this involves somewhat ugly copy-paste of the logic for a
content edit, but structurally is pretty simple.
It also makes #20451 much more visible.
Zulip shows two guides on How to reply, first one by
the welcome bot and second one is intro_reply hotspot.
To simply and avoid redundancy, intro_reply hotspot is
removed.
Fixes#20482.
This commit changes the behavior of subscriber list to
always be sorted by name instead of sorting them by email
when emails are accessible.
This change is fine because we will be using user-level
email address visibility and in that case the email of
some users will be visible and email of some will be not.
We show "Email" column heading always in users list and
subscriber list irrespective of the email-address visibility
setting after 46660e5, so we do need to pass show_email
parameter to render_admin_tab and render_stream_settings.
Radio inputs that are not selected are technically independent
:read-only inputs, not a single input with multiple values; this
results in this selector for read-only inputs not behaving as
expected.
Fixes#20221.
Removed existing empty narrow divs from app/home.html and created
a new javascript module to dynamically load empty narrow messages
using handlebar template.
Fixes#18797
Moves CSS rules that rely on list items in an ordered list being
wrapped in a `<p>` tag so that they apply to the list item itself.
Uses `position: absolute` to set the `::before` pseudo-element in
place and `position: relative` to adjust the list items so that they
do not overlap.
Ideally, when Safari supports the `content` property for `::marker`
pseudo-elements, this issue can be revisited.
Fixes#20440.
The web-public option was disabled instead of being hidden in stream creation
form during live update triggerred from setting enable_spectator_access to
False. It was not being hidden since we have made web-public as the first
option and it is selected by default.
This commit fixes the bug to hide the option and also makes the code more
readable.
We should only consider visible choices while selecting the default
stream-privacy choice in stream creation form. Previously, we were
only checking whether the option is disabled, but this resulted in
a case where no option was selected when the realm-level setting
was set to not allow web-public streams as the choice was only
hidden and not disabled.
This is likely not the correct long-term fix, but it's an effective
tactical fix for this button. Added a TODO noting the expected
direction for a long term solution.
Fixes#20481.
It is possible for user to change the width by using
screen rotation after the page has been loaded on mobile.
If only height has changed, it is most likely due to a
virtual keyboard, we don't hide popover in that case.
Fixes#20439
In 4792af5682 I reformatted the template in such a way
that the div was no longer empty, and therefore
the :empty pseudoclass was not properly applied to
show the placeholder.
If a user chooses to not broadcast their presence status to others, we
still show the user as available in their own user sidebar. Instead, one's
own availability should appear the same as it does for other users.
With tweaks from YashRE42: rebasing to use user_settings instead of
page_params, as introduced in the series of commits ending with
8755a76cf6, adding code comments and
moving the redraw call to `server_events_dispatch.js`.
Fixes part of #18846. Further work is required to display the user's own idle
status properly to complete #18846.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Co-authored-by: Ganeshprasad Biradar <biradarganesh25@gmail.com>
Changing realm-level notification batching period setting from UI
was broken after adding the "Custom" option in 4f63378e7f because it
handled only user-level setting code and not realm-level setting.
This commit fixes it.
This commit refactors the set_notification_batching_ui to
use settings_org.change_element_block_display_property function
for toggling the visibility of custom input.
We add id to the email_notification_batching_period_edit_minutes
element such that we can use change_element_block_display_property
function because it requires id of element as an argument.
This commit also removes the value attribute of the custom
input since its value was set undefined in the template
and then was set in set_notification_batching_ui, so there
is no use of keeping the value attribute in templates.
This is a prep commit for fixing the behavior of this element
in realm-level default settings.
The stream select dropdown's height was clipped by the modal
container which resulted in the dropdown only being displayed
partially. We could either move the dropdown to under `body` or use
`position: fixed` for it be able to show outside parent container.
We go for the later option.
The GIF icon was taking more height than it was alloted to.
The height taken also varied slighly based on external factors.
This pushed other buttons out of their desired position.
Since we don't use video button in compose control buttons
popover, this will never be reached. We can add this code again
when we add video button to the popvoer.
Fixes#20431 by changing dark theme colors of upgrade tips to match
colors of other dark theme tips (with the same structure as the
existing .tip class).
We don't hide popover on click for formatting buttons, emoji picker and time
picker.
Emoji and time picker popovers need a reference to be displayed,
hence we don't hide them.
Not hiding formatting buttons is based on past discussion.
The current instance of compose popover is stored locally
so that we can access it across different modules.
The basic approach for hiding / displaying a button is based on
width and is executed at `sm` breakpoint as per our
`css_variables.js`.
Used handlebars and `hide/show-sm` css class to make this
work. This avoids using too much JS to hide/display elements.
* We move enter sends into its own row separate from compose
control buttons and send button. This makes sure compose control
icons don't wrap on narrow widths.
* Move char limit indicator parallel to enter sends button.
* Left align character exceeded count at bottom.
`Press Enter to send` used to hide `Send` button, we remove that
behaviour.
We show the current state of `Enter` hotkey action via text below
`Send` button which can toggle behaviour on click.
The new is obviously parallel with the small avatar URL construction,
and allows us to deduplicate this construction between the popovers
and full user profile logic for getting a medium avatar URL.
Fixes#20140.
This regular expression to add commas to a large number is hard to
read and produces less useful output than using the standard browser
API for doing this.
Fixes#20416.
We disable the enable_spectator_access setting when the server level
setting, WEB_PUBLIC_STREAMS_ENABLED setting is set to False.
This commit adds a new argument is_disabled to settings_checkbox which
is used to disable the checkbox and set the color of label accordingly.
This commit also adds a help-link besides the label pointing to
"/help/web-public-streams" which is shown irrespective of the
setting being enabled or disabled.
Fixes#20417.
The render_only parameter was passed to settings_checkbox partial of
realm_enable_spectator_access to hide the setting if the server-level
setting is set to False, but it was incorrect since we do not pass
page_params dict to the template and this was not working.
Initialy the render_only was set as page_params.development_environment
and then to page_params.server_web_public_streams_enabled in 260851cd0.
Both of these were incorrect since page_params is undefined in this
template.
We have now decided to disable the setting instead of hiding and this
will be done in next commit and this commit removes the render_only
parameter since it is not working anyways.
The is_nested paramter in settings_checkbox.hbs used to
set disableable class in the div element is not used
anywhere and thus we can remove both the is_nested parameter
and disableable class.
The is_nested paramater was first added in 3e0b420423 and
disableable class was added in 706f422c3.
The use of is_nested parameter was removed in a501abf3a1.
This makes the UI for users browsing organization permissions a bit
less confusing; if they can't edit anything, they shouldn't have these
extra little buttons.
Fixes#20002.
Consider a modal with an error element displayed. When a user clicks
the submit button, the current behaviour is to empty the element. This
empties the inner HTML of the error element, but the CSS makes it still
visible, just empty. This looks bad. To avoid this, we hide the element.
We use the `ui_report` module to display errors, which adds the `show`
class to the error element every time an error is to be displayed. This
makes sure that the error element isn't hidden when the user re-clicks
the submit button while the modal is still open.
update_ui_and_send_reaction_ajax is called from hotkeys, popovers,
reaction clicks, etc. but it is the common point to deny
spectator from creating a reaction local echo.
The availability of this option is now controlled by fancier logic in
stream_settings_ui.js, but we neglected to remove this
development_environment guard when doing so, resulting in stream
creation being broken in production environments (because the
JavaScript code depended on this value being available).
This is the standard way to indicate that something is a dropdown
menu, and in particular avoids confusion some folks had with the
pencil icon.
Tweaked by tabbott to unify CSS with all of our other dropdown list
widget instances.
Fixes#19888.
We select the first enabled radio button by default instead
of selecting "Public" because there can be case when a user
is allowed to create a private-stream only and the other
options are disabled in that case after some recent changes.
This commit adds code for live-updaing the stream-privacy choices
in stream creation form and privacy change modal on changing
"create_public_stream_policy", "create_private_stream_policy"
and "create_web_public_stream_policy".
This commit renames disable_private_stream_privacy_option to
update_private_stream_privacy_option_state and also refactors
the code such that it can also be used to enable the option along
with disabling the option in further commit.
This commit renames disable_public_stream_privacy_option to
update_public_stream_privacy_option_state and also refactors
the code such that it can also be used to enable the option along
with disabling the option in further commit.
This commit renames hide_or_disable_web_public_stream_privacy_option to
update_web_public_stream_privacy_option_state and also refactors the code
such that it can also be used to enable or show the option along with disabling
and hiding the option in further commit.
This commit splits the hide_or_disable_stream_privacy_options_if_required
function into three separate functions for public, private and web-public
streams. This is a prep commit for live-updating the stream-privacy choices
on changing the realm setting.
This commit adds "Manage this user" option in the user-info popover
which simply opens the administrative user-info modal.
We show a spinner on submit button in this case as modal
is not closed immediately and thus we need some indicator
to show that the task is in progress. There is no spinner
on submit button in the modal opened from "Users" section
of organization settings.
Error handling for this case is different than when the
modal is opened from "Users" section of organization
settings because there is no overlay in the background
of modal in this case.
In this case, we show error inside the modal and do not
close it and in case the change is completed successfully
we just close the modal without showing any message.
Fixes part of #18944.
We received a complaint about the generation of multiple duplicate
drafts for a single message. It was discovered that the likely cause
of this was how we were handling clients that were frequently
suspending/unsuspending, we would initiate a reload when we discovered
this, and expect the `beforeunload` handler to save the draft. This
behaved correctly, however, we would also save the compose state and
fill it in via `preserve_state` in reload.js. The important detail
here is that `preserve_state` would not encode and preserve the
`draft_id` for the current message, partly because it had no way of
knowing the `draft_id` of the draft... since we have not saved it yet,
the `beforeunload` event happens after `preserve_state`. As such,
performing any action that would trigger a draft to be saved, eg
pressing Esc to close the compose box, would save a duplicate draft of
the same message.
To resolve the above bug, we (1) ensure that we call
`drafts.update_draft()` in `preserve_state`, this returns a draft_id
to us, which we (2) ensure that we encode as part of the url and (3)
set on the `#composebox-textarea` as a `draft-id` data attribute,
which we check the next time we try to save the draft, post reload.
Note that this causes us to save the draft twice, once from
preserve_state and then again from the `beforeunload` handler, but we
do not add two drafts since the second update_draft call just edits
the timestamp because it finds the `draft-id` data attribute on the
`#composebox-textarea` set by the first call.
Previously, opening a draft and closing it without changing the
content would cause us to show the "saved as draft" tooltip. This was
annoying and would cause annoying UX after fixing a bug related to
saving drafts when reloading, as such, this commit removes the above
behaviour by introducing a simple check on whether the draft contents
are edited.
A page can have either `white` (from `landing_page.css`) or `gray`
(from `portico.css`) background color depending on
webpack chunking order. So, this fixes that bug.
In message header search bar, users didn't use to get any typeahead
suggestions if a normal filter follows search filter.
E.g.: query => foo bar stream:D
In the above case, users didn't use to get any typeahead suggestions.
This was because we had set that the callers of 'parse' function can
assume that the 'search' operator is present in the last in the query.
Because of which `get_search_result` function (in search_suggestion.js)
didn't use to show any typeahead suggestions as it used to assume that
the latest typed query is for search filters.
Fixes part of #19435.
We directly pass operators to remove dependency on narrow_state
module. This avoids a circular dependency of `filter` module
which is evident on the `/devtools/integrations/` page.
This commit extends dialog_widget class by adding a new
optional paramter validate_input which will be a function
to validate the inputs in the dialog and will be called
before showing the spinner and calling the on_click function.
Currently, the password change modal uses this paramter to
validate that the old and new password inputs must not be
empty. Since the spinner will not be initiated in the case
where form is invalid, we need not hide the spinner after
showing the error and thus we can simplify the code to use
ui_report.error to show the error messages of empty fields.
This fixes unexpected cursor repositioning behavior when the cursor was
positioned before or inside the "Quoting..." element.
The comments document the new logic, but roughly we aim to just
preserve the logical position of your cursor after replacing the
placeholder.
We also factor out a shared variable for the "Quoting..." string which
will allow us to tag it for translation in a future commit.
If you used "Quote and reply" to start composing a message, and
started typing before receiving the original message body from the
server, we ended up resetting your cursor to the start of the line
after the quote for two reasons:
* We were incorrectly fetching the pre_cursor for our replacement
operation before doing the server fetch, which meant we ignored any
editing done while waiting for the server to respond.
* Worse, we actually fetched the original cursor position before
inserting the "[Quoting...]" placeholder text. So we were guaranteed
to have at least some amount of error in the cursor position.
Fixes#20379.
Continuing the efforts to reduce dom trashing from the previous
commits, here we remove the third forced reflow by reordering the call
to $(".top-messages-logo").show() via narrow.reset_ui_state(), such
that it happens before the other DOM writes in
recent_topics_ui.hide().
Tweaked by tabbott to avoid adding an unnecessary if/else statement
around recent_topics_ui.hide.
This is a prep commit towards pushing the reset_ui_state calls upwards
into recent_topics_ui, in order to prevent a forced reflow. One side
effect of this change is that we add a call to
`narrow_banner.hide_empty_narrow_message()` from `narrow.activate()`.
This likely has no visible effect, in that the message list rendering
process would end up setting the narrow_banner state correctly, but
logically it could in the future avoid a banner from a stale banner
incorrectly appearing before we've rendered the current view.
This is a prep commit towards extracting a reset_ui_state function
which we can call from here, narrow.activate(), recent_topics.show()
and recent_topics.hide().
We want that function because it will enables us to prevent a forced
reflow when navigating from recent_topics to stream: xyz.
Going through the description of commit
a150b9b0ae is highly recommended since
this is a related issue.
We had received a complaint on chat.zulip.org about navigation with
the keyboard `n` key being significantly slow (~5 seconds), the first
time `n` was pressed when starting from the recent topics view.
It was difficult to reproduce the amount of lag that was reported, but
running chrome with the profile tab set to 4x slowdown helped get
close to it.
Based on profiling from the original report, as well as locally with
chrome set to 4x slowdown, led to the realisation that recent topics
to stream navigation involved a lot of dom thrashing, and so this
series of commits aims to prevent this path from causing forced
reflows.
In this commit, we reorder the calls to $(...).show() in
recent_topics_ui.hide(), this prevents the first reflow in this path,
most likely because displaying message_feed_container before
message_view_header_underpadding was guaranteed to cause style
recalculations since the underpadding is visually above the message
container.
This causes a net 60 ms decrease in the first renarrow, an ~ 70 ms
increase in the second renarrow and an ~ 5 ms increase in the third
renarrow but, more importantly, it eliminates one reflow and sets on a
path where we can achieve strong gains in subsequent commits.
We show "Please enter your password" error inside the modal
if the "Old password" input is empty and "Please choose a new
password" error if the "New password" input is empty and do
not send a request to server.
Fixes#19901.
Previously, if an admin created a private stream with shared history
or a private stream with protected history, they would see the general
tab for that stream in the right side of the subscriptions_overlay as
expected, but, they would not see the pencil button to change stream
privacy unless they clicked a different stream and came back.
The reason for this has to do with how we receive events when we
create a sub. We first get an event with type "stream" and op
"create", we then get an event with type "subscription" and op "add"
ie we create the stream and then sub ourselves to it. Now, we render
`stream_settings.hbs` while handling the "stream create" event, at
this time we pass `can_change_stream_permissions` as false since
`(!sub.invite_only || sub.subscribed)` is false because we're not
subscribed yet. This causes us to skip the insertion of the
"change-stream-privacy" block which is a problem because when we're
handling the "subscription add" event, we run
`stream_ui_updates.update_change_stream_privacy_settings(sub)` which
tries to show the element via `.show()` but can't since the element
does not exist and as a result the admin user does not see the pencil
edit button.
This commit fixes the above bug by changing the template such that we
always insert the button, but conditionally apply
`style="display:none"`.
Fixes: #20345.
I rewrote most of tools/lib/pretty-printer.py, which
was fairly easy due to being able to crib some
important details from the previous implementation.
The main motivation for the rewrite was that we weren't
handling else/elif blocks correctly, and it was difficult
to modify the previous code. The else/elif shortcomings
were somewhat historical in nature--the original parser
didn't recognize them (since they weren't in any Zulip
templates at the time), and then the pretty printer was
mostly able to hack around that due to the "nudge"
strategy. Eventually the nudge strategy became too
brittle.
The "nudge" strategy was that we would mostly trust
the existing templates, and we would just nudge over
some lines in cases of obviously faulty indentation.
Now we are bit more opinionated and rigorous, and
we basically set the indentation explicitly for any
line that is not in a code/script block. This leads
to this diff touching several templates for mostly
minor fix-ups.
We aren't completely opinionated, as we respect the
author's line wrapping decisions in many cases, and
we also allow authors not to indent blocks within
the template language's block constructs.
In cases where an opening tag is so long that we stretch
it to 2+ lines of code, we should try to use block-style
formatting in the template code.
Unfortunately, we have lots of legacy code that violates
this concept, so this is a timid fix.
There are also legit use cases like textarea where we
probably need to keep the ugly template syntax for things
to render properly.
This fixes various visual glitches that resulted from reusing
components and overriding key elements of them. The specific logical
changes are as follows:
* Delete custom checkbox positioning for stream settings; we now just
use the common app_components.css code.
* Remove custom subscription-control-label styling; just use settings
defaults.
* Copy the h3/h4 styling from settings.css. Ideally we'll deduplicate
this in further cleanup.
* Add the inline property to stream_settings_checkbox elements, to
reduce variable with settings_checkbox.hbs.
* Place every individual input inside an input-group, so that we can
use the standard settings.css styling.
Previously, the stream_edit modal relied on the new-style class to set
the margin-bottom value for stream-message-retention-days-input to 0,
in order to override the value set by bootstrap. The class new-style
is unhelpful because of its generic name, and in addition, time has /
will eroded away the significance of its name.
Hence, this commit adds the necessary rules to subscriptions.css and
removes the new-style class.
In order to make this change, this commit adds a block to
`subscriptions.css` with the selector `#stream_privacy_modal
.stream-message-retention-days-input input[type="text"]` one important
rule that this adds is `height: inherit;`. Adding this rule solves a
minor UI glitch where selecting "retain N days after posting" would
cause the save and cancel buttons to jump down by a pixel or so.
Fixes: #20222.
The stream creation form currently does not setup its own handler for
displaying the "N:" input when ".stream_message_retention_setting" is
changed.
Prior to e793ef7f62d280300afeeab2f4a086e99858a5a9, this form would
sometimes work as intended because stream_edit would set the handler
on this dropdown, when it was opened. However, after that commit, this
would simply never work.
Hence, in this commit, we make changes so that stream_create correctly
sets the handler on its dropdown. This causes us to repeat ourselves a
little and as such is not the cleanest solution, but this might be the
best we can do due to the complications of stream_edit opening a
modal.
The stream creation form also uses the same stream_types template as
the stream privacy modal, however, it currently does not setup its own
handler for displaying the "N:" input when
".stream_message_retention_setting" is changed.
Previously, if one opened the stream creation form, then opened the
stream edit modal, and then went back to the stream creation form, the
drop down would correctly also .show() the input, because the handler
here would also target that selector. This is incorrect since we can't
always expect the stream_edit modal to be opened first, stream_create
should set up its own handlers.
Hence, as a prep commit to fixing stream_creation, and to ensure we
don't add duplicate handlers, in this commit we change all selectors
that targeted ".stream_message_retention_setting" to
"#stream_privacy_modal .stream_message_retention_setting" in this
file.
In d62e44fcba we migrate to using
micromodal for this pop up (via dialog_widget), as a result the
.modal-body style no longer applied as that class is not used.
In 55adf88e667da02284f0a6ffb6bcfdf73b5427cb we remove the grey-box
class from the stream_types template, hence even if the above wasn't
true, this rule would still not apply.
This commit thus removes this rule.
Previously, the presence of the styles applied by grey-box caused a
visual disparity between the stream settings overlay and the
personal/organization settings overlay, hence, this commit removes
this class.
Previously, the presence of the styles applied by grey-box caused a
visual disparity between this modal and similar settings in our
organisation settings view, hence, this commit removes this class.
The public and private stream choices in stream creation form are disabled
according to create_public_stream_policy and create_private_stream_policy
settings. It is not needed to disable them in stream privacy modal since
only admins can change the privacy of stream and they are allowed to
create public and private streams always irrespective of the setting.
This commit has the following changes -
- Adds dropdown for changing create_web_public_stream_policy and this
dropdown is visible only if settings.WEB_PUBLIC_STREAMS_ENABLED and
enable_spectator_access is set to True. This dropdown is live-udpated
on changing enable_spectator_access setting.
- The web-public stream option in stream creation form and stream privacy
modal is hidden if one of settings.WEB_PUBLIC_STREAMS_ENABLED or
enable_spectator_access is set to False except in stream privacy modal
when the stream is already web-public so that the user is not confused by
none of the options being selected.
- We disable the web-public stream option in stream creation form and
in stream-privacy modals of stream which are not already web-public
when the user is not allowed to create web-public streams as per
create_web_public_stream_policy setting.
- We use on_show parameter to hide or disable the options in stream-privacy
modal because we use the visible property of element to remove the bottom
border from last element in the stream-privacy choices and thus we have
to wait for the modal to be visible.
Fixes#20287. Fixes#20296.
This commit adds user_can_create_web_public_streams function
in settings_data.js which will be used in further commits
to disable or hide the UI elements for creating web-public
streams.
We do not have 'realm_' prefix to the settings used as keys
in realm_settings object, we directly use the setting name.
This commit removes the 'realm_' prefix from enable_spectator_access
setting.
This is a very frequently requested feature for organizations that are
new to Markdown, that brings Zulip's UI more in line with that of
competing projects and other markdown editors like the GitHub UI.
* We use flexbox instead of `position: relative` to align elements.
* Increase clickable area of icons using more padding.
* Increase space between elements.
* Fix mobile compose box icon alignment.
This works surprisingly unlike my previous attempts to do so.
WARN: This is a pseudo commit and should only be merged with upcoming
compose box bottom refactoring commit since the css changes required
for this change are missing here and are not required after that
commit.
Since we have the drafts button in top left corner and we need space
to insert formatting buttons in the bottom of compose box; removing
drafts link makes sense.
This provides a convenient interface to hide all drafts.
Fixes#19360.
However, we may want to continue to implement a button in the drafts
overlay as well for doing this operation.
In commit 3d86267041 we add logic to
`/shared/emoji.js` which duplicated some of the logic in this
function. Since this isn't desirable, we remove the duplicate logic
here and instead just call `emoji.get_emoji_details_for_rendering`.
In commit 3d86267041 we add logic to
`/shared/emoji.js` which duplicated some of the logic in this
function. Since this isn't desirable, we remove the duplicate logic
here and instead just call `emoji.get_emoji_details_for_rendering`.
Steve Howell
Biki-das
Tim Abbott
Julia Bichler
Sahil Batra
YashRE42
Alya Abbott
Archit Hadge
Swati Bhageria
Kevin
Aman Agrawal
Nikhil Maske
S-Abhishek
Lauryn Menard
Anders Kaseorg
My-Name-Is-Nabil
somesh202
Aini-Alem Robertson
alguimo
Ganesh Pawar
Ketan1502
Arch0125
akshatdalton
Manan Rathi
juliaBichler01
Johan Ehinger