- Do a simple check to see whether JS deps are out-of-date before
running `pnpm install`. This saves about 1 second on my machine
- Remove `playwright install` from the critical path. Instead, add a
`pnpm playwright-install` shortcut, and improve the error which system
specs throw when playwright is out of date. This saves about 0.7s on my
machine.
This solution was working correctly but it had a bug with our hashtag
autocompletion, this is the same solution than before but packaged in a
modifier. It seems to work ok in the latest iOS beta.
Migrates category listing and related UI to tracked built-ins with an
array-like proxy for improved reactivity and modernization.
- Introduce LegacyArrayLikeObject: a Proxy over TrackedArray preserving
array semantics while allowing instance properties/methods
- Rewrite CategoryList to use an array-like object; add tracked state
(page, isLoading, fetchedLastPage, parentCategory), async list(), and
safer loadMore with error handling; deprecate legacy categories/content
usage
- Update routes/templates to pass CategoryList directly (not
.categories), switch to async/await, preserve PreloadStore behavior, and
sync TopicTrackingState with the new model
- Refactor category components (boxes, boxes-with-topics, only) to ES
getters and native array APIs; remove discourseComputed and Ember
helpers like firstObject/filterBy
- Add tests for array-like object behavior (array methods, inheritance,
plugin API modifyClass), CategoryList fetching/parent filtering/stat
rendering/pagination, and UI reactivity
- Remove ArrayProxy and other deprecated patterns
`getBoundingClientRect()` calls `#getTriggerClientRect()`
`#getTriggerClientRect()` calls `this.#view.coordsAtPos(head)`
`coordsAtPos()` internally calls `getBoundingClientRect()` on the
trigger element
Which may creates an infinite loop / `Maximum call stack size exceeded`.
This PR adds a `this.#calculatingCoords` guard to make sure we don't
call `#getTriggerClientRect` again during the `coordsAtPos` call.
To reproduce the issue, you can follow the same steps as the added test
case:
- type a `[link](link)`
- cmd/ctrl-a to select all
- type anything to replace it
You should see a `Maximum call stack size exceeded` console output.
## Overview
This PR introduces comprehensive search functionality for chat messages,
enabling users to search through their chat history both globally across
all accessible channels and within specific channels.
### Search Capabilities
**All-Channel Search**: When no channel is specified, users can search
across all channels they have access to. The search respects channel
permissions through `ChannelFetcher.all_secured_channel_ids`, ensuring
users only see results from channels they can view.
**Per-Channel Search**: Users can scope their search to a specific
channel by providing a `channel_id` parameter, useful for finding
messages within a particular conversation context.
**Search Features**:
- Full-text search using PostgreSQL's tsvector/tsquery
- Advanced filters: `@username` to filter by author, `#channel` to
filter by channel slug
- Sort options: relevance (default) or latest
- Pagination support
- Search data weighted by relevance
## Site Setting: `chat_search_enabled`
This feature is gated behind the `chat_search_enabled` site setting,
which is currently:
- **Default**: `false`
- **Hidden**: `true`
- **Client-accessible**: `true`
### Deployment Strategy
Due to the need for chat messages to be indexed before search becomes
useful, we're implementing a two-phase deployment:
**Phase 1 (Initial Merge)**:
- `chat_search_enabled` remains `false` and hidden
- The `register_search_index` uses default (true) instead of `chat_search_enabled` value
- This allows the reindexing infrastructure to begin indexing existing
chat messages even if we don't show the UI yet
**Wait Period**:
- Wait at least one week after Phase 1 deployment
- `Jobs::ReindexSearch` runs every 2 hours and will progressively index
all chat messages
- This ensures most sites have a significant part of their chat history indexed
**Phase 2 (Follow-up Merge)**:
- Set `chat_search_enabled` default to `true` and unhide it
- Update the `register_search_index` enabled proc uses the default
(true) instead of using the `chat_search_enabled` setting
- Users can now access search with pre-indexed data
**Rationale**: Without this phased approach, users would see the search
UI immediately but receive no results until the reindexing job runs,
creating a confusing experience. By pre-indexing while the UI is hidden,
we ensure search works immediately when enabled.
## New Plugin API: `register_search_index`
This PR introduces a new plugin API that allows plugins to register
custom search indexes that integrate seamlessly with Discourse's search
infrastructure.
### API Signature
```ruby
register_search_index(
model_class:, # The ActiveRecord model to index
search_data_class:, # The model for storing search data
index_version:, # Version number for re-indexing
search_data:, # Proc that returns weighted search data
load_unindexed_record_ids:,# Proc that finds records needing indexing
enabled: # Optional proc to enable/disable (default: -> { true })
)
```
### How It Works
**Integration with SearchIndexer**: When `SearchIndexer.index(obj)` is
called, it checks registered search handlers for the object's type. If a
handler matches, it:
1. Calls the `search_data` proc with the object and an `IndexerHelper`
instance
2. Receives weighted search data (`:a_weight`, `:b_weight`, `:c_weight`,
`:d_weight`)
3. Updates the corresponding search data table with PostgreSQL's
tsvector
**Integration with Jobs::ReindexSearch**: The scheduled job (runs every
2 hours) calls `rebuild_registered_search_handlers`, which:
1. Iterates through all registered search handlers
2. Skips handlers where `enabled` proc returns `false`
3. Calls `load_unindexed_record_ids` to find records needing indexing
4. Indexes up to `limit` records per handler (default: 10,000)
### Chat Implementation Example
```ruby
register_search_index(
model_class: Chat::Message,
search_data_class: Chat::MessageSearchData,
index_version: 1,
search_data: proc { |message, indexer_helper|
{
a_weight: message.message,
d_weight: indexer_helper.scrub_html(message.cooked)[0..600_000]
}
},
load_unindexed_record_ids: proc { |limit:, index_version:|
Chat::Message
.joins("LEFT JOIN chat_message_search_data ON chat_message_id = chat_messages.id")
.where(
"chat_message_search_data.locale IS NULL OR
chat_message_search_data.locale != ? OR
chat_message_search_data.version != ?",
SiteSetting.default_locale,
index_version
)
.order("chat_messages.id ASC")
.limit(limit)
.pluck(:id)
}
)
```
Co-authored-by: Martin Brennan <mjrbrennan@gmail.com>
Co-authored-by: Loïc Guitaut <5648+Flink@users.noreply.github.com>
This version corrects a bug where fluentui emojis didn't have a
transparent background. To ensure the cache is cleared and we don't
serve incorrect emojis anymore we had to bump the emoji version.
Previously, when staged users were disabled and a category allowed
strangers via `email_in_allow_strangers`, incoming emails would
automatically fallback to using the system user to create topics.
Change introduced in this PR
https://github.com/discourse/discourse/pull/34655
This change adds a new hidden site setting
`email_in_allow_system_user_fallback` (default: false) that controls
this behavior. When disabled, emails from strangers will raise a
UserNotFoundError instead of creating topics as system user.
The previous message states that the topic will be closed momentarily
but this is not true as the topic is closed immediately.
This commit also removes the `topic.auto_close_momentarily` i18n key
since it isn't being used anywhere else.
Some styling changes have also been made to make the warning message
clearer.
Steps to reproduce:
* Start drafting a reply to a topic
* Write some text.
* Navigate to a different topic while keeping the draft open
* Click reply on the composer and choose cancel in the modal asking
which topic you want to reply to.
* Write some more text.
* Copy the text you have written or memorize your input.
* Reload the page/ close the composer.
* Navigate back to the topic you replied to
* Open your draft.
* Everything written after clicking cancel is missing.
This was happening because we weren't doing anything on Cancel for
the topic reply choice dialog, and we were doing `disableDrafts` before
opening the dialog, so drafts never resumed.
The fix is to just save the current draft on cancel then turn on
draft saving again so the user can continue typing and delay the
question about "Which topic do you want to reply to?" until later.
c.f.
https://meta.discourse.org/t/draft-is-no-longer-automatically-saved-after-you-cancel-replying/386370
Also rename TopicLabelContent to TopicReplyChoiceDialog, it
is more specific and reflects what the component actually does.
When multiple flaky tests are encountered, we sometimes exceed the 20
minutes timeout. Since we are on self hosted runners now where costs are
much lower, it is OK for us to have longer timeouts.
When the user is editing a draft in multiple windows, they get a dialog
asking if they want to reload or ignore. The ignore button didn't have
the correct border radius, due to it missing `btn-default` (double `btn`
classes instead). This PR adds `btn-default` for that button.
```html
<div class="dialog-footer">
<button class="btn btn-primary" type="button">
<span class="d-button-label">Reload</span>
</button>
↓
<button class="btn btn" type="button">
<span class="d-button-label">Ignore</span>
</button>
</div>
```
<img width="1502" height="970" alt="image"
src="https://github.com/user-attachments/assets/bcc7ac5f-70d0-4c87-abee-dee6090ea1ec"
/>
In `Chat::ChannelFetcher.secured_direct_message_channels_search`,
`User.preload_custom_fields` is called with `channels.flat_map {
_1.chatable.users }`. However,
the `Chat::DirectMessageSerializer` was getting the users via
`object.direct_message_users.map(&:user)` which uses the
`Chat::DirectMessage.direct_message_users` scope instead of the
`Chat::DirectMessage.users` scope resulting in ActiveRecord returning
new `User` objects that do not have user custom fields preloaded.
This fixes the appearance of AI generated gists in the topic list on
/filter, and also includes the gist toggle via a new plugin outlet on
/filter called `after-filter-navigation-menu`.
This shares the state with the discovery route toggle (which is separate
from PM toggle state). I've also added tests to cover gist appearance on
/filter. Before the /filter state was shared with PM state, which was
incorrect.
Before:
<img width="2232" height="424" alt="image"
src="https://github.com/user-attachments/assets/b22ed7a6-388e-4b88-99d4-e9e10af6275a"
/>
After:
<img width="2272" height="506" alt="image"
src="https://github.com/user-attachments/assets/cae03f12-9153-4bcb-a9d3-52712fb2d945"
/>
Having it in d-ai's plugin.rb file solves it when running plugin tests.
But when running core tests, plugins are not loaded, but the tables
still exist in the database.
Followup to 6247fdc255
Updates `prosemirror-model` to use this fix: [When preserving
whitespace, replace newlines with line break replacements
](https://github.com/ProseMirror/prosemirror-model/commit/79e9f2b9497ec3aac70d180aa846267dafa48d9a)
Adds `linebreakReplacement: true` to our hard break node spec
definition.
Adds a system test to confirm a `white-space: pre` HTML pasted from the
clipboard parses new lines as hard breaks.
**Description**
Replaces separate @strip_images and @markdown_images boolean flags with
a single @image_mode variable that can be :strip, :markdown, or nil.
Keeping the interface but ensuring only one
When adding a note through the timeline tab, the note wasn't being
persisted to the reviewable's reviewable_notes array. This caused the
note to disappear when switching between tabs.
This is a follow up to cf4193e6e1.
When chat is being initialized, we initiate an async request to
`/chat/api/me/channels` via `this.chat.loadChannels` but do not await on the request to be completed.
This is fine when a user is not visiting a chat channel route directly.
However, not awaiting on `this.chat.loadChannels` can cause problems
like a user's thread list or drafts to not be displayed if the
`/chat/api/me/channels` request does not return before rendering
happens. To resolve this, we will now wait for the promise in
`this.chat.loadChannels` to resolve before allowing rendering to happen on the `ChatChannelRoute`.
When a `PUT`, `POST`, or `DELETE` operation doesn't need to return any
data, we've historically either returned nothing, or `{ success: "OK"
}`.
A more consistent way to return the same data would be with a 204 status
response. This gives the same information as the `{ success: "OK" }`
body (ie, that the operation successfully completed), without needing to
read or parse the response body.
This change adds a 204 response for `Admin::SiteSettingsController`.
Additional controllers could be migrated in follow-up PRs, or on an
ad-hoc basis.
This change adds a new `ReviewableActionBuilder#build_bundle` helper for
quickly defining action bundles that can be performed on reviewables.
`ReviewableActionBuilder#build_action` has also been updated to allow
plugin-defined actions to appear correctly.
The core reviewable types have been updated to use this new method, and
I've also added support for reviewable chat messages, to demonstrate
plugin support.
Co-authored-by: Krzysztof Kotlarek <kotlarek.krzysztof@gmail.com>
Since the new modifier has been added, some specs were not using using
the focus check on the composer (included in `fill_composer` method) and
we were actually not focused which was causing these specs to fail.
The `{{prevent-scroll-on-focus}}` modifier is a workaround for a bug in
iOS where safari won't follow `preventScroll: true` and will actually
scroll. I thought that not having the timeout would be good enough, but
we actually need this delay to ensure we are past the moment where
safari will start respecting `preventScroll: true`.
The `RSVP.Promise` polyfill has some subtle differences to native
promises. In this case, we ran into a problem where calling `reject()`
inside JQuery's `error` handler would throw an exception, and then stop
JQuery's own error cleanup from running. That caused subtle problems,
like the global `ajaxError` event failing to fire.
Switching from `RSVP.Promise` to `Promise` normally introducing subtle
timing changes. However, I think in this case we are insulated from that
because we're already calling resolve/reject via `@ember/runloop`'s
`run()` function. 🤞
David Taylor
Gabriel Grubba
Joffrey JAFFEUX
Sérgio Saquetim
Renato Atilio
Jarek Radosz
Krzysztof Kotlarek
Alan Guo Xiang Tan
Martin Brennan
Bryce Huhtala
chapoi
Kris
Blake Erickson
Juan David Martínez Cubillos
Tomas Vavrda
Justin Moore
Gary Pendergast