Previously if a specific plugin route was not available (e.g. there was an error loading the plugin's JS due to an ad blocker), the entire page would fail to load. This commit updates the behavior to catch this kind of issue and display a user-friendly message at the top of the screen.
Repro steps:
- enable permanent deletes (via hidden site setting)
- set `min_topic_views_for_delete_confirm` to 0
When permanently deleting, the delete confirm modal is shown (for a
second time) and it doesn't pass the `force_destroy` parameter to the
request and the action results in a 422 error (i.e. can't perma-delete).
This change skips showing the confirm modal when perma-deleting given
that it has already been show on the first delete action.
There are two possible ordering for categories shown in sidebar with
this commit.
When the `fixed_category_positions` site setting is enabled, the
categories are ordered based on `Category#position` which is a configurable
option by the user. When said site setting is disabled, the categories
are ordered based on `Category#name`.
The categories in Sidebar are also sorted in such a way where child
categories are always ordered right after their parents. When multiple
child categories are present, the child categories are ordered based on
the ordering described above.
This updates the behavior of the list destination setting for links in the sidebar.
By default, new/unread content will show a dot like chat, rather than the count of new/unread topics.
If a user chooses to link to new/unread in the sidebar, we'll show the count.
The goal here is to find a simple default for typical users (new/unread indication, no counts, default links) while providing a different workflow for power users (showing new/unread counts, and linking directly to new/unread).
Internal Ref: /t/82626
`siteSettings` is now a service which means there should only be one
state for `siteSettings` during the life time of the application. This
also helps to maintain parity with production where the `site` model
relies on the `siteSettings` service and not a clone of the attributes.
Previously when a topic had e.g. 10 posts and you read them all, the link to the "first unread" would be `/11`, even when we knew there are only 10. (the topic route/controller would then fix that in the location bar after a second if you followed that URL)
This commit fixes a bug on the client site where we would include the
`regular_category_ids` field when trying to update the notification levels of
categories for a user. The `regulary_category_ids` field should only be
included when the `mute_all_categories_by_default` is enabled
Our dialog service doesn't accept HTML by default and we shouldn't include HTML in the error message string. And given that the Ajax error handler is called in multiple contexts, it's tricky to properly support line breaks via either HTML or `\n` so we are opting for plain text in AJAX error messages.
A callback that's provided as a string, such as `{{action "doSomething"}}`, may target the method `doSomething` on the context OR the context's `action` hash (if it exists).
Classic Ember components (i.e. "@ember/component") rely upon "event
delegation" to listen for events at the application root and then dispatch
those events to any event handlers defined on individual Classic components.
This coordination is handled by Ember's EventDispatcher.
In contrast, Glimmer components (i.e. "@glimmer/component") expect event
listeners to be added to elements using modifiers (such as `{{on "click"}}`).
These event listeners are added directly to DOM elements using
`addEventListener`. There is no need for an event dispatcher.
Issues may arise when using Classic and Glimmer components together, since it
requires reconciling the two event handling approaches. For instance, event
propagation may not work as expected when a Classic component is nested
inside a Glimmer component.
`normalizeEmberEventHandling` helps an application standardize upon the
Glimmer event handling approach by eliminating usage of event delegation and
instead rewiring Classic components to directly use `addEventListener`.
Specifically, it performs the following:
- Invokes `eliminateClassicEventDelegation()` to remove all events associated
with Ember's EventDispatcher to reduce its runtime overhead and ensure that
it is effectively not in use.
- Invokes `rewireClassicComponentEvents(app)` to rewire each Classic
component to add its own event listeners for standard event handlers (e.g.
`click`, `mouseDown`, `submit`, etc.).
- Configures an instance initializer that invokes
`rewireActionModifier(appInstance)` to redefine the `action` modifier with
a substitute that uses `addEventListener`.
Additional changes include:
* d-button: only preventDefault / stopPropagation for handled actions
This allows unhandled events to propagate as expected.
* d-editor: avoid adding duplicate event listener for tests
This extra event listener causes duplicate paste events in tests.
* group-manage-email-settings: Monitor `input` instead of `change` event for checkboxes
This reverts commit 28be5d3037 and fcb4675415
This caused qunit timeouts in our internal CI environments. Not sure of the exact cause yet, but we're reverting for now while we investigate.
Classic Ember components (i.e. "@ember/component") rely upon "event
delegation" to listen for events at the application root and then dispatch
those events to any event handlers defined on individual Classic components.
This coordination is handled by Ember's EventDispatcher.
In contrast, Glimmer components (i.e. "@glimmer/component") expect event
listeners to be added to elements using modifiers (such as `{{on "click"}}`).
These event listeners are added directly to DOM elements using
`addEventListener`. There is no need for an event dispatcher.
Issues may arise when using Classic and Glimmer components together, since it
requires reconciling the two event handling approaches. For instance, event
propagation may not work as expected when a Classic component is nested
inside a Glimmer component.
`normalizeEmberEventHandling` helps an application standardize upon the
Glimmer event handling approach by eliminating usage of event delegation and
instead rewiring Classic components to directly use `addEventListener`.
Specifically, it performs the following:
- Invokes `eliminateClassicEventDelegation()` to remove all events associated
with Ember's EventDispatcher to reduce its runtime overhead and ensure that
it is effectively not in use.
- Invokes `rewireClassicComponentEvents(app)` to rewire each Classic
component to add its own event listeners for standard event handlers (e.g.
`click`, `mouseDown`, `submit`, etc.).
- Configures an instance initializer that invokes
`rewireActionModifier(appInstance)` to redefine the `action` modifier with
a substitute that uses `addEventListener`.
Additional changes include:
* d-button: only preventDefault / stopPropagation for handled actions
This allows unhandled events to propagate as expected.
* d-editor: avoid adding duplicate event listener for tests
This extra event listener causes duplicate paste events in tests.
* group-manage-email-settings: Monitor `input` instead of `change` event for checkboxes
The clientside allowPersonalMessages function introduced
in e62e93f83a sometimes did not
work correctly, because the currentUser.groups property
only contained **visible** groups for the current user, which
could exclude auto groups that had their permissions set to
be owner-only visible.
It was unnecessary to add this anyway since we already have
can_send_private_messages on the CurrentUserSerializer. It's
better the backend does this calculation anyway. Use that
in the clientside code instead and get rid of allowPersonalMessages
Before, `sidebar_list_destination` was an attribute on UserOptionSerializer. The problem was that this attribute was added to user model only when the user entered the preferences panel. We want that attribute to be available all the time, therefore it was moved to CurrentUserSerializer.
Displays a sidebar section link to admin users when
`default_sidebar_categories` site setting has not been configured for the
site.
Internal Ref: /t/73500
On the server side, the only limitation for `Category#color` is a length
limit of 6. Therefore, we cannot assume on the client side that the hex
code is always 6 digits.
If a site has no default sidebar tags configured, show tags section if the user has personal sidebar tags configured.
Otherwise, hide the tags section from the sidebar for the user.
If a site has default sidebar tags configured, always display the tags section.
If a site has no default sidebar categories configured:
* Show categories section if user has categories configured
* Hide categories section if user does not have categories configured
If a site has default sidebar categories configured:
* Always show categories section
Add the ability to modify a selectKit's content with `replaceContent`
Eg.
```
api.modifySelectKit("combo-box").replaceContent(() => {
return {
id: "foo",
name: "Foo",
};
});
```
will override existing content to only include the passed object
