We've removed the unused parent div. We've also removed the class that
was only being used in that div from zulip.css. We've attached a class
to the anchor element now and it has the same name as the class we
removed.
Fixes https://chat.zulip.org/#narrow/stream/9-issues/topic/Eye.20icon.20misaligned.20in.20Manage.20your.20API.20key/near/1890711.
The eye icon to show and hide password was misaligned in the 16px info
density mode. But since the icon was using absolute positioning to style
the icon, we took this chance to refactor the element to use flexbox.
We've renamed the `password-div` to `settings-password-div` for settings
specific styling. The eye icon was only broken in settings, and since
the settings and the login/signup stuff the same class was used at is
quite different from each other, it might be better to have two
different classes. The other `password-div` has not been refactored, it
might be better refactored in its own PR along with other similar
elements to use flexbox.
Previously, when a link containing the "with" operator in an incorrect
narrow is loaded, it used to open the correct view with the wrong
title of the message view header.
This commit fixes it by re building the message view header title
in case the narrow for the "with" operator has changed.
Previously, while using "with" operator, even when the narrow
was not updated by the operator, hash change requests were
made.
This commit introduces a new variable - "narrow_requires_hash_change"
which determines whether the narrow was updated and thus
requires a hash change or not.
Fixes#30862
This is a small optimization to avoid DB queries if the bot owner
is not changed.
This also helps in avoiding showing the error message in UI if
anything other than the owner is updated for a deactivated bot.
Ideally if the bot owner is not changed, the bot_owner_id field
should not be passed in the request, but we would handle that
later given this is anyways a small nice optimization and we
follow this pattern at other places as well in the API.
Fixes#30895.
The root font-size for the app has always been 16px, and it remains the
same when switching between 14px and 16px mode. This leads to
`.small` buttons looking relatively smaller to their surroundings in
16px mode. So, if we use a unit that changes when switching between
modes, we will have to multiple that value by (16/14) so that we don't
change the existing behaviour for the 14px mode and make things smaller.
This commit only affects `.small` buttons, the same named class is used
in other places but does not use rem unit there and therefore does not
require any changes.
The original plan was to use em instead of rem and multiply it by
(16/14 * 0.8), but since em depends on the parent element, there was a
case in the poll button widget where 1em was equal to 16px in the dense
14px mode. While, the right thing to do might have been some refactor to
make it work as desired, the safest thing to do right now might be to
use the --base-font-size-px variable directly for the 9.0 release.
Fixes#30920.
Before this, the buttons remained the same when switching 14px vs 16px
mode because rem was used as the unit and we are not changing the root
font-size for either of the 14px or 16px mode. Root font-size is 16px in
both cases.
We've removed 0.875 out of the 0.875rem for the font-size of the buttons
since 0.875rem is equal to 14px. It has been replaced with the base font
size variable.
We've removed the rem values for padding and border-radius and written
the pixel values directly taking in account 1 rem = 16px. We don't scale
the padding and border when switching b/w 14px and 16px mode, so we
should not do that here too. While keeping the rem around would be the
same as the current pixel value in either of the modes, removing the rem
is still better since we've concluded here that we don't need to scale
the padding and border-size b/w modes.
Adds a header to the section of changes notes about new and
deprecated narrow filters, so that it's easier to directly
link to the relevant content in the construct a narrow article
from the main API changelog and endpoint documentation.
When an administrators create channels that they are themselves
not initial subscribers, a channel creation confirmation banner
is displayed in the settings panel.
This commit updates the term "stream" to "channel" in the banner.
Some time ago, I added a condition to not reset
the search bar if the user had already started
typing, so that we wouldn't erase what they'd
started typing. But we encountered a situation
where the search bar can be opened with text in
it: clicking "searching all public channels"
from a search view. We want to reset the searchbox
to add the `channels: public` pill.
I tried to replicate original issue I encountered
where the search box resetting was clearing user
input and couldn't replicate it. So for now I'm
just removing that if statement.
This commit updates "filter.is_conversation_view" to be true for
"with" operator. This is important because essentially, the "with"
operator lands you in the same view as the channel-topic narrow
or the "dm" narrow i.e., the last unread message of the narrow.
Hence, the "with" narrow should be handled in a similar way
while determining whether to allow automatically marking
messages as read, or displaying the unread banner, etc.
Fixes#30863
The HookPress plugin has been unavailable since July 2019, so it
doesn't make sense to continue supporting these events in the
WordPress webhook integration.
Since we access email through pills,to improve the
visibility on a narrow screen, if the screen width
goes below 'lg_min' or 992px drop the email column from users,
deactivated users, bots, channels, groups using a new classname
'settings-email-column'.
Shubham Padia
Karl Stolley
roanster007
Sahil Batra
Lauryn Menard
evykassirer
Aman Agrawal
Vector73
Anders Kaseorg
Prakhar Pratyush
Niloth P
Alya Abbott
Alex Vandiver
sujal shah