We're seeing drops in CLS performance and the animation of this element
may likely be the culprit. We can try removing and seeing if this is
indeed the issue.
FormKit allows you to set `@format` on a field which will set the width
of the wrapping container of the control. However, title and
descriptions are out of this container. FormKit will now by default
applies the same format to title and description.
You can override this behavior by using `@titleFormat` and
`@descriptionFormat`.
Usage:
```javascript
// with a string
<Form as |form|>
<form.Field @name="foo" @title="Foo" @tooltip="text" as |field|>
<field.Input />
</form.Field>
</Form>
// with a DTooltip component
<Form as |form|>
<form.Field @name="foo" @title="Foo" @tooltip={{component DTooltip content="component"}} as |field|>
<field.Input />
</form.Field>
</Form>
```
Followup f55342ba6a
Fixes issues after a refactor in the linked commit.
We now pass `font` as an object to the preview JS
functions, so to get the proper font for the canvas
we need to do `font.label`.
The group has `grant_trust_level` setting which automatically updates
the trust level when the user is added to the group.
Similarly, when the user is removed from the group, the trust level is
recalculated.
There was a bug that when the trust level was downgraded, the user was
not removed from automatic groups like for example `trust_level_3`.
This brings in the change from ttf to woff2 fonts
for all our fonts.
This brings the total distributed size of our fonts down to 1.4MB (down
from 17MB) which is ~91% decrease, and most fonts are now only around
20KB max individually :slight_smile: The biggest reduction was Noto Sans
JP, which was in .otf format and ~4MB for each file.
Changing a tag name and reverting it to a previous tag name choice on
the same screen (meaning, without reloading the page) causes a 404
error.
Reproduction steps:
* Open an existing tag page https://your-discourse.com/tag/a
* Click the wrench, change the name and save
* Open edit again, revert the name to the original tag name
* 404 error
This was happening because of the way we find existing objects
in our store. Tags are using the name as the id/primary key
unlike other records in the UI. When we get the existing object
from the store we throw away the "new" ID, so we ended up with
the old tag ID on the existing object, which led to a 404. To
fix it we can just manually set the tag ID to what it is supposed
to be from params in the tag show route.
c.f.
https://meta.discourse.org/t/404-error-when-you-revert-a-tag-name-after-changing-it-without-reloading-the-page/342559
When using the following validation: `length:5,10`, if the field had no
value we would fail the validation which is incorrect. This commit
ensures we return early in this case and don't fail anymore. If you want
the same behavior you need to do: `required|length:5,10`
Prior to this fix if a field was marked as required we would never show
the none option of the select, however, some forms come with default
values and in this case we would show the first choice of the select as
selected when it would actually be null. This commit ensures that in
this case we show none, and once you select a value, you can't go back
to none.
This reverts commit 3ca4386841.
Reverting while we work on adding error handling. At the moment,
failures are logged, but the process still exits with status=0.
Allows users to save multiple topic and personal message drafts,
allowing more flexibility around content creation.
The "New Topic" button will now always start a fresh topic. Drafts can
be resumed from the drafts dropdown menu or using the "My Drafts" link
in the sidebar.
Since drafts require a unique `draft_key` and `user_id` combination, we
have updated the format of the draft key for both topics and personal
messages. They will now have a prefix like "new_topic_" or
"new_message_" with the timestamp of when the composer was first opened
appended.
This commit converts the `AdminReport` component, which is quite
high complexity, to gjs. After this initial round, ideally this
component would be broken up into smaller components because it is
getting quite big now.
Also in this commit:
* Add an option to display the report description in a tooltip, which
was
the main way the description was shown until recently. We want to use
this on the dashboard view mostly.
* Move admin report "mode" definitions to the server-side Report model,
inside a `Report::MODES` constant, collecting the modes defined in
various
places in the UI into one place
* Refactor report code to refer to mode definitions
* Add a `REPORT_MODES` constant in JS via javascript.rake and refactor
JS to refer to the modes
* Delete old admin report components that are no longer used
(trust-level-counts, counts, per-day-counts) which were replaced
by admin-report-counters a while ago
* Add a new `registerReportModeComponent` plugin API, some plugins
introduce their own modes (like AI's `emotion`) and components and
we need a way to render them
We have many problem check trackers, and some of them
like `OutOfDateThemes` can have a message which has variable
data in it shown to admins. In this case, a list of themes
that need updating. Currently if you resolve one of these
out of date themes and refresh the list of problems, you
do not see any change.
This is happening because we are only updating the `details`
of the `ProblemCheckTracker` record, not the corresponding
`AdminNotice` record which is what is displayed to the admins
on their dashboard. This commit fixes the issue by updating the
details of the notice at the same time as the problem check
tracker details.
All of these buttons use our default grey background styling, but aren't
carrying the `btn-default` class, which makes them easier to target in
themes. This PR adds the class.
Previously, for a search query with `page=11` or higher, we were quietly
returning the page 10 results. The frontend app isn't affected because
it sets its own limit to 10 pages, but still, this response from the
search endpoint does not make sense.
This change switches to returning a 400 error when the `page` parameter
is above the allowed limit (a max of 10).
We have had reports of the topic post move endpoint
sometimes timing out, not necessarily with a large
number of posts, but between two topics that have a
large number of posts.
This buys us some time by `hijack`ing the controller,
which gives us 90 seconds instead of the Unicorn 30
seconds to do the work. At some point we may want to
do this in a background job.
c.f.
https://meta.discourse.org/t/moving-posts-to-a-long-topic-fails/347984
It seems from the original commit notes that this was only included as a query
optimisation, but doing so leads to confusion: https://meta.discourse.org/t/348688
Searching for outbound mail to an address should find that address regardless
of whether or not the mail type to search for is explicitly `group_smtp`.
We used this flag for experimenting with admin plugin sidebars. We have now settled on a tabbed layout, and this is no longer needed.
This PR simply ignores the flag in a backwards-compatible way, so we can discontinue usage in plugins and then remove the backwards-compatibility in core.
Rename `min_first_post_typing_time` to `fast_typing_threshold` and
provide admin 4 options:
- disabled
- low - 1 second
- standard - 3 seconds
- high - 5 seconds
Related PRs:
- https://github.com/discourse/discourse-zoom/pull/112
