- Count deprecations and print them to the console following QUnit runs
- In GitHub actions, write the same information as a job summary
- Add documentation to `discourse-common/lib/deprecated`
- Introduce `id` and `url` options to `deprecated`
- Introduce `withSilencedDeprecations` helper to allow testing deprecated code paths without making noise in the logs
This was previously reverted in 47035693b7.
* DEV: Add utility to hide all user tips
* DEV: Add UserTip Glimmer component
* DEV: Add tests for existing user tips
* FEATURE: Add user tip for post menu
* FEATURE: Add user tip for topic notification level
* FEATURE: Add user tip for suggested topics
* FEATURE: Hide new popups for existing users
This reverts commit 8c48285145. This introduced a bug which could cause sites to break when certain deprecations are hit. We'll re-introduce a fixed version of this change in a future commit.
* FEATURE: Default Composer Category Site Setting
- Create the default_composer_category site setting
- Replace general_category_id logic for auto selecting the composer
category
- Prevent Uncategorized from being selected if not allowed
- Add default_composer_category option to seeded categories
- Create a migration to populate the default_composer_category site
setting if there is a general_category_id populated
- Added some tests
* Add missing translation for the new site setting
* fix some js tests
* Just check that the header value is null
- Count deprecations and print them to the console following QUnit runs
- In GitHub actions, write the same information as a job summary
- Add documentation to `discourse-common/lib/deprecated`
- Introduce `id` and `url` options to `deprecated`
- Introduce `withSilencedDeprecations` helper to allow testing deprecated code paths without making noise in the logs
Previously `this.chatService.appEvents.on(
"chat:user-tracking-state-changed"...)` was registered on constructor and disabled on `willDestroy`. Constructor is evaluated only once, so when the section was collapsed and collapsed then the events were not observed anymore.
didInsert allows evaluating code each time a component is rendered.
Allows quick inline replies in chat push notifications. This will allow users
in compatible platforms (Windows 10+ / Chrome OS / Android N+) to reply
directly from the notification UI.
Probable follow ups include:
- inline replies for posts
- handling failure of reply
- fallback to draft creation if business logic error
- store and try again later if connectivity error
- sent inline replies lack the in_reply_to param
- i18n of inline reply action text and placeholder
This implementation attempts to be more resilient to background tab.
Notes:
- adds support for immediate arg in @debounce decorators
- fixes a bug in discourseDebounce which was not supporting immediate arg in tests
- chat-audio-manager has no tests as audio requires real user interaction and is hard to test reliably
Connector actions are already added as properties of the generated component, but they were not bound. Using them like `{{on "click" this.someAction"}}` and trying to access `this` would not work as expected. This commit binds all actions to the component generated component instance.
Currently, we have available three 2fa methods:
- Token-Based Authenticators
- Physical Security Keys
- Two-Factor Backup Codes
If the first two are deleted, user lose visibility of their backup codes, which suggests that 2fa is disabled.
However, when they try to authenticate, the account is locked, and they have to ask admin to fix that problem.
This PR is fixing the issue. User still sees backup codes in their panel and can use them to authenticate.
In next PR, I will improve UI to clearly notify the user when 2fa is fully disabled and when it is still active.
- allows to scroll while hovering the menu
- correctly changes message background color while hovering menu
- prevents a bug where it would sometimes close the menu while moving from menu to the 3 dots expanded dropdown. This was caused by the gap between header/body of the 3 dots dropdown, which would sometimes allow to create a mouseover event on a possible different underlying message
- removes recent/favorite reactions on drawer mode
- grayscale reactions until hover
- boxshadow on msgactions container
- removes useless code
This reverts commit 136174e0ee.
That worked only 50% of the time (at best), as it was conflicting with other topic-view scrolling code. The reverted feature will eventually be restored as I continue to fix scroll-related issues.
Our method of loading a subset of client settings into tests via
tests/helpers/site-settings.js can be improved upon. Currently we have a
hardcoded subset of the client settings, which may get out of date and not have
the correct defaults. As well as this plugins do not get their settings into the
tests, so whenever you need a setting from a plugin, even if it has a default,
you have to do needs.setting({ ... }) which is inconvenient.
This commit introduces an ember CLI build step to take the site_settings.yml and
all the plugin settings.yml files, pull out the client settings, and dump them
into a variable in a single JS file we can load in our tests, so we have the
correct selection of settings and default values in our JS tests. It also fixes
many, many tests that were operating under incorrect assumptions or old
settings.
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Even with the `chunkFilename` change, the sourcemaps are non-deterministic because they include references to the broccoli cache directory which has a different name for each build. This commit disables auto-import sourcemaps in production to improve caching performance.
Followup to 3673d3359c
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.
Previously, we didn't have a site-wide setting to set the default behavior for user profile visibility and user presence features. But we already have a user preference for that.
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.
