A user who somehow got an empty `zulip` database, but without a
`zerver_messages` table in it, would get stuck in the installer at:
```
++ su postgres -c 'cd / && psql -v ON_ERROR_STOP=1 -Atc '\''SELECT COUNT(*) FROM zulip.zerver_message;'\'' zulip'
ERROR: relation "zulip.zerver_message" does not exist
LINE 1: SELECT COUNT(*) FROM zulip.zerver_message;
^
+ records=
```
Treat a failure to select from `zerver_messages` as having 0 messages,
and continue with the `DROP DATABASE IF EXISTS` / `CREATE DATABASE`
that `create-db.sql` usually does.
Fixes: #29110.
Earlier, we were using 'timezone_now' (the time cron job runs)
as the event_time while invoicing plans in 'invoice_plan'.
This is not accurate as it will lead to invoicing ledger entries
created after 'next_invoice_date' and before 'timezone_now'.
We should only invoice the ledger entries created till
next_invoice_date. It should be independent of the time
at which cron job runs.
This commit updates the logic to use next_invoice_date
as the event_time while invoicing via cron.
Earlier, at few places in test_stripe we were doing
incorrect time travel. For example:
A plan was invoiced till self.next_year & while checking
the billing page, we were using the self.now datetime.
To correctly check the billing page state after plan is
invoiced, we should use a datetime greater than or equal
to the time at which plan was invoiced.
This commit fixes such logically incorrect time-travel.
While creating a LicenseLedger entry in 'create_customer_and_plan',
we should set the 'event_time' to the same time at which the plan
is created.
Earlier, the 'event_time' for ledger entry & 'billing_cycle_anchor'
of the plan were set to different values, which is not the
correct behavior.
Earlier, the code block to calculate additional licenses charge
raised assertion error when processing a fixed-price plan.
The code block shouldn't be executed for fixed-price plans as
we don't charge customers on fixed-price plans for additional
licenses.
Earlier, the 'self.on_paid_plan()' check was verifying if the
billing_session/customer is on paid plan and not the plan we
are processing.
This resulted in a bug. While processing a legacy plan, a customer
switches from legacy plan to a paid plan resulting in the
'self.on_paid_plan()' check returning True.
It leads to invoicing legacy plan which shouldn't happen.
The fix is to check if the plan we are processing is paid or not
instead of the remote_realm/remote_server plan_type.
Previously we declared the 'focused_recipient' object
with an initial field of 'msg_type' and progressively added
fields by mutating the object(depending on the 'msg_type' ie. 'stream'
or 'private'). This was not TypeScript friendly and the compiler threw.
Now, we first fetch those fields and then create the 'focused_recipient'
object depending on the value of 'msg_type' field.
This callback(initially named 'row_to_id') is part of two different
code paths.For one it refers to 'get_row' function local to
'visible_groups' and for other it refers to 'row_to_id' function
local to 'visible_messages'(same namings cause a confusion and is
also inconsistent).
Here I have renamed the callback to 'row_to_output', this is
more explanatory and consistent with name '_divisible_divs' uses
for the same callback.
This creates a much cleaner API and types for these functions. Since
the callers already had the message objects, this avoids extra work
both in the most callers and in these functions.
We also loop through all_rendered_message_lists rather than hardcoding
logic for message_lists.home.
The organization logo in the upper left navigates to the user's home
view. We add a tooltip to make this easier to discover.
We show `Esc` as the keyboard shortcut here, unless the user has
disabled it, in which case we show the alt shortcut `Ctrl` + `[`.
Fixes#29185.
We were updating the compose banners on every `keyup` event on the
topic input. Since, `keyup` also gets triggered for the modifier and
non-printing keys such as "Enter", this lead to banner for topic
required being closed via the `check_posting_policy_for_compose_box`
when pressing "Enter" to send a message with no topic.
This bug was probably introduced in 5c993f0, which moved additional
logic into `update_on_recipient_change`.
To solve this issue, we use the `input` event instead of the `keyup`
event to update the compose banners only when the value inside the
input element changes.
This change also prevents the the compose banner from being closed
when we only press modifier keys - such as Shift.
Add a word-wrap rule so that longer code elements, such as example
URLs or long return value names in the API documentation, do not
overflow out of the view in narrowed browsers or mobile views.
Depending on the kind of config error being shown, different "go back"
links may be more appropriate.
We probably hard-coded /login/ for it, because these config errors are
most commonly used for authentication backend config error, where it
makes sense to have /login/ as "go back", because the user most likely
indeed got there from the login page.
However, for remote_billing_bouncer_not_configured, it doesn't make
sense, because the user almost surely is already logged in and got there
by clicking "Plan management" inside the gear menu in the logged in app.
It's best for these to just be consistent. Therefore:
1. The .../not-configured/ error page endpoint should be restricted to
.has_billing_access users only.
2. For consistency, self_hosting_auth_view_common is tweaked to also do
the .has_billing_access check as the first thing, to avoid revealing
configuration information via its redirect/error-handling behavior.
The revealed configuration information seems super harmless, but it's
simpler to not have to worry about it and just be consistent.
Just shows a config error page if the bouncer is not enabled. Uses a new
endpoint for this so that it can work nicely for both browser and
desktop app clients.
It's necessary, because the desktop app expects to get a json response
with either an error or billing_access_url to redirect to. Showing a
nice config error page can't be done via the json error mechanism, so
instead we just serve a redirect to the new error page, which the app
will open in the browser in a new window or tab.
Only affects zulipchat, by being based on the BILLING_ENABLED setting.
The restricted backends in this commit are
- AzureAD - restricted to Standard plan
- SAML - restricted to Plus plan, although it was already practically
restricted due to requiring server-side configuration to be done by us
This restriction is placed upon **enabling** a backend - so
organizations that already have a backend enabled, will continue to be
able to use it. This allows us to make exceptions and enable a backend
for an org manually via the shell, and to grandfather organizations into
keeping the backend they have been relying on.
By convention, all our backends inherit form ZulipAuthMixin. This is
helpful to have a single place if we want to add some class attributes
that all the backends should have.
Alex Vandiver
Prakhar Pratyush
Alya Abbott
nimishmedatwal
Temidayo32
Anders Kaseorg
evykassirer
Lauryn Menard
Varun Singh
Tim Abbott
Sayam Samal
afeefuddin
Mateusz Mandera
Karl Stolley