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.
The user card is always present in the DOM. Therefore we only need to
add the `aria-labelledby` attribute when there is a user (and a title)
to point to.
What does this change do?
This change adds a dropdown filter that allows a user to filter by
selected or unselected categories/tags in the edit navigation menu
modal.
For the categories modal, parent categories that do not match the
dropdown filter will be displayed as disabled since those parent
categories need to be displayed to maintain the hieracy of the child
child categories.
Why this change?
Predicate matchers are poor at providing good error messages when it
fails if all the predicate matcher does is to return a boolean. Prior to
this change, we were using `has_css? && all?` to assert for the tag
section links. There are two problems here. Firstly, when one of the matchers
fail, the error message does not provide any indication of which matcher
failed making it hard to debug failures. Secondly, the matchers were not
able to assert for the ordering of the tag section links which is an
important behaviour to assert for.
This commit changes `PageObjects::Components::Sidebar#has_tag_section_links?`
such that we make use of assertions to ensure ordering. The usage of
`all` will also provide a clear error message when things go wrong.
Why this change?
There was alot of duplication between the edit navigation menu tags/categories modal which
was making it hard to introduce new changes as the work had to be
duplicated into multiple places.
This commit mainly extracts the duplicated code into common components
such that it is easier to make styling changes across both modals.
This PR splits up the preference that controls the count vs dot and destination of sidebar links, which is really hard to understand, into 2 simpler checkboxes:
The new preferences/checkboxes are off by default, but there are database migrations to switch the old preference to the new ones so that existing users don't have to update their preferences to keep their preferred behavior of sidebar links when this changed is rolled out.
Internal topic: t/103529.
Introduces a new above-latest-topic-list-item-post-count outlet, providing a clean way to add other useful elements to the topic-stats section of the latest-topic-list-item template.
What this change?
When a user opens the modal to edit tags or categories for the
navigation menu, we want to input filter to have focus. This commit
fixes that by doing the following:
1. Changes <DModal> component such that it prioritises elements with the
autofocus attribute first.
2. Adds `autofocus` to the input elements on the edit tags/categories
modal form.
