Merge branch 'getsentry:master' into patch-1

Author: gabrieltaylor

develop-docs/backend/application-domains/database-migrations/index.mdx

@@ -54,7 +54,19 @@ Note that if you have added a new model, you also need to import the model in `_
 
 When merging to master you might notice a conflict with `migrations_lockfile.txt`. This file is in place to help us avoid merging two migrations with the same migration number to master, and if you're conflicting with it then it's likely someone has committed a migration ahead of you.
 
-To resolve this, rebase against latest master, delete your current migration and then regenerate it. If your migration was custom, just save the operations in a text file somewhere so that you can reapply them on the regenerated migration.
+### Automatically Resolving Conflicts
+
+There is a [useful script](https://github.com/getsentry/sentry/blob/master/bin/update-migration) for automatically moving your migration to the top of the migration history.
+
+```bash
+bin/update-migration <migration_name>
+```
+
+It will rename the migration, modify it to depend on the latest migration, and update the lockfile and the name of any tests if they exist.
+
+### Manually Resolving Conflicts
+
+To perform the steps manually, rebase against latest master, delete your current migration and then regenerate it. If your migration was custom, just save the operations in a text file somewhere so that you can reapply them on the regenerated migration.
 
 Always commit the changes to `migrations_lockfile.txt` with your migration.
 

develop-docs/backend/application-domains/email.mdx

@@ -78,7 +78,7 @@ Defaults to `(empty)`.
 <dd><markdown>
 Declared in `config.yml`.
 
-Should Sentry use SSL when connecting to the SMTP server?
+Should Sentry use SSL when connecting to the SMTP server? Mutually exclusive with `mail.use-tls`.
 
 Defaults to `false`.
 
@@ -88,7 +88,7 @@ Defaults to `false`.
 <dd><markdown>
 Declared in `config.yml`.
 
-Should Sentry use TLS when connecting to the SMTP server?
+Should Sentry use STARTTLS when connecting to the SMTP server? Mutually exclusive with `mail.use-ssl`.
 
 Defaults to `false`.
 

develop-docs/backend/application-domains/feature-flags/flagpole.mdx

@@ -148,6 +148,10 @@ Here are some common properties we surface via our Sentry and GetSentry context
 
 : The project's slug
 
+`project_platform` [str]
+
+: The project's platform
+
 **User Context Properties (If checking a flag with an actor)**
 
 `user_id` [int]
@@ -158,6 +162,18 @@ Here are some common properties we surface via our Sentry and GetSentry context
 
 : The active user's email address. This should only contain Sentry employee email addresses.
 
+`user_domain` [str]
+
+: The domain of the active user's email address.
+
+`user_is-staff` [bool]
+
+: Is set to `true` for users that have `is_staff`.
+
+`user_is-superuser` [bool]
+
+: Is set to `true` for users that have `is_superuser`.
+
 
 To see the latest context properties available, check out the repo-specific context builders:
 

develop-docs/backend/issue-platform/index.mdx

@@ -184,9 +184,6 @@ The issue platform provides functionality to help release your new issue type in
 - Post processing - This controls whether we'll pass the issue along to post processing. If disabled, then issues will be created but no notifications will be sent. This can be helpful for testing out what issues look like before release. _Note:_ Any issues created this way will not send new issue notifications after the flag is enabled, since they already exist. In the future, if there is demand we might provide a way to remove all test versions of a new issue type.
 - UI - This controls whether the issue type will appear in the issue list and elsewhere in the ui.
 
-The flags for ingest and post processing are backed by options, and we automatically register these when the issue type is created. These options can be enabled for LA/EA/GA here
-https://sentry.io/_admin/options/.
-
-The flag for the UI uses flagr. We're unable to register new flags in flagr automatically, so you'll need to create the flag in flagr yourself. The name will be in the format `organizations:<GroupType.slug.replace("_", "-")>-visible`.
+These flags are all controlled via flagpole and set via options automator. To get the base values for all of these for easy pasting into flagpole, run `sentry createissueflag --slug=<your_group_slug> --owner=<your_team_name>`. The results of this can be directly pasted into flagpole.yml.
 
 Once your issue type is fully released, and you want it to go out to self-hosted and single tenant you can set `released = True` on your GroupType. This allows it to be released everywhere, and removes the feature flags and options. Generally we recommend doing this after your issue type has been in GA for long enough to verify that it's working as intended.