This splits off the logic between SSO keys used incoming vs outgoing, it allows to far better restrict who is allowed to log in using a site.
This allows for better auditing of the SSO provider feature
- By default, behaviour is not changed: tags are made lowercase upon creation and edit.
- If force_lowercase_tags is disabled, then mixed case tags are allowed.
- Tags must remain case-insensitively unique. This is enforced by ActiveRecord and Postgres.
- A migration is added to provide a `UNIQUE` index on `lower(name)`. Migration includes a safety to correct any current tags that do not meet the criteria.
- A `where_name` scope is added to `models/tag.rb`, to allow easy case-insensitive lookups. This is used instead of `Tag.where(name: "blah")`.
- URLs remain lowercase. Mixed case URLs are functional, but have the lowercase equivalent as the canonical.
When creating lightboxes we will attempt to create 1.5x and 2x thumbnails
for retina screens, this can be controlled with a new hidden site setting
called responsice_post_image_sizes, if you wish to create 3x images run
SiteSetting.responsive_post_image_sizes = "1|1.5|2|3"
The default should be good for most of the setups as it balances filesize
with quality. 3x thumbs can get big.
With these changes, backups to Digital Ocean spaces can be configured with the following variables:
DISCOURSE_S3_ACCESS_KEY_ID: 'XXX'
DISCOURSE_S3_SECRET_ACCESS_KEY: 'YYY'
DISCOURSE_S3_UPLOAD_BUCKET: 'backups-bucket'
DISCOURSE_S3_ENDPOINT: 'https://nyc3.digitaloceanspaces.com'
DISCOURSE_ENABLE_S3_BACKUPS: true
Introduces a hidden setting (default is 0.1) that erodes bounce score
every time we send an email. This means that erratic failures are less
painful cause system auto corrects
These site settings are very hard to explain and only applicable for very
specific Discourse setups.
If an admin "enables staged users" which is used in support scenarios then
all staff can send "messages" directly to an "email".
The setting allows you to extend this to TL4 or any trust level.
Actual use case would be a support type setup with restricted staff. It is
quite rare so hiding this for now and re-evaluate keeping the setting in
2019
At the moment core providers are hard-coded in Javascript, and plugin providers get added to the JS payload at compile time. This refactor means that we only ship enabled providers to the client.
* Phase 0 for user-selectable theme components
- Drops `key` column from the `themes` table
- Drops `theme_key` column from the `user_options` table
- Adds `theme_ids` (array of ints default []) column to the `user_options` table and migrates data from `theme_key` to the new column.
- Removes the `default_theme_key` site setting and adds `default_theme_id` instead.
- Replaces `theme_key` cookie with a new one called `theme_ids`
- no longer need Theme.settings_for_client
