Passes the allowed domains for a realm to the frontend, via
page_params.domains. Groundwork for allowing users to add and
remove domains via the admin setting page, rather than via the
realm_alias.py management command.
Previously, no error would display in the UI if the link to the emoji
image was invalid. This would happen for instance if you put in
“invalid” for the Emoji URL. No alerts would pop up but it would refuse
to add the emoji.
This catches the error and displays a notification that looks like
“Failed: Enter a valid URL.”
Fixes#1116.
This restructures the styling for the Zulip settings and
administration pages to minimize use of Bootstrap and use a consistent
styling library for similar elements.
While it is basically a wash in terms of the page's visuals, it will
make our life a lot easier for future work on improving the settings
pages section of the site.
There are no modern browsers that do not have built in JSON parsing
abilities. We do not need $.parseJSON as it now just serves as a call
to JSON.parse.
Adds a new field default language in the zerver_realm model.
This realm level default language will be used as default language
for newly created users. Realm level default language can be
changed from the administration page.
Fixes#1372.
This is controlled through the admin tab and a new field in the Realms table.
Notes:
* The admin tab setting takes a value in minutes, whereas the backend stores it
in seconds.
* This setting is unused when allow_message_editing is false.
* There is some generosity in how the limit is enforced. For instance, if the
user sees the hovering edit button, we ensure they have at least 5 seconds to
click it, and if the user gets to the message edit form, we ensure they have
at least 10 seconds to make the edit, by relaxing the limit.
* This commit also includes a countdown timer in the message edit form.
Resolves#903.
We were using data for both the request and response data in
$(".administration").on("submit", "form.admin-realm-form".
Left the request data as data to be consistent with the rest of the
file, renamed the response data to response_data.
This is controlled through the admin tab and a new field in the Realms
table. This mirrors the behavior of the old hardcoded setting
feature_flags.disable_message_editing. Partially resolves#903.
Following strings are marked translatable:
- All strings which are passed to `button.text` or which affect the
text of buttons.
- All strings passed to `placeholder`.
- All strings passed to `compose_error`.
Fixes#969
Saving the organization settings form in the administration did not
work due to a trivial form name mismatch caused by following
revisions: 472898c and 58aba59.
The previous code was using the same codepath as for real users, which
was unfortunate in two ways:
* It hit the wrong endpoint on the server and thus failed
* It popped up the "remove a user prompt" which described a bunch of
things not relevant to bots.
Because the `owner` field had the class email, we were sending the
concatination of the user and owner email addresses as the email
address in the reactivate requests.
Fixes#243.
One of the alert rows Was missing a "-status" at the end.
While we're fixing this, make it more robust by adding .expectOne().
(imported from commit 8cb0a560701e2ee48f78471ef8fe5cfa060782af)
Include new field on Realm to control whether e-mail invitations are required
separately from whether the e-mail domain must match.
Allow control of these fields from admin panel.
Update logic in registration page to use these fields.
(imported from commit edc7f0a4c43b57361d9349e258ad4f217b426f88)
Previously, while you'd get the event saying you'd been knighted,
which would make the Administration tab visible, clicking on the tab
would error out because the admin page HTML was never sent over on
page load (since you weren't an admin at that point).
(imported from commit 90ad351533515bebece630d67baf4b142d320754)
Always render the Administration menu item from the back end, but
make it be hidden by default until the page is loaded. Then, the
client can un-hide it as needed.
(imported from commit 66e607eec430d7179b4d5ac3f5416f5be8ac26c9)
There was a bug where you could not reactivate a user after
doing another user-based action on the page, because we weren't
clearing the active_user_row class on the previous row, and
then $(".active_user_row").find('.email').text() would be a
concatenation of two user emails and cause a "No such user!"
error.
(imported from commit c867d3bc0855e02b17b9553e1924926c2dd50e56)
It was confusing, because it has different meaning that being
the opposite of active_user_row.
(imported from commit df190afb2d9bccf9790c7373802b16ff6da2f2cb)
Vladislav Manchev
Steve Howell
umkay
Brock Whittaker
Rishi Gupta
Umair Khan
ukhan
Rag Sagar
Tim Abbott
Vishnu Ks
Aristeidis Fkiaras
Tim Abbott
David Roe
Steve Howell
Waseem Daher
Jessica McKellar