Whenever you are about to reach the limit of users in a group DM, if you
send requests to add new users in parallel, they might all go through
ignoring the limit due to a race condition.
Internal - t/145895
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.
The URLs returned by DiscourseConnect for the user's avatar, profile and
card backgrounds were not always correctly handling CDN.
This make use of the `GlobalPath.full_cdn_url` helper method which has
been battle-tested.
Ref - https://meta.discourse.org/t/-/356599
`/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.
The tests being fixed in this commit are not waiting for the
asynchronous behaviour of bulk closing topic to complete before running
some of the assertions. This commit updates the tests to check for the
asynchronous behaviour to complete so that the following assertions will
pass with more reliability.
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.
Currently, the light version of mobile logo falls back to the desktop
version if the mobile version isn't set. It makes sense to have the same
fallback rule for the dark version as well, i.e. if there's no dark
mobile logo, use the dark desktop logo.
Internal topic: t/150316.
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.
Currently, anonymous/shadow users go through the same permission checks
for chat as normal users do. This means that if a site has chat enabled
for all users, anonymous users also get access to chat. This may be
undesirable for some communities, so we're adding a new site setting
`allow_chat_in_anonymous_mode` to block access to chat for anonymous
users.
Internal topic: t/148088.
This change allows more flexibility when starting a 1-1 direct message
with another user. If there are no messages in the new DM channel then
we should still allow them to add additional users.
This commit removes an assertion for the redirect after 2FA
authentication is success message because the message is flashed briefly
before a route transition happens. A proper fix would require us to
redesign when/how the flash message which we can address in the future.
