In the past, widget implementors would have to subclass the MountWidget component and wire up `didUpdateAttrs` or an observer to trigger a re-render. If that wasn't done, then it could lead to weird behaviors, especially now that page transitions in Discourse do not de-render/re-render components by default.
This commit updates MountWidget so that it re-renders whenever any input arguments change.
Browser capabilities are inherently unconnected to the lifecycle of our app. Making them formally available outside of the service means that they can safely be used in non-app-linked functions without needing risky hacks like `helperContext()` or `discourse-common/lib/get-owner`.
One example of where the old hacks were problematic is the `translateModKey()` utility function. This is called in the root of the `discourse/components/modal/keyboard-shortcuts-help` es6 module. If anything (e.g. a theme/plugin) caused that es6 module to be `require()`d before the application was booted, a fatal error would occur.
Following this commit, `translateModKey()` can safely import and access `capabilities` without needing to worry about the app lifecycle.
The only potential downside to this approach is that the capabilities data now persists across tests. If any tests need to 'stub' capabilities, they will need to revert their changes at the end of the test (e.g. by using Sinon to stub a property).
This commit also updates some legacy references from `capabilities:main` to `service:capabilities`.
These avatar-related helper functions are used in pretty-text, which currently means we load the entire `discourse/lib/utilities` module into the mini-racer when running pretty-text on the server side. This stops us adding any logic or imports to discourse/lib/utilities which may depend on other `discourse/` namespace features.
This commit moves the avatar-related utils into a dedicated module in the `discourse-common` namespace, adds backwards-compatibility shims, and updates the pretty-text config accordingly.
This implementation will need more work in the future. For simplification of tracking and other events (new thread, delete/restore OM...) we used the threads from `threadsManager` which makes pagination more complicated as we already have some results when we start.
Note this commit also simplify `Collection` to only have one `load` method which can be called repeatedly.
This adds an option to allow non-image s3 files to be downloaded through CDN URL.
Addresses the issues in:
* meta.discourse.org/t/s3-cdn-url-not-being-used-on-non-image-uploads/175332
* meta.discourse.org/t/s3-uploads-using-cdn-for-pdfs/213218
Why this change?
The specs are flaky on CI and we've unable to figure out why so we've
decided to skip them only on CI for now. The tests are still ran in our
internal build so we still have some protection in place.
Trying to fix two issues:
1. Sometimes the publish_new! event for update_thread_original_message
finishes running on the UI before the one for thread_created, in this
case we just want to do nothing because thread_created will fetch the
new thread along with its preview from the server if needed
2. Sometimes the thread GET and /read events were erroring because
last_reply on the thread was nil, this was potentially occuring because
the thread_created event was coming through to the UI before the rest
of MessageCreator was done, so we just move that after the big update
to set thread_id for the new and existing messages in the reply
chain
- Unify the silencing methods, use a WeakMap to remember the seen objects
- Export a proper plugin and use the absolute path in the config, instead
of the proprietary config from `broccoli-babel-transpiler`
The latter causes problems in Embroider which doesn't use the broccoli
based babel pipeline.
Some themes were doing `require("i18n").t()`, which was never recommended, but did work prior to f8483295. This commit restores that functionality with a deprecation notice.
What does this commit do??
This commit introduces two changes:
1. As a follow up review comment to
cc463c3e9b, we remove the top level
recipientNames cache in composer message to be a property of the
`ComposerMessage` component instead. Across components, we're more
likely to get a cache miss than a hit since we're caching the entire
recipient array so we can just drop it. If we really need this
optimisation, we should probably use a map and cache the information for
each user instead. However, the request is fairly cheap so we avoid that
optimisation for now.
2. This commit adds a debounce to `_typeReply` as well since we were not
debouncing and the method was being called each time we received the
event.
Why is this change being made?
We've decided that the previous "community" section should look more
like a primary section that holds the most important navigation links
for the site and the word "community" doesn't quite fit that
description. Therefore, we've made the decision to drop the
section heading for the community section.
As part of removing the section heading, the following changes are made
as well:
1. Button to customize the section has been moved to the "footer" of the
"More..." section when `navigation_menu` site setting is set to `sidebar`.
When `navigation_menu` is set to `header dropdown`, a button to customize
the section is shown inline.
2. The section will no longer be collapsable.
3. The title of the section is no longer customisable as it is no longer
displayed. As a technical note, we have not dropped any previous
customisations of the section's title previously in case we have to
bring back the header in the future.
4. The new topic button that was previously present in the header has
been removed alongside the header. Admins can add a custom section
link to the `/new-topic` route if there would like to make it easier for
users to create a new topic in the sidebar.
Generally follows the same pattern as #22520
There are some changes here, notably it uses the addon's babel
settings rather than the app's, and it goes through the same
treatment as the rest of the addon code (which may include more
than just babel).
However, this probably brings us closer to the normal expectations
you have around developing addon code, and in any case, does not
seem to have any effect on the final output:
```
$ diff dist/assets/markdown-it-bundle.js /tmp/dist-before/assets/markdown-it-bundle.js
```
* FIX: Default parameter recipients to create new message via params must be a string
The default parameter recipients was defined as an empty array in:
- route:application#createNewMessageViaParams
- mixin:open-composer#openComposerWithMessageParams
However, in model:composer, targetRecipient is handled as a string as can be
verified due to the existence of the #targetRecipientsArray computed property.
Using the default parameter defined as an array was causing issues with
the `discourse-bcc` plugin when opening the composer using the route
/new-message.
* DEV: Added tests for the composer messages for private messages
* Fix test naming
Co-authored-by: Mark VanLandingham <markvanlan@gmail.com>
---------
Co-authored-by: Mark VanLandingham <markvanlan@gmail.com>
Currently, the admin/wizard build relies on the addon build getting
triggered first, so that its `treeForAddon()` hook will be called,
and then it can stash the result on the app's options, which is
super fragile. In Embroider the timing works differently so the
trees end up being `undefined`.
This inverts the logic so that it will be discourse core's build
calling these hooks at a specific timing and return the result
rather than coordinating through the options bag.
```
$ diff dist/assets/admin.js dist-after/assets/admin.js
$ diff dist/assets/wizard.js dist-after/assets/wizard.js
```
Currently the I18n module shim return an object. Per AMD/loader.js,
the properties on the object becomes named exports of the module,
i.e. `import { t } from 'I18n';`.
However, this is not how we actually consume this module. We always
do `import I18n from 'I18n';`.
The returned object from the shim (`window.I18n`) does NOT have a
`default` property on it. This is only working because loader.js
has a `makeDefaultExport` feature that defaults to true, which we
are relying on to synthesize the default export for us.
That feature has been noted as undesirable and may some day be
deprecated. In Embroider, it specifically disables the feature in
loader.js.
https://github.com/embroider-build/embroider/issues/539
The `message_bus_channels` given to `MessageBus.last_ids(*message_bus_channels)` is not ordered, as a result the expectation of the tests could fail, this test ensures we check the contain of the input instead of content+order.
This commit also standardize the naming pattern of modals: `<Chat::Modal::FooBar />` and changes css class accordingly.
Co-authored-by: David Taylor <david@taylorhq.com>
When the loading slider is enabled, the rendering of `application.hbs` is slightly delayed compared to the old 'spinner' strategy. This means that if a route tried to render a dialog during its `model()` hook, the dialog wrapper element would not be present and an error would occur.
This commit detects that situation and delays rendering the error until the next runloop iteration. If the element is still not found, we print a useful error to the console.
In the long term, we should ideally convert the dialog service to use a pure-ember rendering strategy instead of leaning on a11y-dialog. But for now, this workaround should resolve the problems identified by the chat system specs.
David Taylor
chapoi
Joffrey JAFFEUX
liushuyu
Ted Johansson
Alan Guo Xiang Tan
dependabot[bot]
Martin Brennan
Blake Erickson
Godfrey Chan
Bianca Nenciu
Jordan Vidrine
Discourse Translator Bot
Selase Krakani
Kris
Sérgio Saquetim
Isaac Janzen
Meghna