Buttons which change the content in the compose textarea were so far
enabled even in preview mode, and would work, but those changes would
not be reflected in the visible preview. This is extremely confusing,
and can lead to the possibility of a user accidentally changing the
content of the compose textarea while previewing, and sending that.
Now we disable those buttons in preview mode, both when composing a new
message and when editing an existing one. We still show the tooltips,
but grey them out and make them unclickable.
Fixes: #20962
Fixes#25744
By rendering the emojis after initializing the simplebar container,
the rendering time is decreased by ~30% as observed at 6x CPU
cooldown on mac i7.
This commit adds the follow icon to the right end
(before the three-dot menu icon) of the topic list item
for followed topics.
The icon replaces '@' instead of showing both the '@' and "Follow"
icons in the case of unread mentions, as users don't care if they
are following a topic if they've got unread mentions there.
In a muted stream, the text color of followed topics in the topic list
is set to be similar to that of unmuted topics.
The reason is that the followed topic has a tier of interest above
being unmuted, so it shouldn't stay faded in the topic list.
This commit adds Tippy tooltips to the edit pencil button
in the user profile. Now, when a user opens another user's
profile, they will see the tooltip 'Manage user', and when
they open their own user profile, they will see the tooltip
'Edit profile'.
This commit moves the bot icon to the left of the name in the user
profile and adds a margin-left and margin-right to the name to ensure
there is enough space between the icon, name, and edit pencil.
This commit redirects the edit pencil in the user profile modal to
the 'manage user' tab whenever a user with permission to manage
other users via the user profile opens another user's profile.
However, we still want to redirect the edit pencil to
'settings/profile' if the user opens their own profile. The user
management permission is granted if the user is an admin or the
owner of the bot. However, we do not want system bots to have
access to the edit pencil or the 'manage user' tab. Therefore,
a new variable called 'can_manage_profile' has been introduced
to manage all these permissions, and the CSS has been updated
accordingly.
To redirect to the manage user tab without opening another modal,
I have extracted the toggler. This toggler will store the
component, and if the edit pencil button is clicked, we can use
the goto function to redirect to a different tab.
Changed the id names of both the edit pencil icons to explain
better of what they do.
This commit disables the "Deactivate User" button inside the
"manage user" tab in the user profile modal. Additionally, a
tooltip is applied to the button by wrapping it inside a div
with the tooltip applied.
This commit fixes the inconsistent height of the user profile when
switching tabs. We now have four tabs in the user profile:
"Profile," "Streams," "User Groups," and "Manage User." However,
the "Manage User" tab has footer buttons that need to remain
sticky at the bottom without changing the overall height of
the modal.
To achieve this, we wrapped the footer inside a div element and
assigned it a class called "manage-profile-tab-footer." The main
body of the user profile is given a height of 60vh. However, for
the "Manage User" tab, we decreased this height to 52vh and
allocated the remaining 8vh height to the div element to
accommodate the footer buttons. This ensures that the user
profile maintains consistent height when switching between tabs.
However, we have a 1px border in the footer, so to ensure that
the height is consistent, we reduce the height of the modal
content by 1px, making it calc(52vh - 1px).
To implement this, CSS code was added to the "popover.css" file
and accessed through the class specified in the "user_profile.js"
file.
The default padding of the buttons inside footer is 20px, but
with the above solution on large screens the buttons are not
aligned properly, so removed the padding top and bottom
and instead applied the flex box and property to align the buttons.
This commit migrates the "Manage Bot" modal to the user profile modal,
with the same explanation as in the "Manage User" modal commit.
However, in this commit, we changed the permission of the "Manage User"
tab so that non-admin users can also see the "Manage Bot" tab if they
have created the bot. Additionally, since we can't make changes to
system bots, we check if the bot is a system bot and hide the
"Manage Bot" tab accordingly.
Fixes: #21806
This commit migrates the "Manage User" footer buttons to the user
profile modal. We made this change because we don't want the buttons
to scroll with the content; instead, we want them to be sticky at
the bottom at all times. Therefore, we moved the buttons to the user
profile modal.
This commit migrates the "manage user" modal to the "Full Profile"
modal. Refactored the show_edit_user_info_modal function since
earlier, we used to have a separate "Manage User" modal.
Consequently, we checked if we were coming from the
user_info_popover and then built the dialog widget accordingly.
However, with this new change, we no longer need to build the
dialog widget. Therefore, removed that part and now just pass
the container of the 'user profile modal' to get the content.
Previously, for deactivation, we used to have a separate dialog
widget. But now, since we have a dedicated function to handle
this case, refactored the deactivation code to use the
'confirm_deactivation' function.
Additionally, created two new functions to handle the loading
spinner. Since we will need these functions in the future for
the "Manage Bot" modal, we marked them as exported.
"Since we do not want to show the 'Manage User' tab to the user
looking at their own profile, in the 'can_manage_user' function
that we use to render the 'Manage User' tab, we check if the user
profile popover belongs to the same user. If it does, we set it to
'false' instead of 'true,' ensuring that the 'Manage User' tab is
not visible.
Added a new tab in the user profile modal 'manage user'.
Fixes: #21806
With the previous commits, we have now implemented the subscribe
widget with a separate heading. However, the font size and the gap
of both the heading of the widget and the streams list look bad,
so this commit fixes that.
Since the heading of both the widget and the list have the same CSS,
instead of duplicating it, we used the same class for both and
reduced the font size.
This commit adds a reset function for the subscribe widget so that
whenever someone subscribes to a stream from the dropdown, after
the subscription, the dropdown will return to its initial state
with no stream selected. Additionally, it will display a label with
the subscribe button disabled and a tooltip.
This commit adds a tippy tooltip to the subscribe button in
the user profile. We show this tooltip only when there is no
stream selected and the button is disabled. However, on any
change, we enable the button and hide the tooltip.
This commit adds a subscription widget to the user profile,
including the logic to prevent non-admin users from seeing the
subscription widget of other users. Additionally, as it is not
possible to subscribe generic bots to streams, and the user should
not be a deactivated user, we check for these conditions before
displaying the subscription widget.
To ensure that the alert for both subscribing and unsubscribing
appears on top of the subscribe widget, changed the location of
the alert to be displayed at the top.
Additionally, considering that no stream will be initially selected,
we have made the decision to disable the subscribe button. Once the
user selects a stream, we will enable the subscribe button
accordingly.
Changed the add_user_ids_to_stream function inside subscriber_api.js
to support self subscribe also, so that we don't have to duplicate the
logic in user_profile.js
Created a separate file for the subscribe widget called
user_profile_subscribe_widget.hbs.
Fixes: #18883
Adds a section to the demo organizations help center article about
configuring an email and password for demo organization owners.
For demo organization warning banners about needing to configure
an email, add a link to the new section in the help article.
Also, adds a related articles section to the help center article,
and updates the current draft text for changes in how the demo
organization feature is being implemented.
To reduce extra work for translators, make text for warning banners
and tooltips in demo organizations when the organization owner has
not configured an email address consistent.
Rename existing shortened references to demo organizations, like
`is_demo_org` or `demo-org-warning`, that have been used in the
codebase so far and replace them to be like the `models.py`
variable: `Realm.demo_organization_scheduled_deletion_date`.
This commit rename the existing setting `Who can invite users to this
organization` to `Who can send email invitations to new users` and
also renames all the variables related to this setting that do not
require a change to the API.
This was done for better code readability as a new setting
`Who can create invite links` will be added in future commits.
Earlier option to create new invitations in right_sidebar,
gear_menu and invitations panel does not get live update
when the setting `who can invite others to realm` is changed.
This commit make changes to do live update.
Creates process for demo organization owners to add an email address
and password to their account.
Uses the same flow as changing an email (via user settings) at the
beginning, but then sends a different email template to the user
for the email confirmation process.
We also encourage users to set their full name field in the modal for
adding an email in a demo organization. We disable the submit button
on the form if either input is empty, email or full name.
When the user clicks the 'confirm and set password' button in the
email sent to confirm the email address sent via the form, their
email is updated via confirm_email_change, but the user is redirected
to the reset password page for their account (instead of the page for
confirming an email change has happened).
Once the user successfully sets a password, then they will be
prompted to log in with their newly configured email and password.
Because demo organization owners do not initially have an email
set, some of the personal and organization settings in the web-app
UI should be disabled/hidden until the owner configures an email
address for their account.
Disables the form input elements in the invite user modal if the
user's email is not configured. Also displays a tip at the top of
the modal to let the user know why the form is disabled.
Because demo organization owners do not initially have an email
set, some of the personal and organization settings in the web-app
UI should be disabled/hidden until the owner configures an email
address for their account.
Disables the dropdown for changing the user's email address visibility
in the account & security tab of the personal settings overlay until
the user configures an email address.
Because demo organization owners do not initially have an email
set, some of the personal and organization settings in the web-app
UI should be disabled/hidden until the owner configures an email
address for their account.
Disables configuring organization authentication methods in the
organization settings overlay until the user has configured an email
address. Adds a tip at the top of the authentication methods tab to
indicate why the authentication method checkboxes are disabled.
Because demo organization owners do not initially have an email
set, some of the personal and organization settings in the web-app
UI should be disabled/hidden until the owner configures an email
address for their account.
Disables the show/change API key button in the account & security
tab of the personal settings overlay if the user's email address
is not configured. A tooltip is shown when hovering over the disabled
button explaining why the feature is disabled.
Because demo organization owners do not initially have an email
set, some of the personal and organization settings in the web-app
UI should be disabled/hidden until the owner configures an email
address for their account.
Updates showing the password change field in the account & privacy
tab of the personal settings overlay to check if the user's email
being configured (to cover the demo organization case) and if the
organization has enabled password authorization.
yogesh sirsat
Aman Agrawal
Daniil Fadeev
Prakhar Pratyush
palashb01
Lauryn Menard
evykassirer
Ujjawal Modi