The rewording clarifies that this setting allows users to change only
the value of the field for their own account.
This is a follow-up to #29570 which implented the setting through a
series of 3 commits ending in 23efb5cec7.
This test was written back when Django accepted view function names as
strings that might be wrong; that’s not possible in Django ≥ 1.10.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For settings with allow_everyone_group is False, guest users
are not allowed to do the task controlled by that setting even
if the guest user is member of the group which is used for
that setting.
So, we do not show guest users in typeahead for such settings
and also not create a pill when someone types full email of
the guest user in the input.
There is no such restriction in the API and it is fine
since we eventually have the check to not give guest user
the permission.
And we still allow guests to be part of any group, so there is
no restriction on using groups containing guests as subgroups
of the anonymous groups and showing them in typeahead.
We only use pills UI for can_manage_group setting currently,
but we can still pass setting_type in pill_config so that we
can use that while calling get_group_permission_setting_config
for checking if group is allowed to be used in the setting when
creating group pill from group name.
We currently use the pills UI only for can_manage_group setting so
it is fine to pass setting type as "group" directly to
get_realm_user_groups_for_setting, but it would be better to just
accept setting_type as parameter in typeahead_source and pass that
to get_realm_user_groups_for_setting as other settings will also
use the pills UI in future.
For exporting full with consent:
* Earlier, a message advertising users to react with thumbs up
was sent and later used to determine the users who consented.
* Now, we no longer need to send such a message. This commit
updates the logic to use `allow_private_data_export` user-setting
to determine users who consented.
Fixes part of #31201.
This commit adds test coverage for the
'if user_profile.realm != message.get_realm():' block in
'set_visibility_policy_possible' function.
Currently, 'test_command_with_consented_message_id' adds the
test coverage for this code block. But we plan to remove that
test in the next commit as a part of removing 'react on consent
message' approach.
So, this commit explicitly adds code for the test coverage of
the concerned code block.
Removes the ignore_pull_requests URL parameter from the Travis CI
integration because its functionality is now fully covered by the
standard incoming webhook event filtering framework.
Fixes#30934.
In the installation and integrations activity views, updates the
links to a realm's activity view to use the 'fa fa-table' icon,
instead of the realm name. Now, the realm name links instead to
the realm's support page.
Also, the integrations activity page now includes a link to a
realm's stats view.
Adds a boolean export parameter to the installation activity view.
When true, the initial links column is removed from the chart, a
blank column is removed before human message counts anda column
with all organization owner and admin emails is added.
Updates the links at the top of the installation activity page to
have an option to toggle between the export and non-export versions
of the chart.
Earlier, we used to compute last_edit_timestr as data-tippy-content
when rendering the whole message feed.
This commit changes the behaviour by computing the `last_edit_timestr`
when a user hovers over the message_edit_notice.
Fixes: zulip#27240.
This commit allows configuration of "editable_by_user" property from the
organization settings modal. It also adds support for non-editable
fields in profile settings modal.
Fixes#22883.
Co-Authored-By: Ujjawal Modi <umodi2003@gmail.com>
This margin was extending the size of the parent div, which caused
tooltips applied to the parent to trigger in the empty space below this
input.
Other elements in this section do not have bottom margins. So this
change also helps with uniformity.
This commit is a prep for #22883.
This new property allows organization administrators to specify whether
users can modify the custom profile field value on their own account.
This property is configurable for individual fields.
By default, existing and newly created fields have this property set to
true, that is, they allow users to edit the value of the fields.
Fixes part of #22883.
Co-Authored-By: Ujjawal Modi <umodi2003@gmail.com>
Anders Kaseorg
Alex Vandiver
tnmkr
Tim Abbott
evykassirer
Vector73
Sahil Batra
Prakhar Pratyush
Vlad Korobov
Karl Stolley
Aditya
Lauryn Menard
Pratik Chanda