2024-02-20 16:49:19 +08:00
|
|
|
|
# frozen_string_literal: true
|
|
|
|
|
|
|
|
|
|
module ChatSDK
|
|
|
|
|
class Thread
|
|
|
|
|
# Updates the title of a specified chat thread.
|
|
|
|
|
#
|
|
|
|
|
# @param title [String] The new title for the chat thread.
|
|
|
|
|
# @param thread_id [Integer] The ID of the chat thread to be updated.
|
|
|
|
|
# @param guardian [Guardian] The guardian object representing the user's permissions.
|
|
|
|
|
# @return [Chat::Thread] The updated thread object with the new title.
|
|
|
|
|
#
|
|
|
|
|
# @example Updating the title of a chat thread
|
|
|
|
|
# ChatSDK::Thread.update_title(title: "New Thread Title", thread_id: 1, guardian: Guardian.new)
|
2024-05-03 23:30:39 +08:00
|
|
|
|
#
|
|
|
|
|
def self.update_title(thread_id:, guardian:, title:)
|
DEV: Provide user input to services using `params` key
Currently in services, we don’t make a distinction between input
parameters, options and dependencies.
This can lead to user input modifying the service behavior, whereas it
was not the developer intention.
This patch addresses the issue by changing how data is provided to
services:
- `params` is now used to hold all data coming from outside (typically
user input from a controller) and a contract will take its values from
`params`.
- `options` is a new key to provide options to a service. This typically
allows changing a service behavior at runtime. It is, of course,
totally optional.
- `dependencies` is actually anything else provided to the service (like
`guardian`) and available directly from the context object.
The `service_params` helper in controllers has been updated to reflect
those changes, so most of the existing services didn’t need specific
changes.
The options block has the same DSL as contracts, as it’s also based on
`ActiveModel`. There aren’t any validations, though. Here’s an example:
```ruby
options do
attribute :allow_changing_hidden, :boolean, default: false
end
```
And here’s an example of how to call a service with the new keys:
```ruby
MyService.call(params: { key1: value1, … }, options: { my_option: true }, guardian:, …)
```
2024-10-18 23:45:47 +08:00
|
|
|
|
new.update(thread_id:, guardian:, title:)
|
2024-02-20 16:49:19 +08:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
# Retrieves messages from a specified thread.
|
|
|
|
|
#
|
|
|
|
|
# @param thread_id [Integer] The ID of the chat thread from which to fetch messages.
|
|
|
|
|
# @param guardian [Guardian] The guardian object representing the user's permissions.
|
|
|
|
|
# @return [Array<Chat::Message>] An array of message objects from the specified thread.
|
|
|
|
|
#
|
|
|
|
|
# @example Fetching messages from a thread with additional parameters
|
|
|
|
|
# ChatSDK::Thread.messages(thread_id: 1, guardian: Guardian.new)
|
|
|
|
|
#
|
DEV: Provide user input to services using `params` key
Currently in services, we don’t make a distinction between input
parameters, options and dependencies.
This can lead to user input modifying the service behavior, whereas it
was not the developer intention.
This patch addresses the issue by changing how data is provided to
services:
- `params` is now used to hold all data coming from outside (typically
user input from a controller) and a contract will take its values from
`params`.
- `options` is a new key to provide options to a service. This typically
allows changing a service behavior at runtime. It is, of course,
totally optional.
- `dependencies` is actually anything else provided to the service (like
`guardian`) and available directly from the context object.
The `service_params` helper in controllers has been updated to reflect
those changes, so most of the existing services didn’t need specific
changes.
The options block has the same DSL as contracts, as it’s also based on
`ActiveModel`. There aren’t any validations, though. Here’s an example:
```ruby
options do
attribute :allow_changing_hidden, :boolean, default: false
end
```
And here’s an example of how to call a service with the new keys:
```ruby
MyService.call(params: { key1: value1, … }, options: { my_option: true }, guardian:, …)
```
2024-10-18 23:45:47 +08:00
|
|
|
|
def self.messages(...)
|
|
|
|
|
new.messages(...)
|
2024-02-20 16:49:19 +08:00
|
|
|
|
end
|
|
|
|
|
|
2024-05-03 23:30:39 +08:00
|
|
|
|
# Fetches the first messages from a specified chat thread, starting from the first available message.
|
|
|
|
|
#
|
|
|
|
|
# @param thread_id [Integer] The ID of the chat thread from which to fetch messages.
|
|
|
|
|
# @param guardian [Guardian] The guardian object representing the user's permissions.
|
|
|
|
|
# @param page_size [Integer] (optional) The number of messages to fetch, defaults to 10.
|
|
|
|
|
# @return [Array<Chat::Message>] An array of message objects representing the first messages in the thread.
|
|
|
|
|
#
|
|
|
|
|
# @example Fetching the first 15 messages from a thread
|
|
|
|
|
# ChatSDK::Thread.first_messages(thread_id: 1, guardian: Guardian.new, page_size: 15)
|
|
|
|
|
#
|
|
|
|
|
def self.first_messages(thread_id:, guardian:, page_size: 10)
|
|
|
|
|
new.messages(
|
DEV: Provide user input to services using `params` key
Currently in services, we don’t make a distinction between input
parameters, options and dependencies.
This can lead to user input modifying the service behavior, whereas it
was not the developer intention.
This patch addresses the issue by changing how data is provided to
services:
- `params` is now used to hold all data coming from outside (typically
user input from a controller) and a contract will take its values from
`params`.
- `options` is a new key to provide options to a service. This typically
allows changing a service behavior at runtime. It is, of course,
totally optional.
- `dependencies` is actually anything else provided to the service (like
`guardian`) and available directly from the context object.
The `service_params` helper in controllers has been updated to reflect
those changes, so most of the existing services didn’t need specific
changes.
The options block has the same DSL as contracts, as it’s also based on
`ActiveModel`. There aren’t any validations, though. Here’s an example:
```ruby
options do
attribute :allow_changing_hidden, :boolean, default: false
end
```
And here’s an example of how to call a service with the new keys:
```ruby
MyService.call(params: { key1: value1, … }, options: { my_option: true }, guardian:, …)
```
2024-10-18 23:45:47 +08:00
|
|
|
|
thread_id:,
|
|
|
|
|
guardian:,
|
|
|
|
|
page_size:,
|
2024-05-03 23:30:39 +08:00
|
|
|
|
direction: "future",
|
|
|
|
|
fetch_from_first_message: true,
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
# Fetches the last messages from a specified chat thread, starting from the last available message.
|
|
|
|
|
#
|
|
|
|
|
# @param thread_id [Integer] The ID of the chat thread from which to fetch messages.
|
|
|
|
|
# @param guardian [Guardian] The guardian object representing the user's permissions.
|
|
|
|
|
# @param page_size [Integer] (optional) The number of messages to fetch, defaults to 10.
|
|
|
|
|
# @return [Array<Chat::Message>] An array of message objects representing the last messages in the thread.
|
|
|
|
|
#
|
|
|
|
|
# @example Fetching the last 20 messages from a thread
|
|
|
|
|
# ChatSDK::Thread.last_messages(thread_id: 2, guardian: Guardian.new, page_size: 20)
|
|
|
|
|
#
|
|
|
|
|
def self.last_messages(thread_id:, guardian:, page_size: 10)
|
|
|
|
|
new.messages(
|
DEV: Provide user input to services using `params` key
Currently in services, we don’t make a distinction between input
parameters, options and dependencies.
This can lead to user input modifying the service behavior, whereas it
was not the developer intention.
This patch addresses the issue by changing how data is provided to
services:
- `params` is now used to hold all data coming from outside (typically
user input from a controller) and a contract will take its values from
`params`.
- `options` is a new key to provide options to a service. This typically
allows changing a service behavior at runtime. It is, of course,
totally optional.
- `dependencies` is actually anything else provided to the service (like
`guardian`) and available directly from the context object.
The `service_params` helper in controllers has been updated to reflect
those changes, so most of the existing services didn’t need specific
changes.
The options block has the same DSL as contracts, as it’s also based on
`ActiveModel`. There aren’t any validations, though. Here’s an example:
```ruby
options do
attribute :allow_changing_hidden, :boolean, default: false
end
```
And here’s an example of how to call a service with the new keys:
```ruby
MyService.call(params: { key1: value1, … }, options: { my_option: true }, guardian:, …)
```
2024-10-18 23:45:47 +08:00
|
|
|
|
thread_id:,
|
|
|
|
|
guardian:,
|
|
|
|
|
page_size:,
|
2024-05-03 23:30:39 +08:00
|
|
|
|
direction: "past",
|
|
|
|
|
fetch_from_last_message: true,
|
|
|
|
|
)
|
|
|
|
|
end
|
|
|
|
|
|
DEV: Provide user input to services using `params` key
Currently in services, we don’t make a distinction between input
parameters, options and dependencies.
This can lead to user input modifying the service behavior, whereas it
was not the developer intention.
This patch addresses the issue by changing how data is provided to
services:
- `params` is now used to hold all data coming from outside (typically
user input from a controller) and a contract will take its values from
`params`.
- `options` is a new key to provide options to a service. This typically
allows changing a service behavior at runtime. It is, of course,
totally optional.
- `dependencies` is actually anything else provided to the service (like
`guardian`) and available directly from the context object.
The `service_params` helper in controllers has been updated to reflect
those changes, so most of the existing services didn’t need specific
changes.
The options block has the same DSL as contracts, as it’s also based on
`ActiveModel`. There aren’t any validations, though. Here’s an example:
```ruby
options do
attribute :allow_changing_hidden, :boolean, default: false
end
```
And here’s an example of how to call a service with the new keys:
```ruby
MyService.call(params: { key1: value1, … }, options: { my_option: true }, guardian:, …)
```
2024-10-18 23:45:47 +08:00
|
|
|
|
def self.update(...)
|
|
|
|
|
new.update(...)
|
2024-05-03 23:30:39 +08:00
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
def messages(thread_id:, guardian:, direction: "future", **params)
|
DEV: Provide user input to services using `params` key
Currently in services, we don’t make a distinction between input
parameters, options and dependencies.
This can lead to user input modifying the service behavior, whereas it
was not the developer intention.
This patch addresses the issue by changing how data is provided to
services:
- `params` is now used to hold all data coming from outside (typically
user input from a controller) and a contract will take its values from
`params`.
- `options` is a new key to provide options to a service. This typically
allows changing a service behavior at runtime. It is, of course,
totally optional.
- `dependencies` is actually anything else provided to the service (like
`guardian`) and available directly from the context object.
The `service_params` helper in controllers has been updated to reflect
those changes, so most of the existing services didn’t need specific
changes.
The options block has the same DSL as contracts, as it’s also based on
`ActiveModel`. There aren’t any validations, though. Here’s an example:
```ruby
options do
attribute :allow_changing_hidden, :boolean, default: false
end
```
And here’s an example of how to call a service with the new keys:
```ruby
MyService.call(params: { key1: value1, … }, options: { my_option: true }, guardian:, …)
```
2024-10-18 23:45:47 +08:00
|
|
|
|
Chat::ListChannelThreadMessages.call(
|
|
|
|
|
guardian:,
|
|
|
|
|
params: {
|
|
|
|
|
thread_id:,
|
|
|
|
|
direction:,
|
|
|
|
|
**params,
|
|
|
|
|
},
|
|
|
|
|
) do
|
DEV: Stop injecting a service result object in the caller object
Currently, when calling a service with its block form, a `#result`
method is automatically created on the caller object. Even if it never
clashed so far, this could happen.
This patch removes that method, and instead use a more classical way of
doing things: the result object is now provided as an argument to the
main block. This means if we need to access the result object in an
outcome block, it will be done like this from now on:
```ruby
MyService.call(params) do |result|
on_success do
# do something with the result object
do_something(result)
end
end
```
In the same vein, this patch introduces the ability to match keys from
the result object in the outcome blocks, like we already do with step
definitions in a service. For example:
```ruby
on_success do |model:, contract:|
do_something(model, contract)
end
```
Instead of
```ruby
on_success do
do_something(result.model, result.contract)
end
```
2024-10-21 21:37:02 +08:00
|
|
|
|
on_success { |messages:| messages }
|
2024-02-20 16:49:19 +08:00
|
|
|
|
on_failed_policy(:can_view_thread) { raise "Guardian can't view thread" }
|
|
|
|
|
on_failed_policy(:target_message_exists) { raise "Target message doesn't exist" }
|
2024-02-26 21:16:29 +08:00
|
|
|
|
on_failure { raise "Unexpected error" }
|
2024-02-20 16:49:19 +08:00
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
DEV: Provide user input to services using `params` key
Currently in services, we don’t make a distinction between input
parameters, options and dependencies.
This can lead to user input modifying the service behavior, whereas it
was not the developer intention.
This patch addresses the issue by changing how data is provided to
services:
- `params` is now used to hold all data coming from outside (typically
user input from a controller) and a contract will take its values from
`params`.
- `options` is a new key to provide options to a service. This typically
allows changing a service behavior at runtime. It is, of course,
totally optional.
- `dependencies` is actually anything else provided to the service (like
`guardian`) and available directly from the context object.
The `service_params` helper in controllers has been updated to reflect
those changes, so most of the existing services didn’t need specific
changes.
The options block has the same DSL as contracts, as it’s also based on
`ActiveModel`. There aren’t any validations, though. Here’s an example:
```ruby
options do
attribute :allow_changing_hidden, :boolean, default: false
end
```
And here’s an example of how to call a service with the new keys:
```ruby
MyService.call(params: { key1: value1, … }, options: { my_option: true }, guardian:, …)
```
2024-10-18 23:45:47 +08:00
|
|
|
|
def update(guardian:, **params)
|
|
|
|
|
Chat::UpdateThread.call(guardian:, params:) do
|
2024-02-20 16:49:19 +08:00
|
|
|
|
on_model_not_found(:channel) do
|
|
|
|
|
raise "Couldn’t find channel with id: `#{params[:channel_id]}`"
|
|
|
|
|
end
|
|
|
|
|
on_model_not_found(:thread) do
|
|
|
|
|
raise "Couldn’t find thread with id: `#{params[:thread_id]}`"
|
|
|
|
|
end
|
|
|
|
|
on_failed_policy(:can_view_channel) { raise "Guardian can't view channel" }
|
|
|
|
|
on_failed_policy(:can_edit_thread) { raise "Guardian can't edit thread" }
|
|
|
|
|
on_failed_policy(:threading_enabled_for_channel) do
|
|
|
|
|
raise "Threading is not enabled for this channel"
|
|
|
|
|
end
|
|
|
|
|
on_failed_contract { |contract| raise contract.errors.full_messages.join(", ") }
|
DEV: Stop injecting a service result object in the caller object
Currently, when calling a service with its block form, a `#result`
method is automatically created on the caller object. Even if it never
clashed so far, this could happen.
This patch removes that method, and instead use a more classical way of
doing things: the result object is now provided as an argument to the
main block. This means if we need to access the result object in an
outcome block, it will be done like this from now on:
```ruby
MyService.call(params) do |result|
on_success do
# do something with the result object
do_something(result)
end
end
```
In the same vein, this patch introduces the ability to match keys from
the result object in the outcome blocks, like we already do with step
definitions in a service. For example:
```ruby
on_success do |model:, contract:|
do_something(model, contract)
end
```
Instead of
```ruby
on_success do
do_something(result.model, result.contract)
end
```
2024-10-21 21:37:02 +08:00
|
|
|
|
on_success { |thread:| thread }
|
2024-02-26 21:16:29 +08:00
|
|
|
|
on_failure { raise "Unexpected error" }
|
2024-02-20 16:49:19 +08:00
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|