This sets the stage for being able to consolidate Like notifications
using full names. It also is crucial to this [Reactions plugin
PR](https://github.com/discourse/discourse/pull/31292).
The Like consolidation PR will come after these.
`consolePrefix()` is an expensive operation (it throws a synthetic
error, then parses the backtrace), so we should only do it when
absolutely necessary
On the topic-list page, this provides a 3-4% improvement in "init to
render" times.
Follows up: https://github.com/discourse/discourse/pull/31107
This PR replaces the use of the UsernameValidation mixin with the helper
class for the InvitesShowController and CreateAccount modal component,
and deletes the mixin.
Permalink search regressed in
https://github.com/discourse/discourse/pull/30633 where the search
implementation was changed from server side to client side. Prior to
that change, we included a `filter` param in the request to make the
server find permalinks that matched the given filter and return the
results limited to 100 records. However, with that change, we stopped
sending the `filter` param with the request, which made the server
always return the same 100 records which would then be filtered on the
client side. That means if a site has more than 100 records, any records
that don't make it in the first 100 will never be found using search.
Meta topic:
https://meta.discourse.org/t/permalinks-no-longer-has-a-way-to-search-or-show-all-permalinks/351922?u=osama
Followup to 310cd513d88e3670c7008682ae4b35414084a17d. The `uploadDone`
callback returns the whole upload object, so we need to extract the URL
from it in these cases.
The current code was doing:
- initial value for `showPreview`
- setting another default value in `_setupPreview`
The fix is to move all the computation in one initial step when
initializing the property.
This changes makes relative date formats consistent for both tiny and
medium formats.
Previously we were removing 12 hours from the date for medium format
when it was more than 2520 minutes (42 hours) but not for tiny date
formats.
- Switch to use new `<DecoratedHtml` component (including
`renderGlimmer` support)
- Updates click handling to use `{{on` modifier instead of manual event
listener setup/teardown
- Remove JQuery
- Move decoration into `components/post-item`, instead of managing it
from the top-level user-stream component
- Use new `DecoratedHtml` component
This commit allows admins to filter the list of feature
feed items on the "What's new?" page to _only_ show experiments.
This is useful to both find existing experiments they may have
enabled, and to get a better overview of new ones they would
like to try.
This will eventually not be required when we build a dedicated
config page for experiments.
```
WARNING: Sass's behavior for declarations that appear after nested
rules will be changing to match the behavior specified by CSS in an upcoming
version. To keep the existing behavior, move the declaration above the nested
rule. To opt into the new behavior, wrap the declaration in `& {}`.
More info: https://sass-lang.com/d/mixed-decls
```
Related:
40fd82e2d1
This PR introduces three new plugin modifiers attached to
- `basic_post_serializer.cooked`
- `basic_topic_serializer.fancy_title`
- `topic_view_serializer.fancy_title`
Implementation note: I had wanted to add them in the `Post` and `Topic`
models themselves, but they do not directly provide access to the
request's scope which is needed for the use case.
This fixes the destination of the auth process in the following
scenarios:
- when landing on a PM or a topic as an anonymous user and then loggin
in
- when landing on a public topic, hitting Reply or Like and then logging
in
Eventually, this new component will be used everywhere that we render
'decorated' HTML (e.g. all posts and chat messages). It takes the best
bits from our main widget-based post rendering and re-creates it in a
more ember-native way. For example:
- The HTML is first rendered in a detached DOM, so that requests for
images/iframes/etc. are not triggered until after the decoration
- HTML generation and decoration is done in a helper (i.e. during the
'render' phase of the runloop). I think that's the 'most Ember
compatible' way for us to do this. It means that components added via
`renderGlimmer` will be rendered in the same runloop, and it means that
things like `schedule("afterRender")` will work exactly as expected.
- HTML will be re-rendered and re-decorated whenever the `@html` or
`@decorate` arguments change
- BUT, `untrack` is used to ensure that reactive state accessed inside
the decorate function will not trigger a re-render. This is mostly for
compatibility with existing decorators, and we may want to make
reactivity opt-in in future
- A self-contained `renderGlimmer` system is included. This will allow
`helper.renderGlimmer` to be used for any content in these components.
Implementing it in a self-contained way rather than using the service
means that the component will work ok in unit tests, and that rendered
components will show up in the right place in the Ember inspector.
This commit only introduces the new component in DiscourseBanner.
Followups will introduce it elsewhere.
Ember workaround to ensure that a field with the same name is correctly
destroyed/created when changing the params and then correctly calling
registerField/unregisterFIeld.
...loading an invite link that points to a topic they already have
access to.
This "feature" was removed in 07ef1a80a1461123d602c57e366974aed265a91e
as part of the security fix.
Internal ref - t/145628
Currently when using the shortcuts to delete a post the UI would show
you the confirmation modal even if you don't have the right to do it.
This commit fixes the issue at the root in the
`deletePostWithConfirmation` function.
This was intended to provide a better UX for interactive elements in the
composer preview. However, the morphing strategy has irreconcilable
conflicts with our `decorateCooked` API, and so we have been unable to
enable this by default.
Going forward, we're focussing efforts on the WYSIWYG composer to
provide this kind of smooth UX, so we're dropping the
`enable_diffhtml_preview` approach.
