This change is intended to be backwards-compatible with all the previous arguments to `DButton`.
A deprecation warning will be triggered when a string is passed to the `@action` argument. This kind of action bubbling has been deprecated in Ember for some time, and should be updated to use closure actions.
Co-authored-by: Dan Gebhardt <dan@cerebris.com>
Co-authored-by: David Taylor <david@taylorhq.com>
When opening the invite acceptance page when the user
was already logged in, we were still showing the Accept
Invitation prompt even if the user had already redeemed
the invitation and was present in the `InvitedUser` table.
This would lead to errors when the user clicked on the button.
This commit fixes the issue by hiding the Accept Invitation
button and showing an error message instead indicating that
the user had already redeemed the invitation. This only applies
to multi-use invite links.
* FIX: Update user options only once
Performing actions that updated list of seen popups used to update user
options everytime instead of checking if the change has any effect.
* FIX: Load updated user data from response
node-fetch is now a ES module, so it has to either imported with `import/from` syntax (which can't be used in addon's index.js) or using the dynamic `import()`
Previously we were trying to handle both async and sync use cases in a single function, but it was confusing to read and led to subtle race conditions. This commit separates the async version into a separate function.
Previously we had a combination of a computed property and `this.set`. This was triggering the `computed-property.override` deprecation. This commit moves everything into the `dir` property, makes it a native getter, and adds a test to verify the reactive behavior.
Some locations in the app were `.set`-ing these computed properties. This would trigger the `computed-property.override` Ember deprecation, and also lead to inconsistency between the `..._categories_ids` property and the `...Categories` property.
This commit updates these properties to have getters/setters, with all state being stored in the `..._ids` property. The `@dependentKeyCompat` decorator is used to ensure these 'autotracking' getters can still be used as dependent keys in other computed properties.
- 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.
Passing a string action name to `DButton` causes it to use `sendAction`, which is deprecated and will be removed in Ember 4.x. The action helper converts a string to a closure action.
This also fixes compatibility with https://github.com/discourse/discourse/pull/17767
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.
Previously these were set to expire after 9999 days (27 years). This commit updates them to last 1 year, and to automatically be extended on every user visit.
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
