For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a second step, split
out the subset of fields that pertain to the entire realm.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a first step, split
out the subset of fields that pertain to the current user.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit removes the 'page_params.development_environment' guard
for the setting 'send_stream_typing_notifications' and makes it
available outside the development environment.
This commit fixes the alignment of account-alert-notification-banner
by using a new classname 'account-alert-notification' for this specific
banner, removed the default margin-top and margin-left from this banner
which is set to all other banners, and Aligned the banner with
vertical-align property set to middle.
To left-align this specific banner when the email is long enough
to wrap to the next line removed the margin-left and used a new
classname 'account-settings-heading' for the accounts heading,
and gave a margin-right of 10px to ensure that the notice banner and
the heading have enough space between them, when the email is short.
If the email is long enough to wrap to multiple lines, then the gap
between the email input field and the banner is too low. To adjust
this, set the margin-bottom to 10px.
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 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 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.
Added a 'Deactivate Organization' button inside the
'Personal Settings > Account & Privacy'. This button only appears
when the organization owner is the only user present. To verify this,
I used the 'get_active_human_count' function from the 'people.js'.
To remove duplication, a function has been created inside settings_org
file to handle the click event for the two buttons present inside
personal_settings and organization_settings that perform the same
action of deactivating organization. The click handler is defined in
the click_handlers.js file, which calls the dialog for deactivating
the organization. Previously, the error used to appear at the top of
the organization_settings, but now it appears inside the dialog box
itself.
To remove the duplication of two buttons having the same IDs,changed
the Id `deactivate_realm_button` to a className.
Fixes: #24105
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
David Rosa
Anders Kaseorg
Sahil Batra
Prakhar Pratyush
palashb01
Lauryn Menard