Pasting a generated password into the password box triggers neither a
change event (until the password box is unfocused) nor a keyup event.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
It appears not to have been useful and makes it marginally harder to
reason about how module resolution works. Paths to static content in
node_modules should be resolved through Webpack instead.
(This node_modules symlink was originally created in the pre-webpack world
where all of our static asset paths were based in static/.)
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
Long-term, we want this flow to do a full re-authentication, but this
makes the frontend consistent with the backend and fixes a confusing
bug where submitting the form ended up adding a weird `?password=`
thing to the URL, in addition to not working.
Fixes#12200.
Fixes#12251.
Previously when disabling name changes in server settings, instead
of realm settings, the name edit button did not get disabled.
Changing name resulted in a message stating `no changes made`.
Fixes#12132.
Realm setting to disable avatar changes is already present.
The `AVATAR_CHANGES_DISABLED` setting now follows the same
2-setting model as `NAME_CHANGES_DISABLED`.
This is useful when syncing avatars from an integrated LDAP/active
directory.
The upload avatar and delete avatar buttons are hidden if avatar
changes are disabled and the user is a non-admin.
If the user has a gravatar set, then the user will not be able to
upload an image as their avatar if avatar changes are disabled.
Part of #12132.
This is a small patch to fix the error message an admin would receive if
they tried to change bot info and owner from the "bots" setting of the
organization settings panel.
Apparently, this has been broken since
dee4e3fb89, due to the beforeSend code
here overriding the default beforeSend function that sets the CSRF
token. The correct fix was actually to just run the relevant code
directly before the channel.patch call.
Fixes#11938.
This renames references to user avatars, bot avatars, or organization
icons to profile pictures. The string in the UI are updated,
in addition to the help files, comments, and documentation. Actual
variable/function names, changelog entries, routes, and s3 buckets are
left as-is in order to avoid introducing bugs.
Fixes#11824.
The beforeSubmit function was a feature of the jquery-form plugin that
we removed months ago; the appropriate similar feature of jQuery's
built-in AJAX library is beforeSend.
Users can preview their profile from user settings. If user
open preview profile modal from user settings, then closing
preview profile modal should redirect them to settings modal
again (since probably they want to keep editing).
This commit fixes above issue.
This makes it possible it include our standard markdown formatting in
one's custom profile fields, allowing for links, emphasis, emoji, etc.
Fixes#10131.
While we're at it, we remove the JSON parsing that was part of the
user field code path, since this function isn't responsible for
rendering user fields.
Apparently, our custom profile fields feature was parsing the "user
list" field type in multiple places, and ignoring the results in one
of them. That code had been causing some confusion; the correct
solution is to just delete it, since the template rendering process
ignores that value for this field type.
A bug caused background links to open even when a modal in the user
settings overlay was active in the foreground. This commit fixes this
by disabling mouse events for the background when the modal is active,
and restoring them as soon as the modal starts closing.
Fixes#10654.
New user avatar width is not maximum when user upload
new image. Because wrong html element is accessed for
setting value of image src attribute.
This commit removes these code from success of ajax call,
cause we already handle this in event `user_events - avatar_url`.
In user type custom field, field value is list of user ids. We weren't
converting list to json object in update event payload. This throws
error in frontend, cause we store stringify representation of custom
field value. Therefore, after update event is recieved field-value-
type gets updated to array from string which throws json parsing error.
This commit add FIELD_TYPE_CHOICES_DICT to page_params and replace
FIELD_TYPE_CHOICES.
FIELD_TYPE_CHOICES_DICT includes all field types with keyword, id
and display name. Using this field-type-dict, we can access field
type information by it's keyword, and remove all static use of
field-type'a name or id in frontend.
This commit also modifies functions in js where this page_params
field-types is used.
The JavaScript click handler for this feature was fragile in a way
that would break with upcoming changes to how we display the X
element. We clean this up with a replacement implementation that
should be much less fragile.
This commit prepares the frontend code to be consumed by webpack.
It is a hack: In theory, modules should be declaring and importing the
modules they depend on and the globals they expose directly.
However, that requires significant per-module work, which we don't
really want to block moving our toolchain to webpack on.
So we expose the modules by setting window.varName = varName; as
needed in the js files.
Even when admin removes all custom fields from org, custom
fields header "Profile" doesn't get removed.
Render header "Profile" whenever custom fields data get changed.
The function `settings_account.add_custom_profile_fields_to_settings`
called twice, which resulted in two templates objects being
rendered.
The function also didn't check whether settings overlay was open or
not when processing new events, and thus would throw an "undefined"
error if a custom profile field was editing while the overlay was not
open.
Fixes#9668.
This is preparation for an upcoming refactoring where we pass a bot
ID, not the email/api_key, into the zuliprc generation functions in
the bots code path.
Whenever custom fields templates get rendered within user account
settings, on-change event listener wasn't get created. Cause
event listener wasn't set properly.
The "Short/Long Text" option for custom profile fields wasn't properly
capitalized (i.e. "Text" should have been all lowercase), and also
wasn't properly tagged for translation.
For the sake of consistency, the change to proper capitalization has
also been applied to the models and any tests involving this feature.
Due to a bug in Django, it complained about the models having changed
and thus not being consistent with the migrations. That isn't actually
true (since the database stores the numeric values for each key), but
the migrations have been modified to avoid this error. This does not
affect the migrations' behaviour in any way.
Thomas Ip
Anders Kaseorg
Anders Kaseorg
Yashashvi Dave
Tim Abbott
Shubham Padia
Hemanth V. Alluri
Ben Muschol
Shubham Dhama
Harshit Bansal
Aditya Jain
Rishi Gupta
Armaan Ahluwalia
Robert Hönig
Yago González