Currently when using the shortcuts to delete a post the UI would show
you the confirmation modal even if you don't have the right to do it.
This commit fixes the issue at the root in the
`deletePostWithConfirmation` function.
This was intended to provide a better UX for interactive elements in the
composer preview. However, the morphing strategy has irreconcilable
conflicts with our `decorateCooked` API, and so we have been unable to
enable this by default.
Going forward, we're focussing efforts on the WYSIWYG composer to
provide this kind of smooth UX, so we're dropping the
`enable_diffhtml_preview` approach.
Adds https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/enterkeyhint
to the search inputs.
This hint is used for mobile devices to guide what label
is shown on the onscreen keyboard. By default `return` is
shown, now for search we will see `search`.
Also add `type="search"` to the full page search input for
further guidance.
This feature was originally experimental. We made it baseline in #29572, however this was met with some pushback, so we have decided to make it experimental again.
The original PR couldn't be reverted, but this one basically does the same by cherry-picking all the changes back.
This PR does some things to the about page:
- Hide the stat if there are 0 admins/moderators.
- Count admins and moderators separately, so a user who is both will add
to both counts.
- A user who is both will still show up as a moderator, even if `admins`
is hidden.
Follow-up to https://github.com/discourse/discourse/pull/31271
In the linked PR, we made `<GroupChooser />` use the site's preloaded
list of groups instead of fetching the list from the servers every time
the component is triggered. However, when a site has thousands of
groups, the performance issue has shifted from the server to the browser
— `<GroupChooser />` takes several seconds to render in the browser for
a site with thousands of groups and the sites becomes completely
unresponsive while the component is rendering.
This PR changes the `<GroupChooser />` so it limits the displayed groups
to 100, with ability to filter the list to show more groups when there
are more than 100 groups.
This uses the new `triggerComponent` functionality to implement a button
without the default `DButton` component classes, which helps themes
avoid applying unintentional styling.
A regression introduced in 32c8aa0aad
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 91e9c1c813.
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 f1bdd86a8c
- 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.
6fd577d97d 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 503f9b6f02
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.
