Previously, this would require manually adding `?safe_mode=...` multiple times during the email-based login flow. `/u/admin-login` is often used when debugging a site, so it makes sense for this to be easier.
This commit introduces a new checkbox on the `/u/admin-login` screen. When checked, it'll set the safe_mode parameter on the `/email-login` link, and then pass it all the way through to the homepage redirect.
- `no_custom` -> `no_themes` (history: before themes existed, we had a similar tool called 'customizations')
- `only_official` -> `no_unofficial_plugins` (matches format of `no_themes` and `no_plugins`, and makes it clear that this doesn't affect themes)
- `?safe_mode=no_themes%2C%no_plugins` -> `?safe_mode=no_themes,no_plugins` (the query portion of a URL does not require commas to be encoded. This is much nicer to read)
- If `no_plugins` is chosen from `/safe-mode` the URL generated will omit the superfluous `no_unofficial_plugins` flag
- Some tweaks to copy on `/safe-mode`
There was existing logic for this, but it was broken because the values were being run through `encodeURI` before checking its type. This commit takes the opportunity to modernise the function to use `URLSearchParams`, which means we no longer need to handle encoding/joining strings manually.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
This enforces some ordering rules for properties/methods in native JS classes. Having enforced structure across our codebase will help developers to quickly get their bearings when reading different classes.
The eslint-config-discourse update introduces an enforced ordering of:
```javascript
"order": [
"[static-properties]",
"[static-methods]",
"[injected-services]",
"[injected-controllers]",
"[tracked-properties]",
"[properties]",
"[private-properties]",
"constructor",
"[everything-else]"
]
```
We may wish to introduce more strict ordering of getters/setters/methods in future.
This commits makes the `enable_experimental_sidebar_hamburger` and
`enable_sidebar` site settings public for site admins to enable. While
the site settings are public, do note that the features are still under
heavy development and are subjected to rapid changes
Each test chunk takes about 10 minutes, so those timeouts can be decreased from 20 to 15.
And there are three of those chunks so total can be a bit over 30 minutes, hence the bump to 35.
Fixes warning:
```
Deprecation notice: Jobs::SendSystemMessage was enqueued with argument values which do not cleanly serialize to/from JSON. This means that the job will be run with slightly different values than the ones supplied to `enqueue`. Argument values should be strings, booleans, numbers, or nil (or arrays/hashes of those value types). (deprecated since Discourse 2.9) (removal in Discourse 3.0)
At /var/www/discourse/lib/post_destroyer.rb:335:in `notify_deletion`
```
Polling every 0.001s can cause extreme load on the redis instance, especially in scenarios where multiple app instances are waiting on the same lock. This commit introduces an exponential backoff starting from 0.001s and reaching a maximum interval of 1s.
Previously `CHECK_READONLY_ATTEMPTS` was 10, and resulted in a block for 0.01s. Under the new logic, 10 attempts take more than 1s. Therefore CHECK_READONLY_ATTEMPTS is reduced to 5, bringing its total time to around 0.031s
This was a temporary solution while we updated the resolver and migrated all our singletons to true ember services. Now that's done, we can switch to use `@glimmer/component` directly, and explicitly inject services as required.
This fix is for the experimental user menu. Some `bookmark_reminder` notifications may not be associated with a topic/post (e.g. bookmark reminder for a chat message) in which case the default notification renderer cannot figure out the `href` for those `bookmark_reminder` notifications. This commit teaches the `bookmark_reminder` notification type renderer to fallback to `bookmarkable_url` that's present in the notification data if the default notification renderer doesn't return a `href` for the notification.
At a certain point, the cost of debugging a flaky acceptance test is
just too high for what we're testing for here. I've decided to just
accept the risk of a minor UX feature.
Follow-up to 55fa94f759
Previously, PM only tags were being routed to the public topic list with
the tag added as a filter. However, the public topic list does not fetch
PMs and hence PM only tags did not provide any value when added to the
Sidebar. This commit changes that by allowing the client to
differentiate PM only tag and thus routes the link to the PM tags show
route.
Counts for PM only tags section links are not supported as of this
commit and will be added in a follow up commit.
1. Replace `{{did-insert` with the builtin `{{on` modifier
2. Move the i18n call into the template
With both of those changes, there is no logic left in the backing class, so we can switch to `templateOnly()` which is significantly faster. (granted, not a big deal for a component like this, but it makes for a good demonstration)
Now that all of our singletons have been converted to true Ember Services, we can remove our custom `discourse/component/glimmer` superclass and use explicit injection
This also updates `section-message` to be a templateOnly glimmer component rather than a classic component.
Now that all of our singletons have been converted to true Ember Services, we can remove our custom `discourse/component/glimmer` superclass and use explicit injection
