Why this change?
We are currently not fully satisfied with the current way to edit the
categories and tags that appears in the sidebar where the user is
redirected to the tracking preferences tab in the user's profile causing
the user to lose context of the current page. In addition, the dropdown
to select categories or tags limits the amount of information we can
display.
Since editing or adding a custom categories section is already using a
modal, we have decided to switch editing the categories and tags that
appear in the sidebar to use a modal as well.
This commit removes the `new_edit_sidebar_categories_tags_interface_groups` site setting and
make the modals the default for all users.
See discuss.rubyonrails.org/t/cve-2023-28362-possible-xss-via-user-supplied-values-to/83132
Impact of this vulnerability has been assess to be very low for Discourse since XSS attacks are mitigated by Discourse's default CSP.
Updates the interface for implementing summarization strategies and adds a cache layer to summarize topics once.
The cache stores the final summary and each chunk used to build it, which will be useful when we have to extend or rebuild it.
Cater for polls that can have multiple votes per user.
This fixes an older UserMerge and migration which was intended to
de-duplicate poll votes but did not account for "multiple" type polls.
When the composer is open with a draft for a topic and the user clicks the edit button of a post on the same topic, we shouldn't display the "Save Draft" button. Because the edited post's draft will override the existing draft of the same topic even if we saved it.
Why this change?
We want the position of the filters to remain fixed when scrolling
through the list of categories or tags. Otherwise, the user has to
scroll all the way back to othe top in order to access the filters when
the list of categories or tags is large.
New setting which allow admin to define behavior when topic is in watched category and muted topic and vice versa.
If watched_precedence_over_muted setting is true, that topic is still visible in list of topics and notification is created.
If watched_precedence_over_muted setting is false, that topic is not still visible in list of topics and notification is skipped as well.
Why does this change do?
If the `fixed_category_positions` is `false`, we want to order the
categories in the edit navigation menu categories modal by name. This
makes it easier to filter through a large list of categories.
This commit also fixes a bug where we were unintentionally mutating the
`this.site.categories` array.
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
```
Why is this change required?
The `/new-topic` route is a special route which we use to open the
composer by loading a URL. By default, the `new-topic` route is replaced with the
`discovery.latest` route. On a fresh page load, this makes sense since
there is no template for the `new-topic` route to render. However, this
behavior does not make sense if we're transition from another route.
There is no need to replace the current route with the `discovery.latest` when all we want
is to open the composer.
What does this commit do?
This commit fixes the undesirable behaviour described above by aborting
the existing transition to the `new-topic` route if `transition.from` is
present. This indicates that we're navigating from an existing route and
we can just open the composer.
While still in ember-cli new app blueprint, I don't think this package does much for us. It has support for older things like bower and npm-shrinkwrap, but doesn't support checking yarn.lock and doesn't necessarily work well with our project structure.
- gridified the thread message indicator, alleviating some problems with positioning and overflow
participant avatars will overlap/smush on smaller size and mobile
- the excerpt went from 3 > 2 lines of wrapping on smaller size, still 1 line on large size
- dropped the copy of "last reply"
- fixed wrong line height
- moved the "x replies" over to the right near the participants, as that makes more sense
- using a bubble to indicate other participants, instead of copy
This PR introduces the @container query, which is experimental. Nothing will break when it's being viewed in a not-supported browser, but it will be less elegant.
While we are unable to support OAUTH2 with pop3 (due to upstream dependency ruby/net-pop#16), we are adding the support for mail pollers plugin. Doing so, it would be possible to write a plugin which then uses other ways (microsoft graph sdk for example) to poll emails from a mailbox.
The idea is that a plugin would define a class which inherits from Email::Poller and defines a poll_mailbox static method which returns an array of strings. Then the plugin could call register_mail_poller(<class_name>) to have it registered. All the configuration (oauth2 tokens, email, etc) could be managed by sitesettings defined in the plugin.
This change adds support retroactively updating display names in the new quote format when the user's name is changed. It happens through a background job that is triggered by a callback when a user is saved with a new name.
Why is this change required?
Previously, the tests in `viewing_sidebar_as_anonymous_user_spec.rb` was
flaky because the ordering of the tags changes depending on what the
auto generated tag names are. If a tag name is generated with the name
`tag10`, it would then be sorted before `tag9` which messes up the
ordering specified in our tests. This commit fixes the problem by
specifying the tag names instead of relying on the auto generated ones
by fabricator.
This commit adds data attributes to identify the controls in the user settings UI.
Plugins and TCs can use this information to target each setting to highlight or hide
them.
Although most of the settings also have specific classes identifying them, using data
attributes is more future proof as it is less likely to change them classes, specially
as we increase the adoption of the BEM methodology in CSS.
Using data attributes also are semantically correct as the setting name is data not really related to the classes used.
Alan Guo Xiang Tan
Greg Molnar
Jarek Radosz
Kris
Roman Rizzi
Vinoth Kannan
Discourse Translator Bot
Natalie Tay
chapoi
Krzysztof Kotlarek
Loïc Guitaut
dependabot[bot]
Rafael dos Santos Silva
Bianca Nenciu
Joffrey JAFFEUX
Alessio Cosenza
Ted Johansson
Sérgio Saquetim
Kyle