I accidentally free trials for both cloud and self hosted
enabled while testing, hence didn't catch it.
This mostly involves fixing `is_free_trial_offer_enabled` to
return the correct value and providing it the correct input.
The paragraph tag was being used along with the bold tag to style the
topic and stream in the popovers. The semantic meaning of these tags
are more specialized and should not be used in this context. Replaced
the <p> tags with the more general <div> tags and accounted for the
bold text via the `font-weight` CSS property.
The `.topic-name` class, used to style the topic/stream name in the
topic list in the left sidebar, was also being used to the style the
topic/stream name in the topic/stream popover. This lead to irrelevant
properties being applied to the popover > topic/stream name. Through
this commit, the styling for both of these different cases are now
separated using the appropriate selectors.
Fixes#27562.
When a stream name becomes very long, it may stretch the popover menu
by a lot. We prevent this by allowing the stream name to wrap onto
multiple lines.
We set the streams popover width to be equal to the width of the longest
menu item, via the min-content intrinsic sizing. We also set all the
menu items to `white-space: nowrap` to prevent them wrapping. These
two changes allow the menu items to dictate the width of the popover
instead of a static max-width property, and thus helps with languages
where the length of the translated item may be long enough to wrap.
We set the topics popover width to be equal to the width of the longest
menu item, via the min-content intrinsic sizing. We also set all the
menu items to `white-space: nowrap` to prevent them wrapping. These
two changes allow the menu items to dictate the width of the popover
instead of a static max-width property, and thus helps with languages
where the length of the translated item may be long enough to wrap.
It’s still used indirectly via Scrapy, but we haven’t used it directly
since commit 09e17fbe17 (#2002).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
As per the intended design, the font size of the org plan should
be equal to the font size of other similar links such as org version.
It should not be one size smaller than it, such as those of the
upgrade links.
Some organizations may have long names that could blow up the gear
menu width, in those cases we want to prevent it by wrapping the
org name by explicitly setting the white-space property, and thus
enabling any soft-wrap opportunities.
Through this commit, we set the width of the navbar dropdowns to be
equal to the longest menu item, via the min-content intrinsic sizing.
Note, that the min-content width takes into account all soft-wrapping
opportunities, which could result in the wrapping of the menu items in
many cases. To prevent this, we use the white-space property to prevent
menu items from wrapping in any case.
We currently don't have appropriate padding applied to the lists and
links in the org info section of the gear menu popover. This becomes
an issue when we have a long org name, org url or org version, as
text starts touching the edges of the popover.
This commit adds the missing padding to the items in the org info
section of the gear menu popover.
Pulls the forms for updating the billing collection method and
generally modifying the current plan to a separate template.
Uses the shared template to render these forms for both the
remote server and any attached remote realms.
If there are remote realms attached to the remote server, adds
the forms to be able to update sponsorship requests, approve
sponsorship and update a discount.
This commit updates the CSS to fix the alignment of loading
spinner in "Save" button and also to make sure that button's
width does not change after clicking on the button.
We should show "white" spinner on "Save" button in message edit
form irrespective of the theme, as it looks better with the
button having blue background.
When a self-hosted Zulip server does a data export and then import
process into a different hosting environment (i.e. not sharing the
RemoteZulipServer with the original, we'll have various things that
fail where we look up the RemoteRealm by UUID and find it but the
RemoteZulipServer it is associated with is the wrong one.
Right now, we ask user to contact support via an error page but
might develop UI to help user do the migration directly.
We already override PUSH_NOTIFICATION_BOUNCER_URL in
test_extra_settings.py, so making this change should have as its only
impact making it a bit easier to test the push notifications bouncer
manually in a development environment.
I submitted a related PR to the mobile app documentation for testing
the push notifications software against a production server motivated
by this.
The separation of files no longer makes any sense, with some of these
forms being used by the RemoteRealm and legacy server flows together.
And in general we don't need to scatter this stuff across files.
Also, the unifying of the class of loader on the buttons, fixes a visual
bug on the final "Confirm login" page where you would see it spinning
for half a second upon loading the page, until the .hide() code
triggered.
The way the flow goes now is this:
1. The user initiaties login via "Billing" in the gear menu.
2. That takes them to `/self-hosted-billing/` (possibly with a
`next_page` param if we use that for some gear menu options).
3. The server queries the bouncer to give the user a link with a signed
access token.
4. The user is redirected to that link (on `selfhosting.zulipchat.com`).
Now we have two cases, either the user is logging in for the first time
and already did in the past.
If this is the first time, we have:
5. The user is asked to fill in their email in a form that's shown,
pre-filled with the value provided inside the signed access token.
They POST this to the next endpoint.
6. The next endpoint sends a confirmation email to that address and asks
the user to go check their email.
7. The user clicks the link in their email is taken to the
from_confirmation endpoint.
8. Their initial RemoteBillingUser is created, a new signed link like in
(3) is generated and they're transparently taken back to (4),
where now that they have a RemoteBillingUser, they're handled
just like a user who already logged in before:
If the user already logged in before, they go straight here:
9. "Confirm login" page - they're shown their information (email and
full_name), can update
their full name in the form if they want. They also accept ToS here
if necessary. They POST this form back to
the endpoint and finally have a logged in session.
10. They're redirected to billing (or `next_page`) now that they have
access.
Aman Agrawal
Sayam Samal
Anders Kaseorg
Alya Abbott
Tim Abbott
Lauryn Menard
Mateusz Mandera
Karl Stolley
Sahil Batra
Alya Abbott
N-Shar-ma