Sometime in the deep past, Zulip the GET /users/me/subscriptions
endpoint started returning subscribers. We noticed this and made it
optional via the include_subscribers parameter in
1af72a2745, however, we didn't notice
that they were being returned as emails rather than user IDs.
We migrated the core /register code paths to use subscriber IDs years
ago; this change completes that for the endpoints we forgot about.
The documentation allowed this error because we apparently had no
tests for this code path that used the actual API.
We remove the "full_name" and "account_email" fields from the response
of 'PATCH /settings' endpoint. These fields were part of the response
to make sure that we tell that the parameters not present in response
were ignored.
We can remove these fields as 'ignored_parameters_unsupported' now
specifies which parameters were ignored and not supported by the
endpoint.
We add "ignored_parameters_unsupported" field to the response object
of 'PATCH /settings' endpoint. This will contain the parameters
passed to the endpoint which are not changed by the endpoint and are
ignored.
This will help in removing the other fields like "full_name" from
response which was essentially present to specify that only these
fields were updated by the endpoint and rest were ignored.
We will also change other endpoints to follow this in future.
We migrated the main method in the API bindings project to
get_subscriptions some time ago, and apparently neglected to change
the API documentation as well.
Earlier, the `stream_header_colorblock` wasn't properly styled
with the dropdown toggle button from a UI perspective. This was so
because they had a few space between them due to inconsistencies
in their border radius.
This commit adds an border-radius property to the move topic
dropdown toggle button to eliminate the above issue and
improve it's overall look.
Earlier, the `stream_header_colorblock` wasn't properly styled
with the dropdown toggle button from a UI perspective. This was so
because they had a few space between them due to inconsistencies
in their border radius.
This commit adds an border-radius property to the message_edit
dropdown toggle button to eliminate the above issue and
improve it's overall look.
Previously, the message edit `stream_header_colorblock` used
to incorrectly extend down till the textarea which caused
the UI to be buggy.
Fixed this by adding a `margin-bottom` property similar to
what we did in case of Move topic dropdown.
This minor change accidentally was missed within commit
7c25bd1aa8.
This is more robust towards reruning failed tests (which ran
partially and added some events to a queue before failing).
The tearDown code was added in 571f8b8664.
Previously, Everytime the user triggers the Stream create UI
by pressing the `Create stream` button, the
`create_handlers_for_users` function would reinitialize which
created duplicate event handlers for its elements.
This could lead to multiple click events being triggered over the
same element.
One such example was filed as #19255, where the click event was
triggering twice and hence the "Copy from stream" dropdown
would remain folded (closed).
Fixed this by - Initializing the `create_handlers_for_users` function
within the main `set_up_handlers` function, which is triggered only
once upon the opening of Stream create UI.
Fixes#19255.
This allows for greater flexibility in values for "environment," and
avoids having to have duplicate definitions of STAGING in
`zproject/config.py` and `zproject/default_settings.py` (due to import
order restrictions).
It does overload the "deploy type" concept somewhat.
Follow-up to #19185.
This commit fixes the bug of showing custom email to admin in
the user-info form even when email_address_visibility is set
to admins only.
This commit fixes it to show the correct email according to
email_address_visibility values.
This commit restructures the top-level navigation on our landing
page using dropdowns in a manner that allows us to advertise some
important pages to our visitors:
- Use cases for companies, open source projects, and communities.
- Miscellaneous pages about the product are now accessible from the
"Product" dropdown.
- "Resources" are a few key resources our users may want to consult
if they need help or support.
We are starting to run into situations where this data could be
quite useful for making future decisions, so it makes to store it
in the database, not just in an email.
Moving forward we are hoping to collect data on org types from our
users, so it makes sense to display the org type on the "Counts"
tab of our /activity page.
Implemented dropdown_list_widget in message_edit UI
which enables the functionality to search for streams
while moving a particular message across streams.
This matches the UI we have in the "move topic" widget.
Fixes#18416.
Not having the package installed will cause startup failures in
`process_fts_updates`; ensure that we've installed the package before
we potentially start the service.
We incorrectly include many realm settings in the data section of
'realm/update_dict' schema. It should only contain the settings
related to message edit, realm icon, realm logo and authentication
methods and not other settings, becausea all the other settings send
'realm/update' event and not 'realm/update_dict' event.
This commit only removes 'add_emoji_by_admins_only' and others will
be removed separately.
Previously, non-admin emoji authors were allowed to
delete the emoji only if add_emoji_by_admins_only
was false. But, as add_emoji_by_admins_only setting
is for who can add emoji and not delete emojis, it
should not affect the behavior of deleting emojis
and users should always be allowed to delete the
emojis which. they added themselves
This commit adds moderators and full members options for
user_group_edit_policy by using COMMON_POLICY_TYPES.
Moderators do not require to be a member of user group in
order to edit or remove the user group if they are allowed
to do so according to user_group_edit_policy.
But full members need to be a member of user group to edit
or remove the user group.
There is no need to have a error message which specifies the
roles having permission to edit user-groups, we can simply
have error message as "Insufficient permission" as we already
show the roles having permission clearly in UI.
This commit changes the behavior to show the tip, explaining
which user roles are allowed to edit user groups, to user
with all roles because it is better to show the user which
other roles are allowed to edit. Previously the tip was shown
to non-admin users only.
Tim Abbott
sahil839
Mateusz Mandera
Anders Kaseorg
aryanshridhar
PIG208
Abhijeet Prasad Bodas
akshatdalton
Wesley Aptekar-Cassels
Alex Vandiver
Priyansh Garg
Eeshan Garg
Kerry Jackson