Long labels like "Deactivate xyz" or "Delete xyz" can
be confusing for translators and it can also create bad
strings that can end with like 4 long words in German.
It is better to have the simple options like "Confirm"
and "Cancel". This commit fixes this issue by changing
the text to "Confirm" in their respective template files.
Fixes#17926.
Long labels like "Unstar messages" can be confusing for
translators and it can also create bad strings that can
end with like 4 long words in German. It is better to
have the simple options like "Confirm" and "Cancel".
This commit fixes this issue by changing such text
to "Confirm" as default in confirm_dialog_modal.
Part of #17926.
Tippyjs automatically places it to bottom.
NOTE: placement of tooltip is changed from 'bottom' to `auto`.
Custom css was set here to avoid tooltip being partially hidden
on small screens. This change automatically takes care of it
by showing the tooltip on right side of message_reaction on
small screens if it is partially hidden from the left or
vice versa.
We no longer need to add_tooltip_to_left_panel_row since
tippyjs.delegate will automatically do that for us.
Tippyjs automatically places it to left on small widths and bottom
for large widhts.
We don't want to import tippyjs module here
along with its dependencies, so we just copied
over tippyjs defaults here. They should be
work fine for /stats page even if we decide to change
defaults for the app in tippyjs and forget to do
it here.
Hiding and instantly showing a modal causes a race condition in
Bootstrap since `hide` and `show` calls are asynchronous.
See https://getbootstrap.com/docs/4.0/components/modal/#methods
Instead, use `overlays.open_modal` which prevents background
mouse events when a modal is present.
This prevents a user from maybe accidentally clicking on another deactivate
button while a modal is present. This also prevents a black screen
caused due to this race condition.
And since a user can't click on the button while the modal is present,
it doesn't make sense to hide it before showing it.
So, remove the `hide` call.
Fixes#17297
We keep the error message same for all cases when a user is not
allowed to subscribe others for all values of invite_to_stream_policy.
We raise error with different message for guest cases because it
is handled by decorators. We aim to change this behavior in future.
Explaining the details in error message isn't much important as
we do not show errors probably in API only, as we do not the show
the options itself in the frontend.
We keep the error message same for all cases when a user is not
allowed to create streams for all values of create_stream_policy.
We raise error with different message for guest cases because it
is handled by decorators. We aim to change this behavior in future.
Explaining the details in error message isn't much important as
we do not show errors probably in API only, as we do not the show
the options itself in the frontend.
We keep the error message same for all cases when a user is not
allowed to invite others for all values of invite_to_realm_policy.
We raise error with different message for guest cases because it
is handled by decorators. We aim to change this behavior in future.
Explaining the details in error message isn't much important as
we do not show errors probably in API only, as we do not the show
the options itself in the frontend.
This color picker did not hide even after exiting stream settings.
Fix by adding logic to auto-close any open color pickers when closing
stream settings.
Tweaked by tabbott to use the existing on-close handler, which is
important if one clicks outside the modal or otherwise navigates
another way.
Fixes#17334.
This makes it much more clear that this feature does JSON encoding,
which previously was only indicated in the documentation.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Commit d84727ce7f (#17970) slightly
decreased the apparent size on some platforms depending on which font
was in use before, and some users complained that it was a bit hard to
read. Based on experiments with multiple platforms and monitors and
resolutions, this appears to be a good compromise that increases the
rendered height without increasing the width more than necessary.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This fixes the API documentation tests following recent changes, but
isn't the right solution -- we probably want to change the API itself
to not require this strange JSON-encoding-of-a-string.
But this is necessary to have CI pass.
When the user's full name is long, the full name + `(you)`
in the buddy list starts to truncate, but when hover, the
tooltip displays the full name but not `(you)`.
This commit fixes this by adding `(you)` in the tooltip.
"Narrow to topic" option do exactly the same thing as
clicking the topic name does. So therefore decided to
remove that option from the popover. This commit removes
all the code related to .narrow_to_topic including it's
template code, on click event and a function used for it.
Fixes#18027.
We should disable the stream message retention dropdown for owners
of realm with limited plans. The behavior is correct in other
places, will also just explain the behavior in other places -
For limited plans-
1. Owners can see the dropdown in stream creation form but others
cannot, and in stream privacy modal, the modal is visible to all.
But the modal is disabled in all cases since the realm is on
limited plan.
For standard plans -
1. Owners can see and edit the dropdown in both stream creation
form and stream privacy modal. Non-owners cannot see the modal
in stream creation form but they can see the dropdown in stream
privacy modal and it will be disabled.
Thus, the only change in this commit is to disable the dropdown
in the stream creation form for owners and in limited plan realms.
The other behavior mentioned above was already there.
The comments explain in some detail, but basically we were displaying
the types for booleans incorrectly, and the types for strings in a
somewhat confusing fashion. Fix this with comments explaining the logic.
Using JSON dumping also results in our showing strings inside
quotation marks in our examples, which seems net helpful.
Thanks to ArunSankarKs for finding where we needed to change the
codebase.
Fixes#18021.
There is a bug where invite button is not enabled again after sending
invite is failed, but it is enabled on successful completion of invite.
I am not able to figure out why it is behaving differently in success and
error cases, even when the code to enable button is in complete() function
and it is called in both the cases.
But, I can confirm that adding .button('reset') fixes this bug as button
is disabled using the .button('loading') call and this is according to the
bootstrap docs only. But the bootstrap docs mention that the .button(string)
method has been removed in v4.0 as mentioned here
https://getbootstrap.com/docs/3.4/javascript/.
So, as we would want to avoid using depereceated or removed methods, this
commit simply changes the code to disable the button and set the loading
text using simple jquery and this also solves the above mentioned bug.
The moderator role was not included in the tests for create_stream_policy
and invite_to_stream_policy. The tests are do_set_realm_property_test
in test_events.py and do_test_realm_update_api in test_realm.py.
This should have been added for create_stream_policy in 5b32dcd and
in 5b32dcd for invite_to_stream_policy, but was missed by mistake.
There was a bug where invite users link is shown in the Invitations
section of settings overlay, irrespective if the user is allowed to
invite or not based on the realm settings. So here we just use the
'can_invite_others_to_realm' field of page_params, that was added in
previous commit itself to hide the link accordingly.
Also added the code in server_events_dispatch.js for this field.
Though it doesn't do live update when the overlay is opened similar
to other policies like create_stream_policy, but it ensures that the
visibility of link is correct if the overlay is opened after the
settings has changed.
We should probably do the complete live update in future of the
elements related to such realm settings.
This commit adds backend code for passing can_invite_others_to_realm
field to clients using the fetch_initial_state_data in the page_params
object.
Though this field is not used by webapp as of now, but will be used
to fix a bug of incorreclty showing the invite users option in
settings overlay in the next commit.
We add moderators and full members option to invite_to_realm_policy
by using COMMON_POLICY_TYPES and use can_invite_others_to_realm helper
added in previous commit. This commit only does the backend work,
frontend work will be done in separate commit.
This commit adds can_invite_others_to_realm helper which will be used in
further in next commit when invite_to_realm_policy will be modified to
support all values of COMMON_POLICY_TYPES.
It is important for this commit's correctness that
INVITE_TO_REALM_POLICY_TYPES was initialized to use the same values.
This commit replaces invite_by_admins_policy, which was a bool field,
with a new enum field invite_by_realm_policy.
Though the final goal is to add moderators and full members option
using COMMON_POLICY_TYPES, but this will be done in a separate
commit to make this easy for review.
Tim Abbott
Anders Kaseorg
Nikhil Maske
Aman Agrawal
Tim Abbott
Ganesh Pawar
sahil839
yasiruRathnayaka97
Riken Shah
m-e-l-u-h-a-n
Sumanth V Rao