If, for some reasons, navigating between posts using j/k keyboard
shortcuts does not select any posts, there could be an infinite loop
due to setting the `direction` to `0` and then using it do "iterate"
over the arrays of available "articles".
Despite many attemps, I wasn't able to reproduce the issue reported in
https://dev.discourse.org/t/145565 so this is somewhat of a shot in the
dark.
Follow-up to 5a55c9062a
There are many scenarios that can result in creating a `ReviewableQueuedPost` record, however in the original commit we only added once scenario to the populate rake task. This commit adds the remaining scenarios to the rake task.
This pull request is doing the following changes:
prevents clicking on a section to scroll the document body
do not show favorites section if empty
do not close the user-status modal on emoji selection
giving its own context for user-status picker, that way if you frequently use same emojis for the picker they will always be in favorites
In 15a7a84d84, I changed the `linting`
workflow to run on `ubuntu-latest` because it is free and helps to free
up our self hosted runners for more important workflow jobs. However,
some devs rely on the `linting` workflow for feedback so we want to
provide this feedback as soon as we can. Therefore, we are putting the
`linting` workflow back on our faster self hosted runners.
Previously we would enqueue sidekiq jobs like `PostProcessCooked` **before** triggering the `topic_created` and `post_created` DiscourseEvents. That means that, depending on the speed/availability of Sidekiq, PostProcessCooked might start running on another host before the DiscourseEvents have been executed.
This commit moves the event triggers before enqueue_jobs, so that ordering is guaranteed to be consistent, regardless of Sidekiq performance.
Following on from f369db5ae9, we need to apply a similar fix to inline oneboxes, since they use a different code path to retrieve the onebox provider data.
This change ensures the Accept-Language header is sent by inline onebox requests, too.
Following on from f369db5ae9, this change adds the ability to choose a custom locale to send to onebox providers.
If this setting is left blank, it will fall back to using default_locale.
This PR moves the logic from the nameValidation mixin to a helper class. I've opted to maintain the interface of the previous classes through native getters in combination with dependentKeyCompat so that we limit the amount of changes here (these are referenced in the string form and across classes/templates), and avoid introducing more computed properties from the old reactivity system (alias, readOnly etc.).
We now return a POJO for nameValidation since returning an EmberObject makes no difference here.
Deprecation warning added to the nameValidation mixin as it's still used in a plugin.
3135f472e2 added a nifty new FontSelector component, which creates a dropdown where each item is styled in the font that it corresponds to.
This change uses the new component to style the base_font and heading_font site setting selectors, too.
On WebKit-based browsers, triple clicking on the last paragraph of a post won't stop at the end of the paragraph, leaking the selection into the following nodes until it finds a non-empty node.
This commit introduces a workaround to fix this behavior.
Onebox embeds currently default to accepting any language response from the destination, which can have some surprising behaviour. For example the `curl` equivalent of what Onebox does:
```
% curl -si -H "Accept-Language: *" 'https://developer.android.com/studio' | grep location:
location: /studio?hl=hi
```
This PR uses the value of `SiteSetting.default_locale` to populate the `Accept-Language` header, falling back to English if that isn't available, then finally accepting whatever language the destination makes available.
- uses emojiSearch to ensure we have the same result than autocomplete when filtering emojis (for example search aliases were not working correctly because of this)
- reset the visible sections when clearing filter to ensure we are not attempting to display all the emojis at once which would be slow
- prevents flashing of the full emoji list before showing filtered results
- correctly reset recent favorites and only show them when used
In the api docs note that `silence_reason` and `can_be_deleted` are
optional responses for the admin user api response.
Follow up to: 9cf78ba195
> TODO @blake / @sam - this is not passing cause "silence_reason" is a conditional attribute
> (also can_be_deleted is) - we need to figure out how to not include it in the schema - it is not included
> in the admin response by design
I'm not sure if this is a real-world consideration... but our `test/smoke-test.mjs` script runs chrome with `--disable-local-storage`, so it needs to work.
This commit introduces a new 'dev tools' feature for core, theme and plugin developers. This is enabled by default in development environments, and can be enabled in production by running `enableDevTools()` in the browser console.
When enabled, it will load a separate dev-tools JS/CSS bundle, and show a new toolbar on the left of the page. Dev Tools will remain enabled until the 'x' button is clicked, or `disableDevTools()` is run in the console.
The toolbar currently has three buttons:
- "Toggle safe mode" provides an easy way to toggle all themes/plugins on/off
- "Toggle verbose localization" is a toggle for our existing locale debugging feature
- "Debug plugin outlets" is inspired by the popular 'plugin outlet locations' theme component. It hooks into core's plugin outlet system, and renders a button into every single outlet. Those buttons have a tooltip which shows more information about the outlet, including all of the outletArg values. To inspect the value further, buttons allow the values to be saved to globals and logged to the console.
All of this is implemented under `/static`, and is only async-import()-d when the dev tools are enabled. Therefore, we can continue to add more tools, with zero performance cost to ordinary users of Discourse.
This will cause the glimmer topic-list to be enabled for sites with compatible customizations. Incompatible customizations will print a deprecation message to the console, along with a link to more information.
Also cleans up a handful of specs/behaviour which were revealed by switching the default.
More details at https://meta.discourse.org/t/343404
Now that we correctly await for the modal to close, we dont need to special case and disable focusTrigger, the flow will now be:
- click an element of the menu
- wait for modal to close
- focus trigger
- trigger action, which will eventually open a modal and attempt to focus the first item
The chat emoji picker is renamed emoji-picker, and the old emoji-picker is removed.
This commit doesn't attempt to fully rework a new emoji-picker but instead tries to migrate everything to one picker (the chat one) and add small changes.
Other notable changes:
- all the favorite emojis code has been mixed into one service which is able to store one state per context, favorites emojis will be stored for all topics, and for each chat channel. Meaning that if you always use a specific emoji in a channel, it will only show as favorite emoji in this channel.
- a lot of static code has been removed which should improve initial load perf of discourse. Initially this code was around to improve the performance of the emoji picker rendering.
- the emojis are now stored, once the full list has been loaded, if you close and reopen the picker it won't have to load them again.
List of components:
- `<EmojiPicker />` will render a button which will open a dropdown
- `<EmojiPickerContent />` represents the content of the dropdown alone, it's useful when you want to render a picker from an action which is not the default picker button
- `<EmojiPickerDetached />` just a simple wrapper over `<EmojiPickerContent />` to make it easier to use it with `this.menu.show(...)`
---------
Co-authored-by: Renato Atilio <renatoat@gmail.com>
This adds the Silence Reason column to silenced user lists.
This feature helps combat large spam attacks cause you can quickly see
why a user was silenced and then bulk act on all the silenced users
Meta topic: https://meta.discourse.org/t/full-name-at-sign-up-went-missing/345662/17?u=osama
The preloaded `site` object for anons on login-required sites is a stripped down version of the full object with just a specific set of attributes and doesn't use the site serializer. This results in the `full_name_required_for_signup` and `full_name_visible_in_signup` attributes not making it to the client app when a login-required site is accessed by an anon, causing the name field in the signup form to not be rendered, even when it's required.
This commit includes those attributes in the stripped down version of the `site` object that's used for anons on login-required sites.
