Now that we have support for user-selectable color schemes, it makes sense
to simplify seeding and theme updates in the wizard.
We now:
- seed only one theme, named "Default" (previously "Light")
- seed a user-selectable Dark color scheme
- rename the "Themes" wizard step to "Colors"
- update the default theme's color scheme if a default is set
(a new theme is created if there is no default)
We are using preload to load tags into topics. When later we try to use `order` or `pluck` it is causing N+1
Usually, topics don't have many tags so sorting using ruby should be reasonably performant.
When posts or topics are deleted we don't want to immediately delete associated bookmarks, so we have a grace period to recover them and their reminders if the post or topic is un-deleted. This PR adds a task to the Weekly scheduled job to go and delete bookmarks attached to posts or topics deleted > 3 days ago.
Per Google, sites are encouraged to upgrade from `analytics.js` to `gtag.js` for Google Analytics tracking. This commit updates core Discourse to use the new `gtag.js` API Google is asking sites to use. This API has feature parity with `analytics.js` but does not use trackers.
When the server gets overloaded and lots of requests start queuing server
will attempt to shed load by returning 429 errors on background requests.
The client can flag a request as background by setting the header:
`Discourse-Background` to `true`
Out-of-the-box we shed load when the queue time goes above 0.5 seconds.
The only request we shed at the moment is the request to load up a new post
when someone posts to a topic.
We can extend this as we go with a more general pattern on the client.
Previous to this change, rate limiting would "break" the post stream which
would make suggested topics vanish and users would have to scroll the page
to see more posts in the topic.
Server needs this protection for cases where tons of clients are navigated
to a topic and a new post is made. This can lead to a self inflicted denial
of service if enough clients are viewing the topic.
Due to the internal security design of Discourse it is hard for a large
number of clients to share a channel where we would pass the full post body
via the message bus.
It also renames (and deprecates) triggerNewPostInStream to triggerNewPostsInStream
This allows us to load a batch of new posts cleanly, so the controller can
keep track of a backlog
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
We were trying to observe a non-ember object which is undefined
behavior and was leaking to odd bugs. This replaces the `filter` object
with an Ember Object and things seem to work.
I also took the opportunity with this commit to move some test specific
stuff out of `discourse-loader` which is loaded on the front end of the
application. The test module building now happens in the `test_helper`
bundle.
DEV: Replace instances of Discourse.base_uri with Discourse.base_path
This is clearer because the base_uri is actually just a path prefix. This continues the work started in 555f467.
This misses a test because Favcount doesn't exposes a get to the counter.
Also, since this code deals with all possible notifications configs we support:
- favicon notification
- favicon new content
- title notification
- title new content
the code is a bit complicated to follow. We may look into refactoring it when a
good opportunity arises, like if https://w3c.github.io/badging/ setClientBadge() method
gives us a cleaner way to notify users.
We can't use erb in Ember CLI (since it does not have Ruby) so this has
been ported to use our `javascript:update_constants` rake test instead.
Note we don't have to run this every time a notification type as it's
only used by fixtures to fill in some specific types we test against.
This is long overdue. We had a lot of (not linted) code to initialize
our test suite as part of the Ruby `test_helper.js` bundle.
This refactor moves that out to a `setup-tests` module, which imports
all the modules properly, rather than using `require`.
It also removes the global `server` variable which some tests were using
for pretender. Those tests are fixed, and in the case of widget tests,
support for a `pretend()` was added, which mimics our acceptance tests.
One problematic test was removed, which overwrites `/posts` - this could
break tons of other tests depending on order.
The prefixing logic is moved into a `prefixProtocol` function in lib:url.
This commit also renames an incorrectly named test and uses https as default instead of http, in 2020 it's reasonable to think we most likely want https and not http. User can still specify http if required.
This commit is also moving one test to a component test.
A followup to this commit would be to ensure every dropdowns are using a regex instead of the normalize/lowercase system we have now.
The dark-mode-friendly SVG mask for the wizard's background image
introduced in 8fcfb9586c does not work with
CDNs, because CORS restrictions apply to SVG masks.
It would be complicated to modify CDN access origin rules for this one
specific assets, so instead, this PR moves the contents of the SVG file
inside the stylesheet.
These are tricky because `module.exports` is used by nodejs files as a
global, which is OK. But we don't want to allow `module` in JS tests
for qunit without importing it first.
We used many global functions to handle tests when they should be
imported like other libraries in our application. This also gets us
closer to the way Ember CLI prefers our tests to be laid out.
Previously, Jobs::EnqueueDigestEmails would enqueue a digest job for every user, even if there are no topics to send. The digest job would exit, no email would send, and last_emailed_at would not change. 30 minutes later, Jobs::EnqueueDigestEmails would run again and re-enqueue jobs for the same users.
120fa8ad introduced a temporary mitigation for this issue, by randomly selecting a subset of those users each time.
This commit adds a new `digest_attempted_at` column to the `user_stats` table. This column is updated every time a digest job completes for a user. Using this, we can avoid scheduling digest jobs for the same user every 30 minutes. This also removes the random user selection in 120fa8ad, and instead prioritizes users who had digests attempted the longest time ago.
To avoid blocking the sidekiq queue a limit of 10,000 digests per 30 minutes
is introduced.
This acts as a safety measure that makes sure we don't keep pouring oil on
a fire.
On multisites it is recommended to set the number way lower so sites do not
dominate the backlog. A reasonable default for multisites may be 100-500.
This can be controlled with the environment var
DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE
See https://meta.discourse.org/t/changing-a-users-email/164512 for additional context.
Previously when an admin user changed a user's email we assumed that they would need a password reset too because they likely did not have access to their account. This proved to be incorrect, as there are other reasons a user needs admin to change their email. This PR:
* Changes the admin change email for user flow so the user is sent an email to confirm the change
* We now record who the email change request was requested by
* If the requested by user is admin and not the user we note this in the email sent to the user
* We also make the confirm change email route open to anonymous users, so it can be clicked by the user even if they do not have access to their account. If there is a logged in user we make sure the confirmation matches the current user.
* FEATURE: Export the entire user profile as json, not just bio/website
* FEATURE: Add session log information to user export
Even though the columns are named 'auth_token' etc, the content is not actually usable to log into the forum with. Despite all that, it is still truncated for export, to avoid any 'token hash cracking' situations.
