`ensure_basic_avatar_image` and `ensure_medium_avatar_image` are
essentially the same thing, except a size parameter.
So, refactor them into a single function.
This doesn't introduce any functional changes.
Currently the tools/build-docs was slow
because the clean option was rebulding everything.
But this is only required if one wants the left
sidebar to update.
So now set the default to exclude clean and
add clean option only if --clean is passed.
Also a warning is displayed if clean option is
not passed that the left sidebar won't update.
Fixes#17961.
Change the script to python. This is done
for the following reasons.
* It enables us to use the sanity_check.
* Later when we add warning to include
--clean flag we can use the pre-existing
WARNING from zulip_tools rather than using
terminal color codes.
TODO: Currently this script is slow as the
clean option is expensive so instead use only
html by default and clean only if --clean
option is passed.
Part of #17961.
This avoids calling parse_user_agent twice when dealing with official
Zulip clients, and also makes the logical flow hopefully easier to read.
We move get_client_name out of decorator.py, since it no longer
belongs there, and give it a nicer name.
This ensures it is present for all requests; while that was already
essentially true via process_client being called from every standard
decorator, this allows middleware and other code to rely on this
having been set.
Currently, when there are some old starred messages
in a topic, it is possible that some of them won't be
unstarred on doing "Unstar all messages in topic".
This happens when those messages haven't been fetched
yet from the server, and we have no way to verify if
they actually belong to the topic.
This commit fixes that by changing this mechanism to
first fetch all starred messages in the topic from
the server, and then send their IDs back to the backend
to unstar them.
While doing this, we assume that the user does not
have more than 1000 starred messages in that topic.
Note that, we still depend on the local data to
decide whether or not the "Unstar all messages in
topic" option should be shown in the topic popover.
A method similar to the above cannot be used here, because
making server requests before opening the popover
could visually slow down the popover opening.
Using local data for the topic popover would probably
not be a big problem, because users would want to
unstar all messages in a topic probably after noticing
that there are a lot of them, meaning there was at least
one starred message from that topic which was already
fetched, which is sufficient for us to conclude that
we need to show the option in the topic popover.
Fixes#17790
The dialog now shows `stream > topic` instead of
just the topic.
This creates a new tiny widget for this purpose,
which can be reused in other places too.
The `undefined` case is probably very unlikely, but
if the `stream_id` is bad, after the user confirms,
the request will fail on the backend, which could
confuse the user, since there will be no changes to
the starred messages in view.
So, we don't open the confirmation dialog at all in
such cases.
This logic is already thoroughly tested in node tests for
the `MessageListData` class, and the `unmuted_messages`
method of `MessageList` only directly call the corresponding
method of the data class.
There is no need to store this field (and make sure
that it's the same in both the message_list and
message_list_data objects) on message_list objects,
because we can anyways access it easily with
`message_list.data.excludes_muted_topics`, and storing
it just on the data object seems more intuitive.
This also simplifies the constructor for the `MessageList`
class.
We hide a conversation from the top-left corner PM list if
it is-
* A 1:1 PM where the other user has been muted, or
* Huddle where all users have been muted.
* Extract out data as common variable so that it can
be reused in other tests in the future.
* Use consistent dummy user_ids across tests.
* Expand the data set to cover all possible cases-
- 1:1 PMs
- Huddles
- PMs with self
We'll extend this in the future with details on what is configurable,
but this at least ensures we don't have a state where they don't
appear in our documentation at all.
This commit adds code for live updating the role field of person
object on receiving role change event from server and thus enables
live update of role in users list of settings overlay.
This commit adds code to live update page_params.is_moderator and
person.is_moderator on receiving role change event.
The code for changing role to moderator and from moderator to any
other role was added in previous commit.
This commit modifies the code to show "Moderator" correctly for
realm moderators.
As, we show role using settings_config.user_role_values object and
the same is used for showing options in changing role dropdown, this
commit also adds the moderator option in that dropdown and thus allows
the user to change role to moderator and from moderator to any other
role from frontend.
But the code for live updating page_params.is_moderator and
person.is_moderator will be in further commit.
This commit adds 'admins and moderators' option in frontend for
invite_to_realm_policy.
The logic for moderator for checking whether user is allowed to invite
others or not was added in previous commit as we use common helper
user_has_permission for all policies.
But the test user_can_invite_others_to_relam is updated for including
moderator role in this commit.
Since, we now have role value in the person objects sent from server
we can directly use that to set the value of dropdown used for
changing user role, instead of using multiple if-else conditions
for checking is_admin, is_owner, etc.
Since, we now get role value in person objects sent from server, we
can simply user user_role_map to display role in different places
instead of having multiple if-else conditions to check flags like
is_admin, is_guest, etc.
This commit modifies the user objects returned by 'GET /users',
'GET /users/me', 'GET /users/{user_id}' and 'GET /users/{email}'
endpoints to include role field.
We also include role field in the page_params['realm_users'] dict
and in the person object sent in (type="realm_user", op="add")
event.
This will help determine potentail timeout lengths, as well as serve
as a generally-useful log for locations which do not have Smokescreen
enabled.
In service of #17742.
This help mobile and terminal clients understand whether a server
restart changed API feature levels or not, which in turn determines
whether they will need to resynchronize their data.
Also add tests and documentation for this previously undocumented
event type.
Fixes: #18205.
Event of type restart could not be handled properly, because of
its special behavior. For handling this event in most natural way
we recursively call `do_events_register` when restart event is
recieved, based on custom error created for this event.
Testing: Second call to get_user_events due to recursive calling
of do_event_register, is expected to not contain the restart event.
So new test added in test_event_system.py are based on above behavior
of get_user_events.
Fixes: #15541.
There were some changes that were lost/added by mistake
during a rebase of #17707 after #18154 was merged.
Fixes the GIF icon being hidden / displayed incorrectly
with respect to the settings.
These changes were originally part of
67527a2517 but
were lost during the rebase.
These details clarify the roles of `message_id` and `message_ids`, and
should help a great deal in helping clients correctly implement this
critical API endpoint.
Ganesh Pawar
tushar912
Nikhil Maske
Tim Abbott
orientor
Abhijeet Prasad Bodas
Aman Agrawal
Anders Kaseorg
sahil839
Alex Vandiver
Adam Birds
m-e-l-u-h-a-n