This is a feature of GNU readlink that isn't in the BSD readlink
found on macOS.
For using this and other GNU coreutils features in our scripts in
general, we could use a solution like mobile's tools/lib/ensure-coreutils.sh
to get GNU coreutils on the PATH -- check if it's there already,
if not then try to find a Homebrew install of it and use that, if not
then print a helpful message.
But even then there'd be a bootstrapping problem of how to find
ensure-coreutils.sh . That involves exactly the same problem as we
have for finding git-tools.sh in these lines. So in fact in mobile
for the task of finding ensure-coreutils.sh in the first place, we
do without `readlink -f` anyway.
The one consequence of this behavior-wise is that if you make a
symlink somewhere that points directly at that script (say in your
`~/bin/`), and try to run it using that symlink, it won't work.
(It'll still work just fine if there are symlinks somewhere higher
up in the paths involved -- just not for the script itself.)
An ideal CLI program really should support that, I think, but
lacking a better idea, this seems an acceptable compromise.
Requesting external images is a privacy risk, so route all external
images through Camo.
Tweaked by tabbott for better test coverage, more comments, and to fix
bugs.
As of now, editing a widget doesn't update the rendered content.
It's important to ensure that existing votes or options added later on
don't get deleted when rendered.
This seems more complex than it's worth.
For now, we just prevent edits to widgets.
This commit makes the UI clearer that editing widgets isn't allowed.
See also:
https://github.com/zulip/zulip/issues/14229https://github.com/zulip/zulip/issues/14799Fixes#17156
Introduce a new class "table-sticky-headers" in the settings
and organisation settings HTML table tags and it is used
to make the table headers fix at the top. This commit also
add the background-color and hover properties to the
settings and organisation settings table to make them look
similar to the recent_topics_table.
This commit fixes a rare flake which was most probably
caused when we clicked on the `Check All` button, and
we instantly cleared the filter when it was still marking
the user `checked`, which nullified the effect of clicking
on `Check All` button.
`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.
Anders Kaseorg
Greg Price
Alex Vandiver
Wesley Aptekar-Cassels
Ganesh Pawar
Nikhil Maske
Vishnu KS
Aman Agrawal
Riken Shah
tushar912
Tim Abbott
orientor
Abhijeet Prasad Bodas
sahil839
Adam Birds