Add categories to the serialized search results together with the topics
when lazy load categories is enabled. This is necessary in order for the
results to be rendered correctly and display the category information.
We're starting to use this system for non-ember-5 deprecations, so linking to the Ember 5 topic doesn't make sense. Instead, we can include the deprecation ID to help with identifying the issue.
Why this change?
The current shape of errors returns the error messages after it has been
translated but there are cases where we want to customize the error
messages and the current way return only translated error messages is
making customization of error messages difficult. If we
wish to have the error messages in complete sentences like
"`some_property` property must be present in #link 1", this is not
possible at the moment with the current shape of the errors we return.
What does this change do?
This change introduces the `ThemeSettingsObjectValidator::ThemeSettingsObjectErrors`
and `ThemeSettingsObjectValidator::ThemeSettingsObjectError` classes to
hold the relevant error key and i18n translation options.
We have separated and combined modes for sidebar panels.
Separated means the panels show only their own sections,
combined means sections from all panels are shown.
The admin sidebar only shows its own panels, so it must set
the mode to separated; however when we navigate to chat or
home we must revert to the initial mode setttings.
When hiding/showing the sidebar, as is the case on mobile
and using the toggle in the top left on desktop, we delete
and recreate the ember component on the page. This causes
the `sections` for each sidebar panel to get re-evaluated
every time.
For the admin sidebar, this means that we were constantly
re-adding the plugin links to the sidebar, causing duplication.
This can be fixed by just adding @cached to the getter for
sections.
The Digital Services Act requires a checkbox for any user who's flagging a post as illegal to confirm that they are flagging in good faith. This PR adds that.
Why this change?
This change supports a property of `type: category` in the schema that
is declared for a theme setting object. Example:
```
sections:
type: objects
schema:
name: section
properties:
category_property:
type: category
```
The value of a property declared as `type: category` will have to be a
valid id of a row in the `categories` table.
What does this change do?
Adds a property value validation step for `type: category`. Care has
been taken to ensure that we do not spam the database with a ton of
requests if there are alot of category typed properties. This is done by
walking through the entire object and collecting all the values for
properties typed category. After which, a single database query is
executed to validate which values are valid.
Why this change?
Firstly, note that this is not a security commit because this feature is
still in development and should not be used anywhere.
The reason we want to set a limit here is to greatly reduce the
possibility of a DoS attack in the future via `ThemeSetting` where
someone would set an arbituary large json string in
`ThemeSetting#json_value` and causing the server to run out of resources
trying to serialize/deserialize the value.
What does this change do?
Adds an ActiveRecord validation to ensure that the bytesize of the json
string being stored is smaller than or equal to 0.5mb. We believe 0.5mb
is a decent limit for now but we can review the limit in the future if
we believe it is too small.
Why this change?
The logic for validating a theme setting's value and default value was
not consistent as each part of the code would implement its own logic.
This is not ideal as the default value may be validated differently than
when we are setting a new value. Therefore, this commit seeks to
refactor all the validation logic for a theme setting's value into a
single service class.
What does this change do?
Introduce the `ThemeSettingsValidator` service class which holds all the
necessary helper methods required to validate a theme setting's value
A while ago we increased group SMTP read and open timeouts
to address issues we were seeing with Gmail sometimes giving
really long timeouts for these values. The commit was:
3e639e4aa7
Now, we want to increase all SMTP read timeouts to 30s,
since the 5s is too low sometimes, and the ruby Net::SMTP
stdlib also defaults to 30s.
Also, we want to slightly tweak the group smtp email job
not to fail if the IncomingEmail log fails to create, or if
a ReadTimeout is encountered, to avoid retrying the job in sidekiq
again and sending the same email out.
* Remove unnecessary properties
* Use rem unit
* Add a drop shadow
* Make the "box shadow" slightly more subtle
* Use --d-border-radius
* Don't scale the "box shadow" on hover
* Scale down the on-hover size
* Make the button slightly larger
* Respect prefers-reduced-motion
* Use white rather than --secondary-or-primary
* Don't animate on-hover on mobile
This feature adds the functionality to start a new chat directly from the URL using query params.
The format is: /chat/new-message?recipients=buford,jona
The initial version of this feature allows for the following:
- Open an existing direct message channel with a single user
- Create a new direct message channel with a single user (and auto redirect)
- Create or open a channel with multiple users (and auto redirect)
- Redirects to chat home if the recipients param is missing
This commit introduces the possibility to stream messages. To allow plugins to use streaming this commit also ships a `ChatSDK` library to allow to interact with few parts of discourse chat.
```ruby
ChatSDK::Message.create_with_stream(raw: "test") do |helper|
5.times do |i|
is_streaming = helper.stream(raw: "more #{i}")
next if !is_streaming
sleep 2
end
end
```
This commit also introduces all the frontend parts:
- messages can now be marked as streaming
- when streaming their content will be updated when a new content is appended
- a special UI will be showing (a blinking indicator)
- a cancel button allows the user to stop the streaming, when cancelled `helper.stream(...)` will return `false`, and the plugin can decide exit early
During extensibility when we add post menu buttons we very much want access
to the topic.
The transformer does not include a `topic` attribute due to historical reasons.
Given we are going to move away from transforming long term and need to give
plugins access to topic when they are adding buttons, just add the extra
property
This commit moves some code out of UploadController#show_secure
so it can be reused in other controllers if a secure upload
needs to have permission checks run.
Why this change?
This commit updates `ThemeSettingsObjectValidator` to validate a
property's value against the validations listed in the schema.
For string types, `min_length`, `max_length` and `url` are supported.
For integer and float types, `min` and `max` are supported.
This commit adds another plugin modifier related to post
actions, similar to ae24e04a5e.
This will be used to exclude users who liked _and_ reacted to
the post, since now in discourse-reactions we make a Like when
a user reacts too. This will affect the display of the post footer.
Recently we changed the code to check permission in the backend. Example PR https://github.com/discourse/discourse/pull/25735
After those changes, `isInAnyGroups` and `userInAnyGroups` functions are not used anymore.
If you upload a portrait video or just a video that doesn't fit in the
normal video dimensions we want it to have a black background instead of
trying to render parts of the placeholder image as the video background.
This change removes the placeholder image for the video background when
the play button is clicked and replaces it with an all black background.
Why this change?
This change adds property value validation to `ThemeSettingsObjectValidator`
for the following types: "string", "integer", "float", "boolean", "enum". Note
that this class is not being used anywhere yet and is still in
development.
Why this change?
For some reason, we were setting up bootsnap manually even though the
official documentation suggests requiring `bootsnap/setup` which will
setup bootsnap using the default configuration. Because we were calling
`Bootsnap.setup` manually, we did not set the `development_mode` option
which defaults to `true`. Hence, we were running bootsnap in development
mode even in the production environment which I suppose is not ideal.
What does this change do?
Instead of calling `Bootsnap.setup` manually, we can just use `require
'bootsnap/setup' instead.`
Daniel Waterworth
Jarek Radosz
Bianca Nenciu
chapoi
David Taylor
David Battersby
Kelv
Alan Guo Xiang Tan
Ella E
Martin Brennan
Ted Johansson
dependabot[bot]
Krzysztof Kotlarek
Discourse Translator Bot
Osama Sayegh
Joffrey JAFFEUX
Sam
Blake Erickson
Jan Cernik