We were using `autoclose` as the topic status update
when silently closing topics using the bulk
actions (introduced in 0464ddcd9b).
However, this resulted in a message like this showing in
the topic as a small moderator post:
> This topic was automatically closed after X days.
This is not accurate, the topic was bulk closed by someone.
Instead, we can use `closed` as the status, and a more accurate
> Closed on DATE
message is used. `TopicStatusUpdater` needed an additional
option to keep the same "fake read" behaviour as autoclose
so we can keep the same functionality for silently closing
topics in bulk actions.
This commit extracts the content of the `HomeLogo` to a standalone
component. This enables us to utilize the `home-logo-contents` plugin
outlet to render an alternative version of the logo using the new
component to reuse the rendering logic, but using alternative
properties. For example:
```js
const logoSmallUrl = settings
.theme_uploads["theme-alternative-logo-small"];
const logoUrl = settings.theme_uploads["theme-alternative-logo"];
const mobileLogoUrl = settings
.theme_uploads["theme-alternative-logo"];
api.renderInOutlet("home-logo-contents", <template>
<HomeLogoContents
@logoSmallUrl={{logoSmallUrl}}
@logoUrl={{logoUrl}}
@minimized={{@outletArgs.minimized}}
@mobileLogoUrl={{mobileLogoUrl}}
@showMobileLogo={{@outletArgs.showMobileLogo}}
@title={{@outletArgs.title}}
/>
</template>);
``
decorator-transforms (https://github.com/ef4/decorator-transforms) is a modern replacement for babel's plugin-proposal-decorators. It provides a decorator implementation using modern browser features, without needing to enable babel's full suite of class feature transformations. This improves the developer experience and performance.
In local testing with Google's 'tachometer' tool, this reduces Discourse's 'init-to-render' time by around 3-4% (230ms -> 222ms).
It reduces our initial gzip'd JS payloads by 3.2% (2.43MB -> 2.35MB), or 7.5% (14.5MB -> 13.4MB) uncompressed.
This was previously reverted in 97847f6. This version includes a babel transformation which works around the bug in Safari <= 15.
For Cloudflare compatibility issues, check https://meta.discourse.org/t/311390
Inline the helper functions, avoid creating and then immediately destructuring arrays, use complete strings instead of string interpolation, Map instead of a pojo.
* FEATURE: Add Filter for Webhook Events by Status
* Fixing multiple issues
* Lint
* Fixing multiple issues
* Change the range of the status for webhook events
Really fully authored by Jarek, I only made the PR :)
The `DBreadcrumbItem` and `DBreadcrumbContainer` components
introduced in 1239178f49 have
some limitations, mainly that the container has no awareness of
its items, so nothing that requires positional knowledge can
be used. This is needed to use `aria-current` on the last breadcrumb
item, see https://www.w3.org/WAI/ARIA/apg/patterns/breadcrumb/examples/breadcrumb/.
We change `DBreadcrumbItem` to always be a link, removing
the need for `LinkTo`. Then, we introduce a service to keep
track of containers and items (since all items are rendered into
all containers) and make the item itself responsible for registering
to the service, and introduce the needed `aria-current` behaviour.
---------
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
We want to get rid of the old topic bulk actions modal
and use the new dropdown (currently gated behind
experimental_topic_bulk_actions_enabled_groups). To do
this we need to use the new dropdown in all places in the
UI.
This commit changes the full page search UI to use the new
topic bulk actions dropdown if experimental_topic_bulk_actions_enabled_groups
is enabled, and makes some minor refactors to make this work.
Also add a spec for both the old and new functionality.
# Description
Add `addCustomUserFieldValidationCallback` to the user fields validation mixin. This allows you to add a custom validation when checking the validity of custom user field values in the signup form on submit.
```js
addCustomUserFieldValidationCallback((userField) => {
if (userField.field.name === "my custom user field" && userField.value === "foo") {
return EmberObject.create({
failed: true,
reason: I18n.t("value_can_not_be_foo"),
element: userField.field.element,
});
}
});
```
In the case your custom validation deems an input value `failed`, you return an EmberObject with the fields `failed: true`, `reason`, and `element`.
```js
return EmberObject.create({
failed: true,
reason: I18n.t("value_can_not_be_foo"),
element: userField.field.element,
});
```
which will then display your custom `reason` to the user attached to the given user custom field input and will not submit the signup form.
<img width="288" alt="Screenshot 2024-06-06 at 11 08 40 AM" src="https://github.com/discourse/discourse/assets/50783505/11168fb8-8806-43f0-9417-73991bbd1178">
# Other
- Add `addCustomUserFieldValidationCallback` to the plugin api
- Bump plugin api version
- Update plugin api changelog
- Add tests
For cases where you'd be using a TrackedSet to render something and then modifying that set throughout the same render cycle. (specifically it will be used in #27365)
This commit introduces the initial UI for the admin config area for the /about page. The UI isn't wired and doesn't do anything yet, but we're going to iterate on it in future commits.
Internal topic: t/128544.
This commit fixes a problem where the user will not be able to reset
their password when they only have security keys and backup codes
configured.
This commit also makes the following changes/fixes:
1. Splits password reset system tests to
`spec/system/forgot_password_spec.rb` instead of missing the system
tests in `spec/system/login_spec.rb` which is mainly used to test
the login flow.
2. Fixes a UX issue where the `Use backup codes` or `Use authenticator
app` text is shown on the reset password form when the user does
not have either backup codes or an authenticator app configured.
Followup 0434112aa7,
when I introduced the pluralisation for the
password.too_short message I didn't change the
key name to `count`, which is necessary.
This commit includes various UX improvements to the reset
password page:
* Introduce a `hide-application-header-buttons` helper to do the following:
* Hide Sign Up and Log In buttons, they are not necessary on this flow
* Hide the sidebar, it is a distraction on this flow
* Improve messaging when a 2FA confirmation is required first
* Improve display of server-side ActiveRecord model validation errors
in password form, e.g. instead of "is the same as your current password"
we do "The password is the same as your current password"
* Move password tip to next line below input and move caps lock hint
inline with Show/Hide password toggle
* Add system specs for 2FA flow on reset password page
* Fixes a computed property conflict issue on the password reset
page when toggling 2FA methods
Continued work on moderate flags UI.
In this PR admins are allowed to change the order of flags. The notify user flag is always on top but all other flags can be moved.
This reverts commit 0b10e335ae.
I realised that some of these actions are overridden in themes/plugins, so this is going to cause problems (especially because modifyClass doesn't currently work well with the `@action` decorator)
This makes it more obvious what's happening, and makes it much less likely that users will send repeated reset emails (and thereby hit the rate limit)
Followup to e97ef7e9af
Even when the admin sidebar sections are collapsed, they should expand while filtering. When the filter is removed, sections should go back to the previous state.
In addition, trim whitespace from the filter section.
Only remaining ones are `routes/discourse.js` and `routes/application.js`. Those two both contain legacy `actions: {}` hashes which need to be updated before being converted to native class syntax.
This commit removes the `/admin-revamp` routes which were introduced as a part of an experiment to revamp the admin pages. We still want to improve the admin/staff experience, but we're going to do them within the existing `/admin` routes instead of introducing a completely new route.
Our initial efforts to improve the Discourse admin experience is this commit which introduces the foundation for a new subroute `/admin/config` which will house various new pages for configuring Discourse. The first new page (or "config area") will be `/admin/config/about` that will house all the settings and controls for configuring the `/about` page of Discourse.
Internal topic: t/128544
This commit re-introduces the "Move to Inbox" and "Move to Archive"
bulk topic actions, which we had in the old modal but had not yet added
to the new "experimental" dropdown, which isn't really experimental at
this point.
Once this is merged we can remove the old modal and only
rely on the new dropdown.
The issue was simple, we were just not returning the helper in the `user-private-messages` controller which was preventing any action to happen.
Follow up: we should write specs for this toggle.
Prior to this fix we were opening a modal before closing the `DMenu` modal, given `DModal` expects only one modal at a time it was closing the latest modal and instantly closing the one we just opened.
This adds a small indicator of the Ctrl+/ shortcut that
exists for the admin sidebar filter, since it's not very
obvious that you can do that. This should help people
who are struggling with the long list of links -- it's
much faster to use the keyboard and search for what
you are looking for.
Followup 73c6bb2593
The admin sidebar was also disappearing on another
child admin route (in this case the docker_manager
plugin update page). Instead of relying on the route
name which is flaky, we can set a boolean when the
sidebar is forced in the root admin route, then
turn it off when leaving admin.
When uploading a video, the composer will now show a thumbnail image in
the composer preview instead of just the video placeholder image.
If `enable_diffhtml_preview` is enabled the video will be rendered in
the composer preview and is playable.
Delay rendering sidebar sections after sidebar is shown
Showing the popup takes about 100ms, then rendering each section
could take up to and additional 200ms, which leaves the total just
outside of 300ms. If we cheat by rendering the popup first then
the sections in the next frame, it improves our paint time
Introduce DeferredRender to encapsulate 'paint later'
This uses a new nav style with the heirarchy:
```
Breadcrumbs
|- Title
|- Description
|- Third-Level Navigation
```
The navigation bar uses the transparent red-underlined
buttons similar to the user activity page.
Over time all admin pages will use this, but this starts
with the new plugin show page.
---------
Co-authored-by: Ella <ella.estigoy@gmail.com>
We need to register a waiter so that `settled()` will wait for `runAfterFramePaint()` callbacks to be run before proceeding.
Re-lands 63b7b598cb, but wrapped with `isTesting()` to avoid production errors.
# Context
We currently have a tracked value of `topic` in the header service that we utilize across the app for determining the presence of a topic.
A simple example is: If you are in a topic, and scroll down the page, we need to communicate to the header that a topic is present and we change the styling of the header.
The issue with this logic is that when entering a topic (and you are at the top of the page), we **haven't** set the topic on the header service yet. We only set the topic when you have scrolled down on the page (set by `app/components/discourse-topic.js`)
This is unhelpful behavior when you are utilizing a plugin outlet that is receiving the `topic` from the header:
17add599e3/app/assets/javascripts/discourse/app/components/header/topic/info.gjs (L85)
As the `topic` won't be present until you scroll down the page.
# Changes
This PR adds a tracked `inTopic` value to the header service that is a boolean value. This is to let the app know
> Yes, we are scrolled within a topic
And instead sets the tracked `topic` value immediately, if you are loading a topic, to allow the necessary data to be populated to the plugin outlets on page load.
Previously, avatars would be 'sticky' when:
1. The post was longer than the viewport
OR
2. You were scrolling up
The difference in behavior based on scroll direction doesn't 'feel' quite right. This commit makes the behavior consistent, so sticky avatar logic is applied to all posts regardless of scroll direction.
Prior to this fix we had too logic to detect if a user is active or not:
- idle codepath on the frontend
- online user ids on the backend
The frontend solution is not very reliable, and both solution are just trying to be too smart. Making a lot of people questioning why they receive a notification sometimes and sometimes not. This commit removes all this logic and replaces it with a much more simpler logic:
- you can't receive notifications for channel you are actually watching
- we won't play a sound more than once every 3seconds
When selected some text inside a post, we offer the ability to "fast edit" the selected text without opening the composer.
However, there are certain cases where this isn't working quite a expected, due to the fact that we have some text in the "cooked" version of the post that isn't literally in the "raw" version of the post.
This ensures that whenever someone selects the within
- a quote
- a onebox
- an encrypted message
- a "cooked" date
we directly show the composer instead of showing the fast edit modal and then leaving the user with an invisible error.
Internal ref. t/128400
* FIX: When creating new message via URL do not redirect
If a user clicks on `/new-message` route from inside the instance we're
redirecting the user to `/latest` page which is only intended if the
user is coming from an external site. This commit checks for this
condition and only redirects when user is coming from external source.
This also makes the behavior consistent with `new-topic` route.
Internal topic reference: `/t/-/129523/`
We consider that you should always receive a notification sound when someone speaks directly with you in chat.
This commit also refactors the way we play audio in chat to make it simpler and throttle it to 3 seconds.
We also added a safeguard to ensure we won't play sounds for old messages, this case can happen when message bus is catching up the backlog (eg: in an inactive tab for example).
* FEATURE: add agree and edit
adds agree and edit - an alias for agree and keep -- but with a client action to
edit the post in the composer before the flag is agreed with
---------
Co-authored-by: Juan David Martinez <juan@discourse.org>
We're planning to implement a feature that allows adding required fields for existing users. This PR does some preparatory refactoring to make that possible. There should be no changes to existing behaviour. Just a small update to the admin UI.
Before this fix when generating a pm path leading to a group messages inbox we would blindly take the first group of the pm, however, it's possible our current user doesn't have access to this group.
This commit will now try to find the first group the user has access to, and generate a path to this group’s inbox.
For plugins with only an "enabled" site setting, it doesn't
make sense to take them to the site settings page, since the
toggle switch in the list can be used to change enabled/disabled.
This will not be the case for plugins that have their own custom
config page (like Automation), but we will deal with this when
we actually overhaul this plugin to use the new show page.
Also adds another rspec fixture of a test plugin.
This PR aims to add bulk actions to the user's bookmarks.
After this feature, all users should be able to select multiple bookmarks and perform the actions of "deleting" or "clear reminders"
e.g. `unexpectedly found "! no whitespace ~" when slicing source, but expected " no whitespace "`
See: https://github.com/emberjs/ember.js/issues/19392
Co-authored-by: David Taylor <david@taylorhq.com>
- FIX: properly scope category changes to what the current user can see
- UX: previous category is now highlighted in "red", new category is highlighted in "green"
- PERF: no need to serialize the categories
- FIX: properly track wiki
- FIX: properly track post_type (aka. Staff Color)
- FIX: properly track making a topic a PM
- FIX: never show the category changes when a topic is made a PM
- PERF: post_revision serializer is now more leaner (never includes title changes when post_number > 1, never includes user changes if there aren't any)
- UX: always sort the tags by name
This commit reuses the existing codepath in desktop-notifications and make it available to use to chat.
primaryTab was too hard to test if not impossible in this service test, however isIdle and disabled notifications are correctly tested.
Followup 4e7a75a7ec
Several plugins (Gamification, AI) now use the new
plugin show route. Any plugins that are using it can
now redirect to this page via the Settings button in
the plugin list, rather than taking the user to the
old site settings page filtered by category.
…so it uses the more performant glimmer/template-only component wrapper instead of falling back to an ember component wrapper. see the `element` helper PR for more details.
(experimental)
The initial implementation of glimmer topic-list and related components. Does not include new APIs and isn't compatible with existing customization. That's gonna come in future PRs.
Enabled by adding groups to `experimental_glimmer_topic_list_groups` setting.
1. async/await
2. TrackedSet
3. don't rely on ember array methods
4. list used props
5. move stuff out of constructors
6. don't use ember's Input component
7. convert a function to a method (to avoid passing in a class prop)
8. add missing `@tracked`
9. remove tracking from props that don't need it (not used in templates)
Returns a wrapper component with the given tagname, or an empty wrapper for an empty string.
Similar to the reference implementation of RFC389, with higher-performance shortcuts for common elements.
Same as `@tracked`, but skips notifying consumers if the value is unchanged. This introduces some performance overhead, so should only be used where excessive downstream re-evaluations are a problem.
This is loosely based on `@dedupeTracked` in the `tracked-toolbox` package, but without the added complexity of a customizable 'comparator'. Implementing ourselves also avoids the need for pulling in the entire package, which contains some tools which we don't want, or which are now implemented in Ember/Glimmer (e.g. `@cached`).
This commit introduces the following components:
* DBreadcrumbsContainer - The wrapper template-only component,
which renders all DBreadcrumbsItem components on the page.
* DBreadcrumbsItem - The component that registers a LinkTo
for the breadcrumb trail. The breadcrumb > trail > will
show based on the order these items are rendered on the page.
* BreadcrumbsService - Manages the DBreadcrumbsContainer elements
on the page via DBreadcrumbsContainerModifier.
* DBreadcrumbsContainerModifier - Handles registering DBreadcrumbsContainer
elements with the BreadcrumbsService and deregistering them.
For now, we will only use these breadcrumbs in the admin section
of Discourse, and this initial commit only uses them in admin/plugins.
This is heavily based off of
https://github.com/Bagaar/ember-breadcrumbs,
but will be further modified for our needs.
- removes `will-change: auto;` which is a performance hack which should be avoided and is probably causing more harm than good here
- lowers swipe velocity to 0.4 to ensure the modal can be dismissed with the thumb
- uses JS CSS animate API to animate the backdrop opacity
- uses the height of the modal container to have more precise values when computing backdrop opacity
- animate the modal container instead of the wrapper
- removes a useless template-lint-disable directive
- simplify the closing animation
- various small code tweaks to limit indirection
Navigation to subcategories page was possible through the category drop
and the "view all" link or through the category drop from the categories
page. This commit removes the latter method.
Follow up to commit 77b032c2b5.
Using the CategoryDrop on the categories page redirected the user to the
"latest topics" page with topics only from that category. With these
changes, selecting a category will take the user to a "subcategories
page" where only the subcategories of the selected property will be
displayed.
Categories are loaded in the composer via the category chooser, but
that only loads a subset of the fields. With these changes, the category
will be loaded async to make sure that the template is updated.
This commit adds a different message to the users directory (`/u`) that's shown when there are no results for the search term instead of showing the one for when there are no users on the site yet.
Internal topic: t/126076.
Sorting a topics list in user activities wasn't working because the query parameters weren't passed to `findFiltered()` that does the request to the server.
Made the `sortIcon` more resilient to "input" by always converting the value to a string and checking against `"true"`.
Moved `cleanNullQueryParams()` inside `findFiltered` so we're always removing `null` query parameters.
Internal ref - t/127068
Some of the old (pre-dag) header logic was accidently re-introduced as part of 9bcbfbba43 (presumably by mistake while resolving a merge conflict). This causes sites on the old header implementation to end up with duplicate user menu icons.
Prior to this fix all menus with empty identifier or groupIdentifier would be considered to be part of the same identifiers/groupIdentifiers and would auto close any existing d-menu with no identifier/groupIdentifier when opened.
This commit changes request method for "categories/search" from GET to
POST to make sure that long filters can be passed to the server. For
example, category selectors with many categories are setting the full
list of selected category IDs to ensure these are filtered out from the
list of choices. This can result in a long URL that exceeds the maximum
length.
Some sites are still on the legacy "hamburger dropdown"
navigation_menu setting. In this case to avoid confusion,
we want to show both the sidebar icon and the header dropdown
hamburger when visiting the admin portal. Otherwise, the
hamburger switches sides from right to left for admins
and takes on different behaviour.
The hamburger in this case _only_ shows the main panel, not
other sidebar panels like the admin one.
Recently a bug was introduced when the admin sidebar section was made bold.
When the admin sidebar is disabled, we display the original sidebar in the admin panel. In that case, an incorrect CSS rule is executed.
```CSS
.admin-area .sidebar-wrapper {
background-color: var(--d-sidebar-admin-background);
.sidebar-section-header-text {
font-weight: bold;
}
}
```
Bug in this PR: https://github.com/discourse/discourse/pull/26801
To solve it, a custom CSS class with a panel key was added which will allow granular customisations.
It used to embed the objects which could lead to duplicated objects
when the same user or category was used multiple times (user was admin,
moderator and category or category was parent for multiple categories).
This reverts commit 0f4520867b.
This has led to two problems:
1. An incompatibility with Cloudflare's "auto minify" feature. They've deprecated this feature because of incompatibility with modern JS syntax. But unfortunately it will remain enabled on existing properties until 2024-08-05.
2. Discourse fails to boot in Safari 15. This is strange, because Safari does support all the required features in our production JS bundles. Even more strangely, things start working as soon as you open the developer tools. That suggests the cause could be a Safari bug rather than a simple incompatibility.
Reverting while we work out a path forward on both those issues.
- adds a `@groupIdentifier` property which will ensure that two menus of the same group are not expanded at the same time
- adds a `@class` property which will be applied to the trigger and the content
- adds a `@triggerClass` property which will be applied to the trigger
- adds a `@contentClass` property which will be applied to the trigger
- removes `extraClassName`
It's a temporary solution while I work a better solution. The problem here is quite tricky. We are showing a modal from a modal. But if we close the previous modal, before the second one is show it means we destroy the menu holding the first modal which prevents showing the second modal.
One possible solution would be to refactor d-modal’s show function. At the moment if you await on show it will await until closed and not when the modal has been inserted to the DOM. It means we don't have a clean moment to close the d-menu.
The second issue it that even though it's possible to have multiple modals on screen, the close modal assumes only one active modal at a time.
Cases like the glimmer-site-header are complex because the swiped area is not the moved target, for now it's simpler to not apply the body scroll lock automatically.
A new property is now available on the swipe modifier: `{{swipe @lockBody=false}}`
Note I tried to have tests for this modifier in the past, but it was very inconsistent on CI causing lots of flakeys, this is why there are no tests for now. I might try to write them again using system specs.
Previously, we only updated the duration and interval values in the constructor. So whenever the initial values are updated in the form the changes are not reflected in the UI. To fix this issue we're using "get" methods in this PR.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
Fixes a bug I stumbled upon in dev env:
```
Error: Assertion Failed: You attempted to update <discourse@model:user::ember337>.status to "[object Object]", but it is being tracked by a tracking context, such as a template, computed property, or observer. In order to make sure the context updates properly, you must invalidate the property when updating it. You can mark the property as `@tracked`, or use `@ember/object#set` to do this.
```
decorator-transforms (https://github.com/ef4/decorator-transforms) is a modern replacement for babel's plugin-proposal-decorators. It provides a decorator implementation using modern browser features, without needing to enable babel's full suite of class feature transformations. This improves the developer experience and performance.
In local testing with Google's 'tachometer' tool, this reduces Discourse's 'init-to-render' time by around 3-4% (230ms -> 222ms).
It reduces our initial gzip'd JS payloads by 3.2% (2.43MB -> 2.35MB), or 7.5% (14.5MB -> 13.4MB) uncompressed.
DropdownMenu component is meant as a way to describe the content of menus.
Syntax:
```
<DropdownMenu as |dm|>
<dm.item class="test">
First
</dm.item>
<dm.divider class="foo" />
<dm.item class="bar">
Second
</dm.item>
</DropdownMenu>
```
menus and tooltips are now appended to their own portals. The service are the only responsible for managing the instances, prior to this commit, services could manage one instance, but the DMenu and DTooltip components could also take over which could cause unexpected states.
This change also allows nested menus/tooltips.
Other notable changes:
- few months ago core copied the CloseOnClickOutside modifier of float-kit without removing the float-kit one, this commit now only use the core one.
- the close function is now trully async
- the close function accepts an instance or an identifier as parameter
This commit also:
uses the swipe modifier in the glimmer-site-header component
changes closing condition for d-modal and toast from distance to velocity
cancels toast auto close on touch
