'please refresh, or you may experience unexpected behavior' sounds quite threatening to me. 'please refresh to to keep things working smoothly' conveys the same information in a more friendly way
This commit includes several changes to make hashtags work when "lazy
load categories" is enabled. The previous hashtag implementation use the
category colors CSS variables, but these are not defined when the site
setting is enabled because categories are no longer preloaded.
This commit implements two fundamental changes:
1. load colors together with the other hashtag information
2. load cooked hashtag data asynchronously
The first change is implemented by adding "colors" to the HashtagItem
model. It is a list because two colors are returned for subcategories:
the color of the parent category and subcategory.
The second change is implemented on the server-side in a new route
/hashtags/by-ids and on the client side by loading previously unseen
hashtags, generating the CSS on the fly and injecting it into the page.
There have been minimal changes outside of these two fundamental ones,
but a refactoring will be coming soon to reuse as much of the code
and maybe favor use of `style` rather than injecting CSS into the page,
which can lead to page rerenders and indefinite grow of the styles.
This commit changes `max_image_megapixels` to be used
as is without multiplying by 2 to give extra leway.
We found in reality this was just causing confusion
for admins, especially with the already permissive
40MP default.
When we show the links to installed plugins in the admin
sidebar (for plugins that have custom admin routes) we were
previously only doing this if you opened /admin, not if you
navigated there from the main forum. We should just always
preload this data if the user is admin.
This commit also changes `admin_sidebar_enabled_groups` to
not be sent to the client as part of ongoing efforts to
not check groups on the client, since not all a user's groups
may be serialized.
Why this change?
We have been seeing checkout timeouts happening on CI when using the
default of 5 seconds. This can happen in system tests when the server
has to process many requests using the same database connection.
Therefore, we will double the timeout for now and monitor if stuff
continues to timeout.
Why this change?
This commit introduces an experimental `type: objects` theme setting
which will allow theme developers to store a collection of objects as
JSON in the database. Currently, the feature is still in development and
this commit is simply setting up the ground work for us to introduce the
feature in smaller pieces.
What does this change do?
1. Adds a `json_value` column as `jsonb` data type to the `theme_settings` table.
2. Adds a `experimental_objects_type_for_theme_settings` site setting to
determine whether `ThemeSetting` records of with the `objects` data
type can be created.
3. Updates `ThemeSettingsManager` to support read/write access from the
`ThemeSettings#json_value` column.
Followup to 95a2d285d397edf0c31ac7ac96dac7d3d0f200d3
Fixes a missing translation and also makes it so the
flag modal does not have a scrollbar when it opens.
Followup fb087b7ff6d168bbfcaa5f83d53ac122d6a18a1c
post_links_allowed_groups is an odd check tied to
unrestricted_link_posting? in PostGuardian, in that
it doesn't have an escape hatch for staff like most
of the rest of these group based settings.
It doesn't make sense to exclude admins or mods from
posting links, so just always allow them to avoid confusion.
Affects the following settings:
* whispers_allowed_groups
* anonymous_posting_allowed_groups
* personal_message_enabled_groups
* shared_drafts_allowed_groups
* here_mention_allowed_groups
* uploaded_avatars_allowed_groups
* ignore_allowed_groups
This turns off `client: true` for these group-based settings,
because there is no guarantee that the current user gets all
their group memberships serialized to the client. Better to check
server-side first.
When enabled, the workbox caching logic in the service worker will be replaced with a very simple offline error page. We plan to use this as an experiment to see how it affects performance and stability of Discourse.
Why this change?
I have been investigating transaction related issues with our system
tests and I have a hard time figuring out what is causing the problem.
To help simplify our environment further, we will set the pool size in
the test environment to 1 so that it is impossible for us to be fetching
a different connection between the threads since they all share the
connection pool.
Also set `reaping_frequency` to `0` to ensure we don't reap any
connection ensuring the same connection is always used.
- Created a new migration for here_mention
- Updated existing migration for here_mention
- Updated site settings for here_mention, create_tag, and
send_email_messages
* DEV: Update min trust level to tag topics migration to groups
- Update the existing migration to include staff and admin
- Update default values
- Added migration to include staff and admin cases
Checking group permissions on the client does not work,
since not all groups are serialized to the client all
the time. We can check `uploaded_avatars_allowed_groups`
on the server side and serialize to the current user
instead.
There are some cases where staff (admins/mods) can
be in lower trust levels, so some of these checks will
fail for them. Since we want to keep allowing this (for now)
we should set most settings to also default to be allowed
for staff too, since the old `has_trust_level?` check
worked in this way.
These routes were previously rendered using Rails, and had a fairly fragile 2fa implementation in vanilla-js. This commit refactors the routes to be handled in the Ember app, removes the custom vanilla-js bundles, and leans on our centralized 2fa implementation. It also introduces a set of system specs for the behavior.
Running Discourse 3.2 stable under Ember 3 will technically be possible, but is only intended as a short-term migration point. This commit adds an admin warning for sites which are using this configuration, to make it clear that themes and plugins are unlikely to support the configuration.
https://meta.discourse.org/t/287211
Why this change?
In https://www.postgresql.org/docs/current/non-durability.html, it is
recommended to create unlogged tables to avoid WAL writes which can help
speed at performance at the expense of durability. In the CI env, there is no need for durability at all.
Therefore, we are going to be creating unlogged tables by default.
Co-authored-by: Ted Johansson <ted@discourse.org>
Co-authored-by: Rafael dos Santos Silva <xfalcox@gmail.com>
We're changing the implementation of trust levels to use groups. Part of this is to have site settings that reference trust levels use groups instead. It converts the min_trust_level_to_tag_topics site setting to tag_topic_allowed_groups.
We're changing the implementation of trust levels to use groups. Part of this is to have site settings that reference trust levels use groups instead. It converts the min_trust_level_for_user_api_key site setting to user_api_key_allowed_groups.
This isn't used by any of our plugins or themes, so very little fallout.
If configuring only moderators in a group based access setting, the mapping to the old setting wouldn't work correctly, because the case was unaccounted for.
This PR accounts for moderators group when doing the mapping.
We're changing the implementation of trust levels to use groups. Part of this is to have site settings that reference trust levels use groups instead. It converts the min_trust_to_post_links site setting to post_links_allowed_groups.
This isn't used by any of our plugins or themes, so very little fallout.
