This moves CSS from mobile/compose.scss and desktop/compose.css into
common/compose.scss and removes some old unused CSS in the process.
In addition:
* Prevents the grippie div from rendering on mobile, rather than hiding
the div with CSS
* Prevents the composer education messages from rendering on mobile,
rather than hiding them with CSS
* Wraps the `#draft-status` container with a condition instead of its
children, preventing the empty div from rendering when it's not used
* Adds a missing `btn-transparent` class to the mobile controls toggle
This switches the signup/login UI to the full page experience by
default. This has been in use by many sites for multiple months and we
have ironed out many fixes in the meantime.
The `full_page_login` setting is also marked for removal in about
1.5mths, by the end of April 2025.
This allows more flexibility for custom behaviours.
Example usage:
```gjs
@action
onSet(value, { set, name }) {
set(name + ".0.baz", value * 2)
}
<form.Object @name="something" as |object|>
<object.Field @name="foo" @title="Foo" @onSet={{onSet}} as |field|>
<field.Input />
</object.Field>
</form.Object>
```
There is no current plugin outlet on the Topic List which allows one to
attach additional UI after the title without messing up the badge
display.
We can’t use `topic-list-after-title` because that will render before
the badge which looks untidy:
... and we can’t use`topic-list-before-category` because that’s not
always rendered when we drill into a Category.
The solution is a new plugin outlet located after the badge is rendered.
This needs to be on both the desktop and mobile flavours.
See discussion here:
https://meta.discourse.org/t/locations-plugin/69742/1144?u=merefield
This commit unskips 3 flaky system tests and gives up on asserting that
redirecting is done correctly. This is because we have invested
considerable effort into this and cannot figure it out. The redirect is
tested by the client side anyway so there is still some test coverage.
We currently have `user_color_schemes` serialized on the preloaded
`Site` object, but it's very lightweight, only having an ID and name.
It would be useful for some themes and also the user Interface
preferences tab to be able to access the colors for the color scheme,
as well as the theme it belongs to.
This commit expands the serializer to include these extra attributes.
This `user_color_schemes` key is already cached as a fragment, so this
shouldn't be too much extra burden to send to the client.
Tight lists are lists that look like this:
* Item 1
* Item 2
* Item 3
Loose lists look like this:
* Item 1
* Item 2
* Item 3
There is a place for the latter, but the former is more
common default behaviour for writing apps and widgets, so
we are overriding the prosemirror default to use tight lists.
Eventually we will have a shortcut or other special behaviour
to switch between the list styles.
When editing a color palette via the new page introduced in
https://github.com/discourse/discourse/pull/31742, it should apply the
color changes for the admin making the change automatically upon save.
Internal topic: t/148628/12.
We intend to replace this JQuery autocomplete implementation soon. But
before that, we'd like to drop the raw-hbs compilation/runtime system.
Therefore, this commit does a 1:1 conversion of the autocomplete
templates to vanilla JS. They're fairly small/simple, so they're still
fairly readable.
Concerns this little fading scroll affordance in the horizontal overflow
nav:
The parent container of the user nav has an optional
`--d-content-background` variable applied, and adding this for the nav
means that if a theme author uses `--d-content-background` the nav will
match automatically. When `--d-content-background` is not set, we fall
back to `--secondary` which is the default background.
I also realized that we don't need RGB values here since we're simply
fading from a solid color to transparent.
`/categories` sometimes returns accompanying topics under certain site
settings. The `CategoryList` currently allows preloading for topic
custom fields via `preloaded_topic_custom_fields`, but not for topics
themselves.
This addition is required for
https://github.com/discourse/discourse-solved/pull/342.
When multiple admins are working in the review queue, it's quite easy for two people to try and handle the same reviewable at the same time. This change addresses the two major situations where this can occur.
The `ReviewableClaimedTopic` model has been extended to allow the system to mark a reviewable as claimed as soon as the first moderator starts handling the reviewable, even when the `reviewable_claiming` setting is disabled. This ensures that reviewable actions with client-site activity (for example, `agree_and_suspend`) will lock the reviewable before another moderator starts working on it.
When someone handles handles a reviewable, we now use `MessageBus` to inform other moderators that it's changed. If any of the other moderator have that reviewable open (either individually, or on the list screen), it will automatically refresh that data.
We didn't have support in the #problem constructor for multiple targets, forcing developers to manually construct a Problem instance. This involves a lot of details and is error prone.
This PR supports passing an optional target argument to the constructor. This will be passed on to the translation_data method to generate the correct message as well.
When logged in and visiting another user's drafts page, we should
redirect back to the current user drafts page.
For non auth users, we can redirect back to the forum `/latest` page.
This PR renames a couple of settings related to anonymous mode:
1. `allow_anonymous_posting` → `allow_anonymous_mode`. This setting is
used as a switch for the entire anonymous mode feature, so it makes
sense to give it a generic name that better reflects what the setting
does.
2. `allow_anonymous_likes` → `allow_likes_in_anonymous_mode`. The new
name is clearer and will match a new setting that we'll add to allow
anonymous users to post in chat.
Internal topic: t/148088.
Meta:
https://meta.discourse.org/t/cant-erase-the-bookmark-search-input/357861/4
> When we fill in the bookmark search input and send the request, then
we can’t delete the input’s content.
After removing the last character, the `searchTerm` getter is called. At
this point, `_searchTerm` is empty.
However, `this._searchTerm || this.q` will treat the empty string as
_falsy_, and the `q` value is displayed instead.
It makes it impossible to clear the input.
To fix this, we check specifically on the initial state of
`_searchTerm,` which is _undefined_, to include an empty string as a
valid value.
Note: because of `@computed`, the issue is not triggered when the
content is selected and deleted.
Refactors the use of the buffered-content mixin to native getters on the
dependent classes.
This mixin previously provided a cached wrapper around an instance of
BufferedProxy and added 2 convenience methods aliasing BufferedProxy
methods.
### Main changes:
* Use of the`@cached` decorator to maintain parity with the previous
version of `this.buffered` to make sure we only refresh the buffered
proxy if the dependent property changes.
* _Not entirely sure if @cached + @dependentCompat is more performant
than just using `@computed`_
* Use of the`@dependentCompat` decorator to ensure backwards
compatibility of the getter with computed properties - we will leave
refactoring of those somewhere down the road as that would greatly
increase the scope of this PR
* `applyChanges` / `discardChanges` are the same as
`applyBufferedChanges` / `discardBufferedChanges` for BufferedProxy
Accessing a component-rendered DOM element from a service is not ideal,
and can lead to timing issues. We've attempted to work around this using
`afterRender`, but it's still not ideal.
This commit moves the `A11YDialog` setup into a modifier. Now the
service only stores state, and the component renders things based on
that state. This is much more in line with Ember norms, and should be
much more robust.
Test adjustments are because the dialog element is now only rendered
on-demand, rather than being present in the DOM all the time. This
brings dialog inline with our Modal system.
This commit updates the 2FA token submission page to disable the submit
button when the 2FA token is not valid and to also set the submit button
to be in the loading state after the submit button has been clicked.
The UX issues were discovered while I was investigating a flaky test
which has been unskipped in this commit as well. I am not sure if this
will completely resolve the flakiness but we have to unskip it to know
if it continues to be flaky.
Now we have the search input showing in a few
different configurations:
* Welcome banner
* Header field
* Header icon
And we can get to the search with both `/` and
`Ctrl+F` shortcuts. These configurations can
be used together, and we need to focus on the right
search input at the right time.
This commit fixes the shortcuts not working
or showing the wrong thing in some cases,
and adds a comprehensive system spec for all
the variants.
We often need to be able to change the format of a container and to
change the flex-direction, this is now possible through two properties:
`<form.Container @format="large">`
`<form.Container @direction="column">`
On top of this `Object` has now a similar behavior to `Collection`. It
will be displayed as flex, add gap between children and accepts
`...attributes`.
Ideally we would add support for color spaces like okclh to the app, or
have some method for converting them to rgb automatically. But for now,
this will stop the app crashing completely.
We want to give some themes more control over
the default experience in core. To this end, this
commit adds value transformers for these
site settings:
* enable_welcome_banner
* search_experience
This way, themes can give a different value to
what has been set in core.
This can be potentially confusing, a follow up PR
may refactor this a bit so there is a more direct
correlation between the setting and the transformer
so we could show a warning in the site setting page
for example.
Commit f1700ca58929bcbfad23565861d1d3084ae1b3f8 ensures that categories
are loaded lazily, in pages, if the number of visible categories is over
1000. This affected the list of subcategories on the category page too.
The logic has been changed to only paginate if the number of categories
that would have been returned is grater than 1000. For example, if there
is a parent category filter, pagination will only be enforced if the
number of subcategories is over 1000.
Uses `getCaretCoords` from the text manipulation implementation to rely
on each editor's strategy to get the caret (left,top) positions.
This is mostly to fix an issue on Safari, where the virtual element
approach doesn't work, but also improves the emoji picker positioning
when triggered from autocomplete in the Markdown editor.
Fixes an incorrect logic on `transformPasted` that was causing a
`TypeError: Cannot read properties of null (reading 'marks')` when only
part of a paragraph was selected.
Adds tests
