The web-public option was disabled instead of being hidden in stream creation
form during live update triggerred from setting enable_spectator_access to
False. It was not being hidden since we have made web-public as the first
option and it is selected by default.
This commit fixes the bug to hide the option and also makes the code more
readable.
We should only consider visible choices while selecting the default
stream-privacy choice in stream creation form. Previously, we were
only checking whether the option is disabled, but this resulted in
a case where no option was selected when the realm-level setting
was set to not allow web-public streams as the choice was only
hidden and not disabled.
We don't have automated test coverage on this yet,
but below are the results from manual testing.
Note that we include the realm icon and logo even
though they were not created by Cordelia.
./manage.py export_single_user cordelia@zulip.com
$ (cd /tmp/zulip-export-4v3mo802/ && find .)
.
./emoji
./emoji/2
./emoji/2/emoji
./emoji/2/emoji/images
./emoji/2/emoji/images/3.jpg
./emoji/records.json
./messages-000001.json
./realm_icons
./realm_icons/2
./realm_icons/2/night_logo.original
./realm_icons/2/night_logo.png
./realm_icons/2/icon.png
./realm_icons/2/icon.original
./realm_icons/records.json
./avatars
./avatars/2
./avatars/2/c5125af0447f4d66ce34c1b32eac75ac27ebe0e7.original
./avatars/2/c5125af0447f4d66ce34c1b32eac75ac27ebe0e7.png
./avatars/records.json
./uploads
./uploads/2
./uploads/2/68
./uploads/2/68/xyEkC5dTIp8m42_6HJ3kBfdt
./uploads/2/68/xyEkC5dTIp8m42_6HJ3kBfdt/denver.jpg
./uploads/2/96
./uploads/2/96/ol5WE6RTUntvuPDSpJUrYTim
./uploads/2/96/ol5WE6RTUntvuPDSpJUrYTim/denver.jpg
./uploads/records.json
./user.json
There are tactical reasons to remove this assertion.
Basically, the reason it's safe to remove is that it's
been around a long time and we would have seen this
operationally. Also, the check to make sure that the
S3 filename thingy matches the avatar hash is a much
stronger check.
We will soon restore a stronger version of this check
that applies to all of our asset types (emojis/avatars/etc.).
This makes it easier to read the calling code and see
the big picture of how the four asset types are
organized.
I also handle uploads first, to be similar to the local
code.
This code is well tested--you can modify any of the callers
to pass in a wrong value of `object_key` and get a failing
test.
This is likely not the correct long-term fix, but it's an effective
tactical fix for this button. Added a TODO noting the expected
direction for a long term solution.
Fixes#20481.
The comment explains in more detail, but basically we'd skip
exercising a bit of code in the signup code path if there were no
messages in the last week, resulting in the query count not matching.
Before:
$ git log -p -1 88fd399bec | wc
50015 134879 2016086
After:
$ git log -p -1 88fd399bec | wc
1554 6624 229028
$ git log -a -p -1 88fd399bec | wc
50015 134879 2016086
Also add some organization and explanatory comments to this file,
following what we have in zulip-mobile:.gitattributes .
"help" command occurs in the command list in
initial pms or when bot doesn't understand the message. It doesn't
occur when the bot is respoding to the "help" command itself.
Having wantMessagesSigned=True globally means that it's also applied by
python3-saml to regular authentication SAMLResponses - making it require
the response to be signed, which is an issue because a feasible
alternative way that some IdPs (e.g. AzureAD) take by default is to sign
specifically the assertions in the SAMLResponse. This is also secure,
and thus we generally want to accept it.
Without this, the setting of wantMessagesSigned=True globally
in 4105ccdb17 causes a
regression for deployments that have already set up SAML with providers
such as AzureAD, making Zulip stop accepting the SAMLResponses.
Testing that this new logic works is handled by
test_saml_idp_initiated_logout_invalid_signature, which verifies that a
LogoutRequest without signature will be rejected.
It is possible for user to change the width by using
screen rotation after the page has been loaded on mobile.
If only height has changed, it is most likely due to a
virtual keyboard, we don't hide popover in that case.
Fixes#20439
This commit adds code to check whether a user is allowed to use
wildcard mention in a large stream or not while editing a message
based on the realm settings.
Previously this was only checked while sending message, thus user
was easily able to use wildcard mention by first sending a normal
message and then using a wildcard mention by editing it.
In 4792af5682 I reformatted the template in such a way
that the div was no longer empty, and therefore
the :empty pseudoclass was not properly applied to
show the placeholder.
I remove some spurious whitespace and a stray period
in zephyr-mirror, and then for all three I try to
line-wrap/indent in a way that's nicer for humans
and parsers to read.