Using the (array) helper creates an array instance, passes it to applyValueTransformer, which then allows themes/plugins to mutate it.
When the helper is re-computed, the **same array instance** is passed to the transformers again. Any elements added in the last run are still there.
This commit moves applyValueTransformer to a getter, so that it's run with a brand new array each time.
This commit introduces <NotificationsTracking /> which is a wrapper component around <DMenu /> which replaces the select-kit component <TopicNotificationsButton />.
Each tracking case has its dedicated component:
- topic -> `<TopicNotificationsTracking />`
- group -> `<GroupNotificationsTracking />`
- tag -> `<TagNotificationsTracking />`
- category -> `<CategoryNotificationsTracking />`
- chat thread -> `<ThreadNotificationsTracking />`
When fetching DM channels, we would fetch all the user's DM channels,
and limit the number of DM channels we display on the client-side using
the `DIRECT_MESSAGE_CHANNELS_LIMIT`.
This is obviously not scalable as users are having more and more
discussions with other users.
This commit ensures we always limit the number of DM channels we send to the
client.
It adds the `MAX_DM_CHANNEL_RESULTS` in `ChannelFetcher` and use it to
limit the records returned by the server. This value should always be
lower than `DIRECT_MESSAGE_CHANNELS_LIMIT` on the client-side, so that
when the user has more "unread DMs" they still show up on the client as
they read them.
While adding a spec, I also updated the spec that ensures we have a
limit on public channels to use `stub_const` to temporarily lower the number
of fixtures we create during the test.
Previously, theme hbr files were compiled to an IIFE, which would be executed before the app is booted. That is causing silenced deprecations to be printed, because the deprecation-workflow isn't set up when the IIFE is run.
This commit updates the theme compiler so that it matches the ember-cli-based raw-hbs compiler. Templates are output to normal modules, which will then be loaded by the existing `eager-load-raw-templates` initializer. This runs after the app has started booting.
* DEV: add db consistency check for UserEmail
* DEV: add db consistency check for UserAvatar
* DEV: ignore inconsistent data related to user avatars when deciding whether to rebake old posts
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
---------
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
This reverts commit 9694dc6cb0.
Some of our previous email styling depended on this 'incorrect' ordering, so the change caused some text to become illegible. Reverting while we work out a better solution
This feature writes a stack trace as part of the message. That means it is not sourcemapped by the browser, and you have further to scroll to find the real backtrace.
In the past we avoided this feature with our production 'deprecation shim', but that was removed as part of our Ember 5.12 upgrade.
When viewing your own user profile, we offer the ability to expand / collapse your user info.
By default, the info are collapsed and the button to toggle it only worked once. Meaning you could expand the info but not collapse it back.
This fixes the issue by using `toggleProperty()` instead of directly `set()`-ing a value.
Also added an acceptance test to ensure it doesn't regress.
Was reported in https://meta.discourse.org/t/342254
This will help us keep consistency with things that we've decided to rename. Initial rules are for "color scheme" -> "color palette", and "private message" -> "personal message".
Also updates some remaining occurences of "color scheme" in our translation files.
Co-authored-by: Gerhard Schlager <gerhard.schlager@discourse.org>
Collections were an existing concept in FormKit but didn't allow nesting. You can now do infinite nesting:
```gjs
<Form
@data={{hash
foo=(array
(hash bar=(array (hash baz=1))) (hash bar=(array (hash baz=2)))
)
}}
as |form|
>
<form.Collection @name="foo" as |parent parentIndex|>
<parent.Collection @name="bar" as |child childIndex|>
<child.Field @name="baz" @title="Baz" as |field|>
<field.Input />
</child.Field>
</parent.Collection>
</form.Collection>
</Form>
```
On top of this a new component has been added: `Object`. It allows you to represent objects in your form data. Collections are basically handling arrays, and Objects are objects.
This is useful if you form data has this shape for example:
```javascript
{ foo: { bar: 1, baz: 2 } }
```
This can now be mapped in your form using this syntax:
```gjs
<Form @data={{hash foo=(hash bar=1 baz=2)}} as |form|>
<form.Object @name="foo" as |object name|>
<object.Field @name={{name}} @title={{name}} as |field|>
<field.Input />
</object.Field>
</form.Object>
</Form>
```
Objects accept nested collections and nested objects. Just like Collections.
A small addition has also been made to `Collection`, they now support a custom `@tagName`, it's useful if each item of your collection is the row of a table for example.
This PR cleans up some unnecessary CSS which are not used anymore. Support of sidebar in chat has a long history due to the various steps leading to the sidebar as we know it today.
Currently, there are two ways (kind of) for accessing `params` inside a
service:
- when there is no contract or it hasn’t been reached yet, `params` is
just the hash that was provided to the service. To access a key, you
have to use the bracket notation `params[:my_key]`.
- when there is a contract and it has been executed successfully,
`params` now references the contract and the attributes are accessible
using methods (`params.my_key`).
This patch unifies how `params` exposes its attributes. Now, even if
there is no contract at all in a service, `params` will expose its
attributes through methods, that way things are more consistent.
This patch also makes sure there is always a `params` object available
even when no `params` key is provided to the service (this allows a
contract to fail because its attributes are blank instead of having the
service raising an error because it doesn’t find `params` in its context).
`<DSelect />` is a wrapper similar to our existing `<DButton />` over the html element `<select>`. The code is ported from form kit which is now directly using `<DSelect />`. Note this component has also been used in edit topic timer modal.
This component is recommended for a small list of text items (no icons, no rich formatting...).
Usage:
```gjs
<DSelect class="my-select" @onChange={{this.handleChange}} as |select|>
<select.Option @value="foo" class="my-favorite-option">Foo</select.Option>
<select.Option @value="bar">Bar</select.Option>
</DSelect>
```
This commit comes with a set of assertions:
```gjs
import dselect from "discourse/tests/helpers/d-select-helper";
import { select } from "@ember/test-helpers";
assert
.dselect(".my-select")
.hasOption({ value: "bar", label: "Bar" })
.hasOption({ value: "foo", label: "Foo" })
.hasNoOption("baz");
await select(".my-select", "foo");
assert.dselect(".my-select").hasSelectedOption({value: "foo", label: "Foo"});
```
We can't delete the file from disk as some of the assets are still
served by the app instead of going through the S3 bucket. It is a bug we
need to fix but it also means this ENV is unsafe now. Just drop the env
until we ensure all assets requested by the app are requested from the
S3 bucket directly.
Introduces a new component used to show a grid of stats
on any page, mostly used for dashboards and config pages.
This component yields a hash with a `Tile` component property,
and the caller can loop through their stats and display them
using this component.
Each stat needs a @label and a @value at minimum, but can
also pass in a @tooltip and a @url.
