This lets us remove this fairly ugly user interface widget, which was
inconsistent with the rest of the settings UI.
The implementation is approximately the same as before I just migrated
"Add new custom profile field" form into a modal, status update
notifications about these forms will be displayed inside their modal,
and made some little design changes as discussed on CZO.
Fixes part of: #21634
This is a preparatory commit for commit "Edit custom profile
field form into modal."
Above mentioned commit will use class input-group instead of
control-group so here we are already changing it to input-group.
There is no control-group class to hide/show in custom profile fields
list instead there is input-group class, kind of little typo I guess
from this 9e343f1 commit.
We now send a new user_topic event while muting and unmuting topics.
fetch_initial_state_data now returns an additional user_topics array to
the client that will maintain the user-topic relationship data.
This will support any future addition of new features to modify the
relationship between a user-topic pair.
This commit adds the relevent backend code and schema for the new
event.
Updates documentation to include information about user presence
objects with `aggregated` key (instead of the user's email) where
appropriate.
Also, cleans up spelling, grammar and formatting errors in the
descriptive text for these objects / endpoints.
`render_table` calls itself recursively when it finds nested
`additionalProperties` (i.e. nested objects) in response schema,
to render their properties.
This fixes `render_table` to call `render_desc` along with
calling itself, to render the description of the nested
`additionalProperties` as well.
Spamming the `s` shortcut when hovered on an image can cause the
tooltip to be displayed at the top left corner. This is caused by
original reference of the tooltip being removed from DOM. The
re-rendering is happening so quickly that tippy is not able to hide
the tooltip in time.
We separate the permission checks for content and topic edits
by changing the can_edit_topic_or_content to can_edit_topic
and use it only for checking topic edits and check content
edits separately in check_update_message itself. There is no
change in behavior as of this PR, there will be more changes
as per #21739.
This is a prep commit for #21739. The permission checks for
them are essentially separate except the one that message
sender is allowed to edit content and topic irresepctive of
edit_topic_policy setting, and this will too be changed in
future commit and so it will be better to have these checks
separate for readability.
We can also probably create a new function for checking content
edits but currently we only check the sender is same as the use
who is editing and it does not make sense to have a separate
function for just one check. We can do so in future in case we
do some more refactoring for #21739.
Currently locally echoed messages are checked using locally_echoed
field in get_editability. Previously it used local_id field but it
was changed in 0e25055c1d. Tests for get_editability used local_id
till now, but the tests were passing as the message was not allowed
to edit due to time limit. This commit fixes the tests to use
locally_echoed field instead.
The presence of `auto_signup` in idp_settings_dict in the test case
test_social_auth_registration_auto_signup is incompatible with the
previous type annotation of SOCIAL_AUTH_OIDC_ENABLED_IDPS, where `bool`
is not allowed.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
In 3b4f8cc85b,
we added support to `auto_signup`, but this field was not defined in
`SAMLIdPConfigDict`, causing mypy type error in
`SAMLAuthenBackendTest.test_social_auth_registration_auto_signup`.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Uptil now only space was used as a word separating character when
searching streams. This meant that searching for "xyz" would not turn
up a stream named "stream-xyz" as one would expect.
Since -, _ and / are likely to be used as word separators in stream
names, these 3 are added as word separators for streams. The utility
function `filter_by_word_prefix_match` is refactored by adding an
optional `word_separator_regex` argument.
Fixes: #19700.
We construct model instances in the import tool solely for the purpose
of serializing them with the `model_to_dict` helper that returns a
dictionary. Passing `float` to these models' DateTimeField is not
accepted by the type checker. Modifying the dictionary instead avoids
this typing issue.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
We pass the realm_emoji dict to notify_realm_emoji instead
of computing it in notify_realm_emoji itself, because its
caller functions will require the dict in further commits
for creating RealmAuditLog entries.
This commit also renames the legacy event variable to
legacy_event from event because same event is sent
twice if we keep only single variable and change its
value. This was happening because the event value was
changed when the first send_event was actually executed.
We pass the realm_linkfiers list to notify_linkifiers instead of
computing it in notify_linkifiers itself, because its caller
functions will require the list in further commits for creating
RealmAuditLog entries.
Since we not allow enabling public access on limited plan realms,
we set the enable_spectator_access setting to False when downgrading
to a limited plan. Setting is still shown in the UI but it is
disabled.
We also show upgrade banner along with disabling the setting.
We also hide the web-public stream creation policy dropdown in
such case as we do when enable_spectator_access is False.
This commit adds code to send stream creation and peer add events
when stream is changed from private to public. These events are
only sent to users who are not susbcribed to the stream and are
not realm admins as subscribers and realm admins already have
the stream data. This will update the stream data with clients
and will remove the need to reload to view the modified stream.
Fixes#22194.
Since we updated the bot edit form opened from "Personal"settings
section to be same as that opened from organization settings
section, we do not require this file anymore.
Fixes: #22033.
We now allow admins to edit configuration of outgoing webhook
and embedded bots from the edit form in "Organization" settings
section. In next commit we would deduplicate the code to use same
modal in both "Organization" and "Personal" settings sections.
This commit adds option to change bot avatar from the admin bot-edit
form. This is a prep commit for making bot edit forms in both
"Personal" and "Organization" settings sections same.
We do not use dialog_widget.submit_api_request now since we need
to pass processData and a couple of other parameters with the
request since we are sending a file also as part of data. And
also we add code to show loading spinner which was previously
handled by submit_api_request.
We now show confirmation modal when deactivating bot from
personal settings section. Since we have added deactivate
option in the bot-edit modal opened from admin settins page
and we would replace the modal opened from personal settings
with that modal, it would be good to show the modal consistently.
This commit also moves confirm_bot_deactivation function from
settings_users.js to settings_bots.js to avoid cyclic dependencies.
We move show_edit_bot_info_modal function to settings_bots.js
as this code will be used for modals opened from the personal
bot settings section as well when we would make both the modals
same and this will help us in avoiding cyclic imports.
The "for" attribute of label of full-name input in
admin_human_form.hbs was set to "full_name" which is already the
ID of full name input in profile section and not the input in
this form.
As a result, the modal was being closed on clicking on that
label. This commit for now just updates the "for" attribute
for full-name input to the correct ID.