The Telegram onboarding flow in a nutshell:
1. user invites our bot in a channel and types "/start"
2. Telegram calls our webhook (/integration/telegram/bot/)
3. Our webhook generates and posts an invite link to the chat
4. User clicks the invite link, we show "Add Telegram" form
...
In step 3, when we post the invitation link, if Telegram returns
an error (for example, CHAT_WRITE_FORBIDDEN), our webhook was
throwing HTTP 500. In response, Telegram would retry the webhook
several times, but that's probably futile.
After this commit, the webhook will return HTTP 200, regardless
of whether we could post the invite to the Telegram chat or not.
There is a specific limit of how many other users a given user
can invite in their projects (depends on the plan they are on).
When the limit is reached, the user cannot invite *new* users
in their projects, but they can still invite team members
from one project into another project. In other words, we count
the number of unique invited users, not the number of memberships.
There was an UI bug in the "Invite a Team Member" dialog. The
dialog has an editable "Email" text field. When an user has reached
the team limit, and they open the "Invite" dialog, they could
enter a new user's email address in the Email field and try to invite
them. The server would refuse to exceed the team limit and would
return a plain HTTP 403 page. This is of course confusing to the
end user.
The fix is to show "Email" as a text field only if the user has
not yet exceeded their team size. If they have, then show "Email"
as non-editable text.
The problem:
- the first "pip wheel" collects a specific version of requests
- the second "pip wheel" collects the latest version of requests
- later "pip install" tries to install both and fails
The fix is to run "pip wheel" once, and it will then pick a single
version of requests that satisfies all constraints.
Fixes: #594
- Refactor transport classes to raise exceptions
on delivery problems, instead of returning error
message as string. Exceptions can carry extra meta
information (see TransportError.permanent field, see
MigrationRequiredError subclass). I considered attaching
the extra information to strings by subclassing str, but
using exceptions felt cleaner and less hacky.
- Add Channel.disabled field, for disabling integrations
on permanent errors. For example, if Slack returns
HTTP 404, we will now mark the integration as disabled
and will not make requests to that Slack endpoint again.
Redirect unauthenticated users to the sign in page
instead. Rationale:
- The content on the welcome page is what often belongs
to a separate "marketing site". The marketing content
is of no use on self-hosted instances, which typically
have new signups disabled and are for internal use only
- (the real reason, let's be honest) a number of
self-hosted instances are accessible over the public
internet. Search engines index the nearly identical
landing pages and see them as duplicated content.
The jsonify decorator parses request payload as JSON
and puts it in request.json. The payload would normally
be a complex object, but if a client sends, let's say,
a single integer, then request.json is a python int.
The authorize decorator looks for API key first in request
headers, then in request body. It expects the request
body to be a complex object.
This commit changes adds the following validation rule in
the jsonify decorator: if request body is not empty, it
*must* parse as JSON, and the root element of the parsed
document *must* be a dict.
Previous retry logic was:
- max 3 tries
- every try times out after 5 seconds
The new retry logic is:
- max 3 tries
- every try times out after 10 seconds
- if the first two tries have used > 10 seconds, don't
do the third try
cc: #569
