In my original PR (#9647) I attempted to solve the problem of
using fake timers in acceptance tests by using the new sinon
clock.tickAsync methods. This way of doing things seems to be flawed,
however, as we are getting random spec timeouts starting with the
bookmark acceptance test where this was introduced.
I think I was going about things the wrong way. This commit introduces
a new function with callback (acceptanceUseFakeClock) that sets up the
fake timers using sinon.useFakeTimers with the shouldAdvanceTime option
set to true. This advances time at a normal rate of 20ms per tick, which
means that we are not freezing any time and existing setTimeout funcs.
should proceed as normal. Along with this the callback passed will
run clock.reset() at the end to make sure all the timers are cleaned
up correctly.
There is an optional third parameter after the callback, which is the
timezone. If the user is logged in for the acceptance test then their
timezone is used, otherwise we default to America/Denver.
Usage is (inside an acceptance test):
```
test("Name of the test", async assert => {
// first parameter is time to start fake clock at
await acceptanceUseFakeClock("2020-05-04T13:00:00", async () => {
// test code goes here e.g. await visit("/url");
});
});
```
This commit prevents a 500 error from occurring if someone is trying to
setup their discourse instance as a sso provider and they don't pass in
a `return_sso_url` in their payload.
We were getting errors like this in Reviewables in some cases:
```
ActiveRecord::StatementInvalid (PG::AmbiguousColumn: ERROR: column reference "category_id" is ambiguous
LINE 4: ...TRUE) OR (reviewable_by_group_id IN (NULL))) AND (category_i...
```
The problem that was making everything go boom is that plugins can add their own custom filters for Reviewables. If one is doing an INNER JOIN on topics, which has its own category_id column, we would get the above AmbiguousColumn error. The solution here is to just make all references to the reviewable columns in the list_for and viewable_by code prefixed by the table name e.g. reviewables.category_id.
This is so that, on a multisite cluster, when we handle a CDN request,
the hostname that is requested corresponds to one of the sites -
specifically the default site.
* FEATURE: Support for App Shortcuts Menu
This adds a list of shortcuts to a installed Discourse instance.
It can be accessed by right clicks or long press on the app icon.
See https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Shortcuts/explainer.md
List of possible follow ups include:
- Making it admin customizable
- Making it user customizable
- Using SVG icons from the site icon sprite
- Picking an accent color for icons
* FIX: Add type to shortcut menu icons
This refactors default_current_user_provider in a few ways:
- Introduce a generic `api_parameter_allowed?` method which checks for whitelisted routes/formats
- Only read the api_key parameter on allowed routes. It is now completely ignored on other routes (previously it would raise a 403)
- Start reading user_api_key parameter on allowed routes
- Refactor tests as end-end integration tests
A plugin API for PARAMETER_API_PATTERNS will be added soon
Previously we only changed sequence on ownership change, this
cause a race condition between tabs where user could type for a
long time without being warned of an out of date draft.
This change is a radical change and we should watch closely.
Code was already in place to track sequence on the client so no
changes are needed there.
Adding this from a review; I was using Discourse.currentUser which is frowned upon now.
Passing currentUser both for regular post menu buttons and extra buttons attached via the plugin API.
Lots of formatting/whitespace changes, best off reviewing with ?w=1
posts and topics tables can be huge, this migration change
ensures the migration performs less work in one giant transaction
reducing risk of deadlocks
Migration is re-runnable thanks to NOT EXISTS checks
For pages that do not specify canonical URL we will default to `https://SITENAME/PATH`.
This ensures that if a URL is crawled on the CDN the search ranking will transfer to the main site.
Additionally we whitelist the `?page` param
