Primary is a more appropriate color here than "danger". Authorizing is
important, but we usually use "danger" for destructive actions and
nothing is being destroyed here.
Overriding computed properties with arguments is no longer supported by Ember, so we need to rename this computed property and add fallback logic manually.
This fixes the styleguide 'buttons' page. Ref https://meta.discourse.org/t/styleguide-bugs/335211?u=david
When performing bulk dismissal in Unread and New views, the dismiss button stays at the top of the UI. Because of this we want to provide the dismiss action also in the "sticky" menu that's always in view, even when scrolling a long list of topics.
This reverts commit 5a00a041f1.
Implementation is currently not correct. Multiple uploads can share the
same etag but have different paths in the S3 bucket.
Follow-up to a5497b74be
In the linked commit, as part of simplifying the invite modal, we removed the option to skip sending an email when creating an invite restricted to a specific address. This has caused confusion about whether an email will be sent by Discourse or not, so we're adding back the option to create a restricted invite without emailing.
Internal topic: t/134023/48.
Followup 0568d36133
S3 itself and other S3-compatible providers do not
allow using an S3 custom endpoint and dualstack at
the same time, so this commit fixes that by not using
dualstack when the endpoint is present.
This PR ensures that admins are shown a confirmation dialog when clicking to disable 2FA for a user. The 2FA button is right below the "Grant Badge" button and as such it can easily be clicked accidentally. It's also good practice to ask for confirmation before removing important functionality.
A "bad upload" in this context is a upload with a mismatched URL. This can happen when changing the S3 bucket used for uploads and the upload records in the database have not been remapped correctly.
"Resume editing" would do nothing when going through the `/new-message` flow.
This seems to be broken since [this commit](b0f6d074be). which moved `this._setModel` calls around – the same we're doing now, but to different places: the first one needs to happen after the `draft.data` has been set , while the second needs to happen before the `this.open` call.
When we added direct S3 uploads to Discourse, which use
presigned URLs, we never took into account the dualstack
endpoints for IPv6 on S3.
This commit fixes the issue by using the dualstack endpoints
for presigned URLs and requests, which are used in the
get-presigned-put and batch-presign-urls endpoints used when
directly uploading to S3.
It also makes regular S3 requests for `put` and so on use
dualstack URLs. It doesn't seem like there is a downside to
doing this, but a bunch of specs needed to be updated to reflect this.
This PR adds a small visual change to the new feature item on the `/admin/whats-new` page. When features are marked with an experimental site setting, they should show an indication on the feature item that it is "Experimental"
When replying to a topic, the @-mention userSearch needs the topicId and the categoryId so they can trigger immediately, with sane suggestions.
This was broken when the mentions were moved from ComposerEditor to DEditor.
* UX: Apply admin table classes for consistent mobile styling on the emojis page
* UX: remove icon from the button
* UX: styling tweaks on the emoji uploader form
* UX: right align table button controls
* apply prettier
Currently, if an association is added as a tracked field in
`PostRevisor`, the `PostRevisionSerializer` class will try to serialize
it somehow. This will raise an error as ActiveRecord collection proxies
can't be serialized.
This patch addresses this issue by skipping any association tracked by
the `PostRevisor` class.
I was skimming through existing pages to get a feel for the admin UI guidelines. I noticed that this part was missing its margin. On some further investigation, it seems that a single CSS selector, .award-badge was being used both for the section and for the button in the header, so I decided to 1) separate the two and 2) add in the missing margin.
Prior to Uppy, the `uploads#create` endpoint used to receive a `type` param that indicated the purpose/target of the upload, such as `avatar`, `site_setting` and so on. With the introduction of Uppy, the `type` param became the MIME type of the file being uploaded, and the purpose/target of the upload became a new param called `upload_type`, however the backend could still use the `type` param (which now contains MIME type) as the purpose/target of the upload if `upload_type` is absent.
We technically don't need to send the MIME type over the network, but it seems like it's done by Uppy and we have no control over the `type` param that Uppy includes:
758de8167b/app/assets/javascripts/discourse/app/lib/uppy/uppy-upload.js (L146-L151)
This commit does a couple of things:
1. It amends the `uploads#create` endpoint so it always requires the `upload_type` param and doesn't fallback to `type` if `upload_type` is absent
2. It forces consumers of the `UppyUpload` class (and by extension `UppyImageUploader`) to specify `type` of the upload
Internal topic: t/140945.
This commit switches the route for the about config page to retrieve the list of site settings that control the /about page by their area instead of their individual names.
Internal topic: t/136384.
In some cases, on Safari iOS, we would recompute the "--composer-vh" variable due to a minimal change in the viewport. This ends up triggering a loop where setting this variable triggers another viewport resize event, which triggers another change of the variable...
In order to fix (patch?) this issue, we now have a 1px leeway when checking the difference between the previous and new viewport.
Internal ref - t/141088
Multiple category styles can be used on the same site. The category and
subcategories page will use the "desktop_category_page_style" setting
and individual category pages will use the style selected in settings,
if any.
Commit c1f078ca tried to use the same style for both the category and
subcategories page, but the route matching did not take into account
the "discovery.categoryAll" and "discovery.categoryNone" variants of
the "discovery.category" route.
Template overrides have been advised against for a long time, and are increasingly hard to maintain as Discourse's development accelerates. This commit officially deprecates this customization method, which will be removed in the not-too-distant future (likely in the first half of 2025).
From plugin-api comment:
Registers a new tab to be displayed in "more topics" area at the bottom of a topic page.
```gjs
api.registerMoreTopicsTab({
id: "other-topics",
name: i18n("other_topics.tab"),
component: <template>tbd</template>,
condition: ({ topic }) => topic.otherTopics?.length > 0,
});
```
You can additionally use more-topics-tabs value transformer to conditionally show/hide
specific tabs.
```js
api.registerValueTransformer("more-topics-tabs", ({ value, context }) => {
if (context.user?.aFeatureFlag) {
// Remove "suggested" from the topics page
return value.filter(
(tab) =>
context.currentContext !== "topic" ||
tab.id !== "suggested-topics"
);
}
});
```
Recently we added a new feature for automatically gridding images in the composer (https://github.com/discourse/discourse/pull/29260). After testing this feature under a setting for a short period of time, the feature is no longer experimental anymore.
This PR removes the site setting `experimental_auto_grid_images`.
Allows anonymous users to download the calendar file. Before, they were given the option, but it would fail silently with a `TypeError: Cannot read properties of null (reading 'user_option')`.
I have been unable to figure out a way of testing this usefully (as I fear it would require creating several thousands of objects), but existing tests pass and a manual test with ~400k topics succeeds after the fix, while it would hang indefinitely and/or consume all disk space before the fix.
I have reported the initial problem and my findings in https://meta.discourse.org/t/topic-reset-all-highest-exhausts-all-available-disk-space/333837
The primary key is usually a bigint column, but the foreign key columns
are usually of integer type. This can lead to issues when joining these
columns due to mismatched types and different value ranges.
This was using a temporary plugin / test API to make tests pass. After
more careful consideration, we concluded that it is safe to alter the
tables directly.
We are moving away from the mobile-specific template pattern in favor of logical `{{#if}}` statements. This brings us closer to a standard Ember app, makes testing easier, and reduces duplicate code.
This commit includes some minor refactoring in the resolver & component-templates initializer, so that the mobile lookups happen on desktop, without actually being used. This allows us to print the deprecation message consistently, to improve visibility to developers.
This commit fixes the (?) tooltips for reports on
the admin dashboard on mobile.
The fix is that float-kit instances can now have different triggers
and un-triggers for mobile and desktop, and float-kit is now aware
of the site being in mobile view.
Example usage:
```
@triggers={{hash mobile=(array "click")}}
```
So now, if you press on the tooltip trigger on mobile it shows
correctly, and on desktop both hover and click can be used.
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Currently the tracking for clicked links are injected into the HTML in a span tag. This leads to the link counter value being highlighted when copying and pasting. Additionally, any means for using CSS to hide link counters result in a gap due to it occupying a specific width.
With this change, we make link counters appear in a data attribute on the link element and visually shown with CSS `::after` element.
We are moving away from the mobile-specific template pattern in favor of logical `{{#if}}` statements. This brings us closer to a standard Ember app, makes testing easier, and reduces duplicate code.
We are moving away from the mobile-specific template pattern in favor of logical `{{#if}}` statements. This brings us closer to a standard Ember app, makes testing easier, and reduces duplicate code.
We are moving away from the mobile-specific template pattern in favor of logical `{{#if}}` statements. This brings us closer to a standard Ember app, makes testing easier, and reduces duplicate code.
We are moving away from the mobile-specific template pattern in favor of logical `{{#if}}` statements. This brings us closer to a standard Ember app, makes testing easier, and reduces duplicate code.
We are moving away from the mobile-specific template pattern in favor of logical `{{#if}}` statements. This brings us closer to a standard Ember app, makes testing easier, and reduces duplicate code.
Docking is a leftover from older header code, it looks like it is no
longer used in the app. This helper was registering a scroll event
listener to check if the header should be docked or not. Initially, a
"docked" class was added to the body element. This class persisted
through the lifecycle of the app and the scroll event was doing no
useful work.
Some older themes may still use it in CSS, that will cause a regression,
from a quick look at existing code, the surface area should be small
(2-3 themes). It's worth removing the event listener for performance
reasons. We could possibly add the class "docked" statically to the body
element, but it's redundant. It's best to clean up the relevant CSS in
themes, where applicable.
This commit adds a new "Community title" field to the about config page. This field controls the `short_site_description` setting, which is shown in the browser tab for key pages such categories pages and topic lists.
Internal topic: t/140812.
Followup bd4e8422fe
In the previous commit, we introduced the `page_view_legacy_total_reqs`
report. However this was not tested properly, and due to a typo
the report returned no data.
This commit fixes the issue and adds a spec to catch this.
* DEV:refactor user badges create to get grant opts from method
* Replace method overwrite with plugin modifier
* Add aditional params
* change modifier name
The `categories_only_optimized` category page style has been introduced
in commit d37a0d401c. This commit makes
sure that style is enforced for users who can see over 1000 categories
in order to keep `/categories` page functional.