Commit Graph

59 Commits

Author SHA1 Message Date
Joffrey JAFFEUX d75d64bf16
FEATURE: new jump to channel menu (#22383)
This commit replaces two existing screens:
- draft
- channel selection modal

Main features compared to existing solutions
- features are now combined, meaning you can for example create multi users DM
- it will show users with chat disabled
- it shows unread state
- hopefully a better look/feel
- lots of small details and fixes...

Other noticeable fixes
- starting a DM with a user, even from the user card and clicking <kbd>Chat</kbd> will not show a green dot for the target user (or even the channel) until a message is actually sent
- it should almost never do a full page reload anymore

---------

Co-authored-by: Martin Brennan <mjrbrennan@gmail.com>
Co-authored-by: Jordan Vidrine <30537603+jordanvidrine@users.noreply.github.com>
Co-authored-by: chapoi <101828855+chapoi@users.noreply.github.com>
Co-authored-by: Mark VanLandingham <markvanlan@gmail.com>
2023-07-05 18:18:27 +02:00
Martin Brennan 3f1024de76
DEV: Refactor DM channel creation into new service pattern (#22144)
This will be used when we move the channel creation for DMs
to happen when we first send a message in a DM channel to avoid
a double-request. For now we can just have a new API endpoint
for creating this that the existing frontend code can use,
that uses the new service pattern.

This also uses the new policy pattern for services where the policy
can be defined in a class so a more dynamic reason for the policy
failing can be sent to the controller.

Co-authored-by: Loïc Guitaut <loic@discourse.org>
2023-07-03 10:18:37 +10:00
Loïc Guitaut 885ab9a015
DEV: Introduce an `array` type for Chat contracts (#22278)
This small patch registers a new `ActiveModel` type: `array`.
It will split a string on `,` to create a new array. If the value is
already an array, nothing will happen and for all other types, it will
wrap the value in an array.

Here’s an example on an existing contract:
```ruby
  attribute :target_usernames

  before_validation do
    self.target_usernames =
      (
        if target_usernames.is_a?(String)
          target_usernames.split(",")
        else
          target_usernames
        end
      )
  end

  # can be rewritten as:

  attribute :target_usernames, :array
```
2023-06-27 10:51:58 +10:00
Loïc Guitaut 0f4beab0fb DEV: Update the rubocop-discourse gem
This enables cops related to RSpec `subject`.

See https://github.com/discourse/rubocop-discourse/pull/32
2023-06-26 11:41:52 +02:00
Andrei Prigorshnev 3ea31f443c
FEATURE: Export chat messages to CSV file (#22113)
To export chat messages, go to `/admin/plugins/chat` and click the Create export 
button in the _Export chat messages_ section. You'll receive a direct message 
when the export is finished.

Currently, this exports all messages from the last 6 months, but not more than 
10000 messages.

This exports all chat messages, including messages from private channels and 
users' direct conversations. This also exports messages that were deleted.
2023-06-21 16:13:36 +04:00
Martin Brennan fc199d42fa
FIX: Add aria-label attribute to cooked hashtags (#22182)
This commit adds an aria-label attribute to cooked hashtags using
the post/chat message decorateCooked functionality. I have just used
the inner content of the hashtag (the tag/category/channel name) for
the label -- we can reexamine at some point if we want something
different like "Link to dev category" or something, but from what I
can tell things like Twitter don't even have aria-labels for hashtags
so the text would be read out directly.

This commit also refactors any ruby specs checking the HTML of hashtags
to use rspec-html-matchers which is far clearer than having to maintain
the HTML structure in a HEREDOC for comparison, and gives better spec
failures.

c.f. https://meta.discourse.org/t/hashtags-are-getting-a-makeover/248866/23?u=martin
2023-06-20 15:47:17 +10:00
Joffrey JAFFEUX 9ba333808f
FIX: prevents admins to be silenced (#21854)
Currently in chat it was possible to have TL4 users to flag admins and silence them, this change should ensure it's never possible.
2023-06-01 08:36:11 +02:00
Loïc Guitaut 0733dda1cb DEV: Add policy objects to services
This patch introduces policy objects to chat services. It allows putting
more complex logic in a dedicated class, which will make services
thinner. It also allows providing a reason why the policy failed.

Some change has been made to the service runner too to use more easily
these new policy objects: when matching a failing policy (or any failing
step actually), the result object is now provided to the block. This
way, instead of having to access the reason why the policy failed by
doing `result["result.policy.policy_name"].reason` inside the block,
this one can be simply written like this:
```ruby
  on_failed_policy(:policy_name) { |policy| policy.reason }
```
2023-05-25 12:34:00 +02:00
Martin Brennan 0b3cf83e3c
FIX: Do not cook icon with hashtags (#21676)
This commit makes some fundamental changes to how hashtag cooking and
icon generation works in the new experimental hashtag autocomplete mode.
Previously we cooked the appropriate SVG icon with the cooked hashtag,
though this has proved inflexible especially for theming purposes.

Instead, we now cook a data-ID attribute with the hashtag and add a new
span as an icon placeholder. This is replaced on the client side with an
icon (or a square span in the case of categories) on the client side via
the decorateCooked API for posts and chat messages.

This client side logic uses the generated hashtag, category, and channel
CSS classes added in a previous commit.

This is missing changes to the sidebar to use the new generated CSS
classes and also colors and the split square for categories in the
hashtag autocomplete menu -- I will tackle this in a separate PR so it
is clearer.
2023-05-23 09:33:55 +02:00
Martin Brennan 9953a6edd9
DEV: Rearchitect chat tracking state (#21550)
This moves chat tracking state calculation for channels
and threads into a central Chat::TrackingStateManager service, that
serves a similar purpose to the TopicTrackingState model
in core.

This service calls down to these query classes:

* ThreadUnreadsQuery
* ChannelUnreadsQuery

To get the unread_count and mention_count for the appropriate
channels and threads.

As well as this, this commit refactors the client-side chat
tracking state.

Now, there is a central ChatTrackingStateManager Ember Service
so all tracking is accessible and can be counted from one place,
which can also initialize tracking from an initial payload.

The actual tracking counts are now maintained in a ChatTrackingState
class that is initialized on the `.tracking` property of both channel and
thread objects.

This removes the attributes on UserChatChannelMembership and decoration
of said membership from ChannelFetcher, preferring instead to have an additional
object for tracking in the JSON.
2023-05-16 14:51:13 +02:00
Andrei Prigorshnev b85d057df4
FIX: ensures `all_mentioned_user_ids` is not used as identifier (#21491)
A follow-up to 54b2a85b. That commit didn't fix the issue because the to_notify hash that we return from the notify_edit method isn't used anywhere apart from tests (that's confusing, we're going to fix that soon).
2023-05-12 17:47:48 +04:00
Andrei Prigorshnev 2703f2311a
DEV: Create a chat_mention record when self mentioning (#21438)
In the past, we create a `chat_mention` records only when we wanted to notify a user about a mention. Since we don't send notifications when a user mentioning himself, we didn't create a `chat_mention` records in those cases.

Now we use `chat_mentions` records in other scenarios too, so when a user is mentioning himself we want to:
1. Create a `chat_mention` record for that mention
2. Do not create a notification for that mention
2023-05-11 19:30:26 +04:00
Joffrey JAFFEUX 54b2a85b27
FIX: ensures `all_mentioned_user_ids` is not used as identifier (#21452)
When making the list of users to notify we set `all_mentioned_user_ids` key on the `to_notify` Hash.

This hash will be passed around until the actual moment where we send the notifications:

```ruby
identifier_text =
  case identifier_type
  when :here_mentions
    "@here"
  when :global_mentions
    "@all"
  when :direct_mentions
    ""
  else
    "@#{identifier_type}"
  end
```

As not found `all_mentioned_user_ids` would end up being sent as `@all_mentioned_user_ids` which is obviously incorrect.

This commit is a direct fix to the issue and will remove the key as soon as we have used it sooner up in the chain.

This bug was reproducible when doing this sequence of events:

- create a message with a direct mention: `@bob hi`
- edit this message into a global mention `@all hi`
2023-05-09 13:00:19 +02:00
Andrei Prigorshnev 35a414bb38
DEV: Create and update chat message mentions earlier (#21388)
We need to create and update `chat_mentions` records for messages earlier. They should be created or updated before we  call `Chat::Publisher.publish_new!` `Chat::Publisher.publish_edit!` to send the message to message bus subscribers).

This logic is covered with tests in `message_creator_spec.rb`, `message_updater_spec.rb`, `notifier_spec.rb` and `notify_mentioned_spec.rb`.

See the commits history for steps of refactoring.
2023-05-05 15:47:07 +04:00
Martin Brennan 24ec06ff85
FEATURE: Reintroduce better thread reply counter cache (#21197)
This was reverted in 38cebd3ed5.
The issue was that I was using Discourse.redis.delete_prefixed
which does a slow redis KEYS lookup, which is not advised in
production. This commit removes that, and also ensures the periodical
thread count update only happens if threading is enabled.

I changed to use a redis INCR/DECR for reply count
cache. This avoids a round trip to redis to GET the current
count, and also avoids multi-process issues, where
if there's two processes trying to increment at the
same time, they may both receive the same value, add one
to it, then both write the same value back.
Then, it's only n+1 instead of n+2.

This also prevents almost all chat scheduled jobs from
running if chat is disabled, the only one remaining is
the message retention job.
2023-04-24 09:32:04 +10:00
Martin Brennan 21f93731a3
DEV: Move channel creation for category into service (#21167)
This commit moves the category channel creation out
of the Chat::Api::Channel controller and into a
dedicated CreateCategoryChannel service. A follow up
commit will move the DM channel creation out of
the old DirectMessageChannelCreator service.

Also includes a new on_model_errors helper
for chat service class usage, that collects model
validation errors to present in a nice way.

---------

Co-authored-by: Loïc Guitaut <loic@discourse.org>
2023-04-24 09:15:16 +10:00
Daniel Waterworth 38cebd3ed5
Revert "FEATURE: Better thread reply counter cache (#21108)" (#21192)
This reverts commit 180e3e11d1.

Per internal discussions, this is a temporary revert, to investigate if this is causing a performance regression.
2023-04-20 15:09:47 -05:00
Martin Brennan a8cf8e57b4
FIX: Do not count thread messages for channel unreads (#21126)
We currently don't have a nice UI to show unread messages for the thread,
and it will take some time to create one. For now, this commit makes it so
new messages inside a thread do not count towards a chat channel's unread
counts, and new messages sent in a thread do not update a user's `last_read_message_id`
for a channel.

In addition, this PR refactors the `Chat::ChannelFetcher` to use the `Chat::ChannelUnreadsQuery`
query class for consistency, and made said class able to return zeroed-out records
for channels the user is not a member of.

Finally, a small bug is fixed here where if a user's `last_read_message_id` for
a channel was a thread's OM ID, then the thread OM would not show in the
main channel stream for them until another reply to the channel was posted.
2023-04-19 08:53:51 +10:00
Martin Brennan 180e3e11d1
FEATURE: Better thread reply counter cache (#21108)
This commit introduces a redis cache over the top of the thread
replies_count DB cache, so that we can quickly and accurately
increment/decrement the reply count for all users and not have
to constantly update the database-level count. This is done so
the UI can have a count that is displayed to the users on each
thread indicator, that appears to live update on each chat
message create/trash/recover inside the thread.

This commit also introduces the `Chat::RestoreMessage` service
and moves the restore endpoint into the `Api::ChannelMessages`
controller as part of incremental migrations to move things out
of ChatController.

Finally, this commit refactors `Chat::Publisher` to be less repetitive
with its `MessageBus` sending code.
2023-04-18 14:01:01 +10:00
Martin Brennan 1e85de36e2
FEATURE: Hook up chat bulk delete for threads (#21109)
Followup to bd5c5c4b5f,
this commit hooks up the bulk delete events for chat
messages inside the thread panel, by fanning out the
deleted message IDs based on whether they belong to
a thread or not.

Also adds a system spec to cover this case, as previously
the bulk delete event would have been broken with an incorrect
`typ` rather than `type` hash key.
2023-04-18 08:28:20 +10:00
Joffrey JAFFEUX 12a18d4d55
DEV: properly namespace chat (#20690)
This commit main goal was to comply with Zeitwerk and properly rely on autoloading. To achieve this, most resources have been namespaced under the `Chat` module.

- Given all models are now namespaced with `Chat::` and would change the stored types in DB when using polymorphism or STI (single table inheritance), this commit uses various Rails methods to ensure proper class is loaded and the stored name in DB is unchanged, eg: `Chat::Message` model will be stored as `"ChatMessage"`, and `"ChatMessage"` will correctly load `Chat::Message` model.
- Jobs are now using constants only, eg: `Jobs::Chat::Foo` and should only be enqueued this way

Notes:
- This commit also used this opportunity to limit the number of registered css files in plugin.rb
- `discourse_dev` support has been removed within this commit and will be reintroduced later

<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2023-03-17 14:24:38 +01:00
Andrei Prigorshnev 7df40fc905
DEV: do not fabricate a notification when fabricating a chat_mention (#20636)
This is just a little clean-up in tests. In the past, when creating a `chat_mention` 
record, we always created a related notification. Starting from fa543cda 
notifications and chat_mentions are fully decoupled from each other. So if we're 
testing just chat mentions there is no need to fabricate notifications for them.
2023-03-10 18:32:33 +04:00
Martin Brennan a252022117
DEV: Fix broken plugin specs because of bookmarkable changes (#20574) 2023-03-08 10:39:51 +08:00
Martin Brennan 360d0dde65
DEV: Change Bookmarkable registration to DiscoursePluginRegistry (#20556)
Similar spirit to e195e6f614,
this moves the Bookmarkable registration to DiscoursePluginRegistry
so plugins which are not enabled do not register additional
bookmarkable classes.
2023-03-08 10:39:12 +10:00
Andrei Prigorshnev fa543cda06
DEV: Always create chat mention records (#20470)
Before this commit, we created a chat mention record only in case we wanted to send a notification about that mention to the user. Notifications were the only use case for the chat_mention db table. Now we want to use that table for other features, so we have to always create a chat_mention record.
2023-03-07 19:07:11 +04:00
Loïc Guitaut bc4e016b49 DEV: Make the `model` step compatible with collections 2023-02-27 14:24:43 +01:00
Andrei Prigorshnev 69c7df2e56
DEV: do not fabricate a Notification when fabricating a ChatMention (#20450)
Initially, the chat_mention db table was created to support notifications. So when creating 
a `chat_mention` record we were always creating a related `notification` record. So did the
ChatMention fabricator. 

Now we want to use the chat_mention db table in other scenarios. So we started decoupling 
mentions from notification in 75b81b68.

This removes fabrication of Notifications from the ChatMention fabricator. We need to be able 
to fabricate a ChatMention without a Notification.
2023-02-27 14:41:28 +04:00
Loïc Guitaut b8762172e4 DEV: Allow `with_service` in jobs
This patch introduces a new `ServiceJob` class allowing the use of
`with_service` in jobs.

This way, it’s easier to use the chat service objects in jobs and
provides the same level of functionality than the one we have in
controllers.
2023-02-23 09:28:53 +01:00
Gerhard Schlager 7ef482a292
REFACTOR: Fix pluralized strings in chat plugin (#20357)
* FIX: Use pluralized string

* REFACTOR: Fix misuse of pluralized string

* REFACTOR: Fix misuse of pluralized string

* DEV: Remove linting of `one` key in MessageFormat string, it doesn't work

* REFACTOR: Fix misuse of pluralized string

This also ensures that the URL works on subfolder and shows the site setting link only for admins instead of staff. The string is quite complicated, so the best option was to switch to MessageFormat.

* REFACTOR: Fix misuse of pluralized string

* FIX: Use pluralized string

This also ensures that the URL works on subfolder and shows the site setting link only for admins instead of staff.

* REFACTOR: Correctly pluralize reaction tooltips in chat

This also ensures that maximum 5 usernames are shown and fixes the number of "others" which was off by 1 if the current user reacted on a message.

* REFACTOR: Use translatable string as comma separator

* DEV: Add comment to translation to clarify the meaning of `%{identifier}`

* REFACTOR: Use translatable comma separator and use explicit interpolation keys

* REFACTOR: Don't interpolate lowercase channel status

* REFACTOR: Fix misuse of pluralized string

* REFACTOR: Don't interpolate channel status

* REFACTOR: Use %{count} interpolation key

* REFACTOR: Fix misuse of pluralized string

* REFACTOR: Correctly pluralize DM chat channel titles
2023-02-20 10:31:02 +01:00
Andrei Prigorshnev 75b81b6854
DEV: extract the logic for extracting and expanding mentions from ChatNotifier (#20290)
Initially, the ChatMention model / db table was introduced to better support notifications (see discourse/discourse-chat@0801d10). That means that currently, we create a new chat_mention record only if a user will be notified about the mention.

Now we plan to start using the ChatMention model in other scenarios (for example for implementing user status on mentions) so we need to always create a new record in the chat_mention table. This PR does the first step into that direction by decoupling the logic for extracting and expanding mentions from the code related to notifications.

This doesn't change any behavior, only extracts code from ChatNotifier.
2023-02-16 19:55:18 +04:00
Martin Brennan c07f1e442f
DEV: Fix failing chat spec and add unexpected failure indicator (#20299)
This commit fixes the UpdateUserLastRead spec which was checking
for a message ID that did not exist -- this could fail at times
since message ID 2 could exist. Better to create + destroy a message
since then it's guaranteed we have a unique ID.

This also attempts to clarify a step that we expect to fail which
succeeds instead by adding another emoji next to the success tick and
an explanation text.

Also removes some uses of unless in Services::Base, we generally prefer
to use alternatives, since unless can be hard to parse in a lot of
cases.

Co-authored-by: Loïc Guitaut <loic@discourse.org>
2023-02-15 19:16:13 +01:00
Martin Brennan 60ad836313
DEV: Chat service object initial implementation (#19814)
This is a combined work of Martin Brennan, Loïc Guitaut, and Joffrey Jaffeux.

---

This commit implements a base service object when working in chat. The documentation is available at https://discourse.github.io/discourse/chat/backend/Chat/Service.html

Generating documentation has been made as part of this commit with a bigger goal in mind of generally making it easier to dive into the chat project.

Working with services generally involves 3 parts:

- The service object itself, which is a series of steps where few of them are specialized (model, transaction, policy)

```ruby
class UpdateAge
  include Chat::Service::Base

  model :user, :fetch_user
  policy :can_see_user
  contract
  step :update_age

  class Contract
    attribute :age, :integer
  end

  def fetch_user(user_id:, **)
    User.find_by(id: user_id)
  end

  def can_see_user(guardian:, **)
    guardian.can_see_user(user)
  end

  def update_age(age:, **)
    user.update!(age: age)
  end
end
```

- The `with_service` controller helper, handling success and failure of the service within a service and making easy to return proper response to it from the controller

```ruby
def update
  with_service(UpdateAge) do
    on_success { render_serialized(result.user, BasicUserSerializer, root: "user") }
  end
end
```

- Rspec matchers and steps inspector, improving the dev experience while creating specs for a service

```ruby
RSpec.describe(UpdateAge) do
  subject(:result) do
    described_class.call(guardian: guardian, user_id: user.id, age: age)
  end

  fab!(:user) { Fabricate(:user) }
  fab!(:current_user) { Fabricate(:admin) }

  let(:guardian) { Guardian.new(current_user) }
  let(:age) { 1 }

   it { expect(user.reload.age).to eq(age) }
end
```

Note in case of unexpected failure in your spec, the output will give all the relevant information:

```
  1) UpdateAge when no channel_id is given is expected to fail to find a model named 'user'
     Failure/Error: it { is_expected.to fail_to_find_a_model(:user) }

       Expected model 'foo' (key: 'result.model.user') was not found in the result object.

       [1/4] [model] 'user' 
       [2/4] [policy] 'can_see_user'
       [3/4] [contract] 'default'
       [4/4] [step] 'update_age'

       /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/update_age.rb:32:in `fetch_user': missing keyword: :user_id (ArgumentError)
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:202:in `instance_exec'
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:202:in `call'
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:219:in `call'
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `block in run!'
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `each'
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:417:in `run!'
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:411:in `run'
       	from <internal:kernel>:90:in `tap'
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/app/services/base.rb:302:in `call'
       	from /Users/joffreyjaffeux/Code/pr-discourse/plugins/chat/spec/services/update_age_spec.rb:15:in `block (3 levels) in <main>'
```
2023-02-13 13:09:57 +01:00
Martin Brennan 9a45b59fb5
FEATURE: Automatically create chat threads in background (#20206)
Whenever we create a chat message that is `in_reply_to` another
message, we want to lazily populate the thread record for the
message chain.

If there is no thread yet for the root message in the reply chain,
we create a new thread with the appropriate details, and use that
thread ID for every message in the chain that does not yet have
a thread ID.

* Root message (ID 1) - no thread ID
    * Message (ID 2, in_reply_to 1) - no thread ID
    * When I as a user create a message in reply to ID 2, we create a thread and apply it to ID 1, ID 2, and the new message

If there is a thread for the root message in the reply chain, we
do not create one, and use the thread ID for the newly created chat
message.

* Root message (ID 1) - thread ID 700
    * Message (ID 2, in_reply_to 1) - thread ID 700
    * When I as a user create a message in reply to ID 2, we use the existing thread ID 700 for the new message

We also support passing in the `thread_id` to `ChatMessageCreator`,
which will be used when replying to a message that is already part of
a thread, and we validate whether that `thread_id` is okay in the context
of the channel and also the reply chain.

This work is always done, regardless of channel `thread_enabled` settings
or the `enable_experimental_chat_threaded_discussions` site setting.

This commit does not include a large data migration to backfill threads for
all existing reply chains, its unnecessary to do this so early in the project,
we can do this later if necessary.

This commit also includes thread considerations in the `MessageMover` class:

* If the original message and N other messages of a thread is moved,
   the remaining messages in the thread have a new thread created in
   the old channel and are moved to it.
* The reply chain is not preserved for moved messages, so new threads are
   not created in the destination channel.

In addition to this, I added a fix to also clear the `in_reply_to_id` of messages
in the old channel which are moved out of that channel for data cleanliness.
2023-02-08 10:22:07 +10:00
Martin Brennan 1a6f6d1dc4
Revert "FEATURE: Automatically create chat threads in background (#20132)" (#20205)
This reverts commit 37e6e3be7f.
2023-02-08 09:59:18 +10:00
Martin Brennan 37e6e3be7f
FEATURE: Automatically create chat threads in background (#20132)
Whenever we create a chat message that is `in_reply_to` another
message, we want to lazily populate the thread record for the
message chain.

If there is no thread yet for the root message in the reply chain,
we create a new thread with the appropriate details, and use that
thread ID for every message in the chain that does not yet have
a thread ID.

* Root message (ID 1) - no thread ID
    * Message (ID 2, in_reply_to 1) - no thread ID
    * When I as a user create a message in reply to ID 2, we create a thread and apply it to ID 1, ID 2, and the new message

If there is a thread for the root message in the reply chain, we
do not create one, and use the thread ID for the newly created chat
message.

* Root message (ID 1) - thread ID 700
    * Message (ID 2, in_reply_to 1) - thread ID 700
    * When I as a user create a message in reply to ID 2, we use the existing thread ID 700 for the new message

We also support passing in the `thread_id` to `ChatMessageCreator`,
which will be used when replying to a message that is already part of
a thread, and we validate whether that `thread_id` is okay in the context
of the channel and also the reply chain.

This work is always done, regardless of channel `thread_enabled` settings
or the `enable_experimental_chat_threaded_discussions` site setting.

This commit does not include a large data migration to backfill threads for
all existing reply chains, its unnecessary to do this so early in the project,
we can do this later if necessary.

This commit also includes thread considerations in the `MessageMover` class:

* If the original message and N other messages of a thread is moved,
   the remaining messages in the thread have a new thread created in
   the old channel and are moved to it.
* The reply chain is not preserved for moved messages, so new threads are
   not created in the destination channel.

In addition to this, I added a fix to also clear the `in_reply_to_id` of messages
in the old channel which are moved out of that channel for data cleanliness.
2023-02-08 09:50:42 +10:00
Martin Brennan 0924f874bd
DEV: Use UploadReference instead of ChatUpload in chat (#19947)
We've had the UploadReference table for some time now in core,
but it was added after ChatUpload was and chat was just never
moved over to this new system.

This commit changes all chat code dealing with uploads to create/
update/delete/query UploadReference records instead of ChatUpload
records for consistency. At a later date we will drop the ChatUpload
table, but for now keeping it for data backup.

The migration + post migration are the same, we need both in case
any chat uploads are added/removed during deploy.
2023-01-24 13:28:21 +10:00
Martin Brennan 2eb0a300b6
FIX: Use hashtags in channel archive PMs if available (#19859)
If the enable_experimental_hashtag_autocomplete setting is
enabled, then we should autolink hashtag references to the
archived channels (e.g. #blah::channel) for a nicer UX, and
just show the channel name if not (since doing #channelName
can lead to weird inconsistent results).
2023-01-16 10:20:37 +10:00
Martin Brennan 387693e889
FIX: Improve error reporting and failure modes for channel archiving (#19791)
There was an issue with channel archiving, where at times the topic
creation could fail which left the archive in a bad state, as read-only
instead of archived. This commit does several things:

* Changes the ChatChannelArchiveService to validate the topic being
  created first and if it is not valid report the topic creation errors
  in the PM we send to the user
* Changes the UI message in the channel with the archive status to reflect
  that topic creation failed
* Validate the new topic when starting the archive process from the UI,
  and show the validation errors to the user straight away instead of
  creating the archive record and starting the process

This also fixes another issue in the discourse_dev config which was
failing because YAML parsing does not enable all classes by default now,
which was making the seeding rake task for chat fail.
2023-01-12 10:04:46 +10:00
David Taylor 055310cea4
DEV: Apply syntax_tree formatting to `plugins/*` 2023-01-07 11:11:37 +00:00
Krzysztof Kotlarek 9f927cf999
DEV: permission type for private category fabricator (#19601)
Allow to specify permission type for category fabricator to test `:readonly`, `:create_post` and `:full` rights.
2022-12-23 11:18:29 +08:00
Joffrey JAFFEUX d2e24f9569
DEV: start glimmer-ification and optimisations of chat plugin (#19531)
Note this is a very large PR, and some of it could have been splited, but keeping it one chunk made it to merge conflicts and to revert if necessary. Actual new code logic is also not that much, as most of the changes are removing js tests, adding system specs or moving things around.

To make it possible this commit is doing the following changes:

- converting (and adding new) existing js acceptances tests into system tests. This change was necessary to ensure as little regressions as possible while changing paradigm
- moving away from store. Using glimmer and tracked properties requires to have class objects everywhere and as a result works well with models. However store/adapters are suffering from many bugs and limitations. As a workaround the `chat-api` and `chat-channels-manager` are an answer to this problem by encapsulating backend calls and frontend storage logic; while still using js models.
- dropping `appEvents` as much as possible. Using tracked properties and a better local storage of channel models, allows to be much more reactive and doesn’t require arbitrary manual updates everywhere in the app.
- while working on replacing store, the existing work of a chat api (backend) has been continued to support more cases.
- removing code from the `chat` service to separate concerns, `chat-subscriptions-manager` and `chat-channels-manager`, being the largest examples of where the code has been rewritten/moved.

Future wok:
- improve behavior when closing/deleting a channel, it's already slightly buggy on live, it's rare enough that it's not a big issue, but should be improved
- improve page objects used in chat
- move more endpoints to the API
- finish temporarily skipped tests
- extract more code from the `chat` service
- use glimmer for `chat-messages`
- separate concerns in `chat-live-pane`
- eventually add js tests for `chat-api`, `chat-channels-manager` and `chat-subscriptions-manager`, they are indirectly heavy tested through system tests but it would be nice to at least test the public API

<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
2022-12-21 13:21:02 +01:00
Martin Brennan baf78d3d91
FIX: Add missing user_id args for ChatMessage.cook (#19508)
In both ChatMessage#rebake! and in ChatMessageProcessor
when we were calling ChatMessage.cook we were missing the
user_id to cook with, which causes missed hashtag cooks
because of missing permissions.
2022-12-19 11:05:37 +10:00
Krzysztof Kotlarek 09d15d4c7f
FIX: access to category chat only when user can create post (#19488)
Previously, restricted category chat channel was available for all groups - even `readonly`. From now on, only user who belong to group with `create_post` or `full` permissions can access that chat channel.
2022-12-19 11:35:28 +11:00
Martin Brennan ec9ec1e04e
FEATURE: Sort hashtags starting with term higher priority (#19463)
This introduces another "section" of queries to the
hashtag autocomplete search, which returns results for
each type that start with the search term. So now results
will be in this order, and within these sections ordered
by the types in priority order:

1. Exact matches sorted by type
2. "starts with" sorted by type
3. Everything else sorted by type then name within type
2022-12-15 13:01:44 +10:00
Martin Brennan 3ee4b59c64
DEV: Use guardian user for can_chat? (#19418)
Instead of passing `user` to `guardian.can_chat?`, we
can just use the inner `@user` that is part of the guardian
instance already to determine whether that user can chat,
since this is how it works for all other usages of guardian
even within chat.
2022-12-13 09:14:17 +10:00
Martin Brennan f5b464ead5
FIX: Do not return channels for hashtags if user cannot chat (#19417)
Previously with this experimental feature a user would be
able to search for public channels for public categories
using the new #hashtag system even if they couldn't chat.
This commit fixes the hole.
2022-12-12 12:24:41 +10:00
Martin Brennan 3fdb8ffb57
FEATURE: Allow showing hashtag autocomplete results without term (#19219)
This commit allows us to type # in the UI and present autocomplete
results immediately with the following logic for the topic composer,
and reversed for the chat composer:

* Categories the user can access and has not muted sorted by `topic_count`
* Tags the user can access and has not muted sorted by `topic_count`
* Chat channels the user is a member of sorted by `messages_count`

So in effect, we allow searching for hashtags without a search term.
To do this we add a new `search_without_term` to each data source so
each one can define how it wants to handle this logic.
2022-12-08 13:47:59 +10:00
Roman Rizzi 9c8043a4d2
FEATURE: Enforce mention limits for chat messages (#19034)
* FEATURE: Enforce mention limits for chat messages

The first part of these changes adds a new setting called `max_mentions_per_chat_message`, which skips notifications when the message contains too many mentions. It also respects the `max_users_notified_per_group_mention` setting
and skips notifications if expanding a group mention would exceed it.

We also include a new component to display JIT warning for these limits to the user while composing a message.

* Simplify ignoring/muting filter in chat_notifier

* Post-send warnings for unsent warnings

* Improve pluralization

* Address review feedback

* Fix test

* Address second feedback round

* Third round of feedback

Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
2022-12-06 14:54:04 -03:00
Joffrey JAFFEUX 68c4f16a73
FEATURE: channels can allow/disallow @all/@here mentions (#19317)
The settings tab of each category channel should now present the option to allow or disallow channel wide mentions: @here and @all.

When disallowed, using these mentions in the channel should have no effect.
2022-12-05 17:03:51 +01:00
Martin Brennan a34838d671
FIX: Minor hashtag autocomplete fixes (#19173)
* Do not search category name when searching channels to avoid
  confusing results
* Overflow text in autocomplete menu with ... if it is too long
* Make autocomplete menu less height
2022-11-24 15:45:13 +11:00