A regression introduced in 32c8aa0aad880bcab372ffd75bce3c857060d721
incorrectly passes label to the trigger component, but also passes
translatedLabel instead of label to the menu.
The existing test was checking for the presence of "label", but it was
actually returning true because the test was showing "en.label". The
test has been modified in consequences.
In a few places throughout the app, when we render the `<GroupChooser
/>` component, we fetch the full groups list of the site from the
`/groups/search` endpoint. This is wasteful because the full groups list
is already included in the preloaded data that's sent to the client app
on the initial page load, so we can just use this preloaded list for
`<GroupChooser />` and we can avoid making an HTTP request.
Internal topic: t/147297.
This property allows to have a custom component for the DMenu trigger
instead of using a `DButton` which comes with its own css class for
example.
Example:
```gjs
const myComponent = <template><span ...attributes>test</span></template>;
<DMenu @triggerComponent={{myComponent}}>...</DMenu>
```
⚠️ It's important to pass the attributes otherwise your custom
trigger won't work.
The weekly job can take more than 2 hours to run on larger sites. It is
ideal for the jobs to be as small as possible and this is what this
commit attempts.
This reverts commit 91e9c1c81343990d5ebbb3a3bb7c68ec4445d610.
After feedback, for now we are reverting this change. This is not
permanent, the settings sidebar will be removed again, after we:
* Visually group the settings the same way as the sidebar does
on All Settings
* Add more settings pages to the main admin sidebar to cover the ~250
settings not yet represented there
Currently, if creating an API key in "granular" mode, and not selecting any scopes, a globally scoped API key is created. This can be surprising and is not ideal. Having a key with no scopes isn't useful in the first place, so this PR adds client- and server side validations to check that at least one scope is selected if using "granular" mode.
This fixes an issue where the topic invitation rate limiter
for invites for the 1 minute period was incorrectly using
1 day as the length of time the limit should be applied over.
The default for `max_topic_invitations_per_minute` is 5,
so this would be very easy to exceed, then the user gets
a very confusing warning message saying they have to wait
23 hours to send more invites.
This commit also makes other `RateLimiter` period parameters
more consistent by always using the form `N.PERIOD` instead
of things like `86_400` hardcoded seconds per day.
After you've selected and deselected text, `selection.rangeCount` will
return `true` on future events. Checking for `selection.toString` is
more robust.
Followup to f1bdd86a8c9bec03b962167c37963b1d11d0e5ea
- Add `composer-service-cannot-submit-post` transformer to allow for disabling submit based on custom conditions
- Add tests for transformer
- Add a couple helpful appEvents, that plugins can use add custom error popups to plugin-defined fields.
Updates the create topic button to be icon only (mobile) due to screen
space restrictions. The icon is also updated to make it easier to
understand what the button does, even when there is no text.
This change makes it possible to render the action code from small
action posts (ie. close topic etc) without the relative date. This is
applied in the user stream items to prevent duplication of dates.
Small alignment fix for user stream items on desktop, following changes
made in #31122
We currently have a combination of `post-list-item` and
`user-stream-item` classes within these pages, so I've also applied some
shared styles to these elements to provide a more consistent layout.
6fd577d97d3923cec3d2458f45ebd2704703fd22 widened the scope of
`use_email_for_username_and_name_suggestions` (default false) to include
invites, which means that it fell back to a generic username like
`user1`.
This commit makes it bail out earlier in this situation, so that no
suggestion is attempted.
Translation overrides can be marked as "invalid interpolation keys" or "outdated" if the original translation is changed. We run a job every hour to check for this. We also have an admin problem check for it.
The problem is we don't refresh this status when an admin updates the override. So even if the invalid keys are removed, the override will still show up under the "invalid" filter.
There's a similar situation with the "outdated" status. The admin is shown a prompt which they can dismiss, which in turn updates the status, but updating the translation should also count as "addressing" it.
This PR runs a refresh on the override status when updating.
Followup 503f9b6f02ac5c4918d41611848c886b8755e5a0
This previous commit introduced an autogenerated
settings route for every plugin with more than one
setting defined. Plugins with only one setting
only have enabled_site_settings defined, which are
handled using the toggle in the admin plugin list,
so we don't need a dedicated setting page for them.
However in production this introduced a performance
issue, since we were looking through SiteSetting.all_settings
for every plugin, which could be quite slow in some
cases especially on our hosting.
Instead, we already have all the plugin settings cached
inside `SiteSetting.plugins`. We can instead use this to
count how many settings the plugin has, then if there is > 1
for a plugin we use the settings route. This is a much faster lookup
than
searching through SiteSetting.all_settings.
This commit makes the
[color-scheme-toggle](https://github.com/discourse/discourse-color-scheme-toggle)
theme component a core feature with improvements and bug fixes. The
theme component will be updated to become a no-op if the core feature is
enabled.
Noteworthy changes:
* the color mode selector has a new "Auto" option that makes the site
render in the same color mode as the user's system preference
* the splash screen respects the color mode selected by the user
* dark/light variants of category logos and background images are now
picked correctly based on the selected color mode
* a new `interface_color_selector` site setting to disable the selector
or choose its location between the sidebar footer or header
Internal topic: t/139465.
---------
Co-authored-by: Ella <ella.estigoy@gmail.com>
This commit fixes a bug in the "Dark Mode" checkbox in the interface user
preferences where the checkbox state doesn't appear in the disabled
state if the user disables dark mode.
This happens because when rendering the checkbox, we check the relevant
user options field within the controller's `init` method, but at that
point in the controller's life cycle, the `user_option` object isn't
available. What we should do instead is move this check to the route's
`setupController` method where the `user_option` object is available and
we can set the correct state on the controller.
https://meta.discourse.org/t/-/349976 (private topic)
While working with some themes, I noticed that all of these buttons
don't have the `topic-footer-button` class, so it can't really be used
effectively. The admin menu, bookmark button, and reply button were all
missing it. This adds the class.
This PR adds two attributes (`op_can_like` & `op_liked`) to
`TopicListItemSerializer`.
We've also added `serialize_topic_op_likes_data` theme modifier so that
these two attributes are only added when a theme or component needs this
data.
Likely we want the group smtp email job to retry. Also added a check to
see if we already have an email log entry for the message to avoid
possible duplicates on retry.
Related previous commit: ed47b550266e1ab669c756b0ecb48d1685b08fee
Until now, we were excluding uploads with a not null
access_control_post_id from cleanup, because we were still
considering them "secure" even though they might have been
`secure: false`.
It's not necessary to keep these around, these are no more
important than regular uploads if they are not referenced
by anything.
This setting was introduced a year ago for
51016e56dd99a9ad4bd82cdc6c0cf968754c70ed, which was
formerly a design experiment.
In practice on our hosting, noone has ever disabled this
setting, and it's for a useful feature. There is no
point keeping it.
Stopping propagation when a `DMenu`'s trigger is clicked could prevent
another floating UI element, e.g. the search menu in the header, from
closing when clicking outside of it. We call `stopPropagation` on the
event to allow more clicks within a `DMenu`'s trigger without it getting
closed, so we shouldn't stop the event propagation if the `DMenu` hasn't
been expanded yet.
This change includes the following updates:
- Rename view all to view all drafts
- Remove view all link from drop-down when all drafts are displayed in
the menu
- Different icon for draft topics and PMs (adds envelope for PMs)
- Disable drop-down when New Topic button is disabled (private
categories etc)
- Improve drafts drop-down loading (no longer disables the trigger btn
on click)
In the current admin index page, all plugins show up as tabs. This includes plugins with auto-generated config routes.
This changes the tabs to include only plugins with custom UIs.
Plugins like for example AI or Akismet create reviewable items. When the
plugin is disabled, then we cannot properly handle those items.
In that situation, we should display warnings about unhandled types.
Instruct admin to reenable plugins. In addition, we should allow the
admin to delete all pending reviews from disabled plugins.
