Commit Graph

9 Commits

Author SHA1 Message Date
Penar Musaraj
b8ee52c4cb
UX: Wait for render before invoking A11YDialog (#24100)
Previously, focus wasn't being applied correctly on dialogs using named
components. This was because the A11YDialog was being invoked before
the component was completely rendered.

The long-term plan is to move away from A11YDialog doing the rendering
here, but for now this should do.
2023-10-26 08:24:47 -04:00
David Taylor
25ddbd1aa6
DEV: Convert remaining core services to native class syntax (#23756) 2023-10-18 12:28:56 +01:00
David Taylor
48193767bf DEV: Sort imports
Automatically generated by `eslint --fix` to satisfy the updated configuration
2023-10-10 21:46:54 +01:00
Jarek Radosz
1c87bb7fe9
DEV: Update DButton uses (#23333)
1. Use `this.` instead of `{{action}}` where applicable
2. Use `{{fn}}` instead of `@actionParam` where applicable
3. Use non-`@` versions of class/type/tabindex/aria-controls/aria-expanded
4. Remove `btn` class (it's added automatically to all DButtons)
5. Remove `type="button"` (it's the default)
6. Use `concat-class` helper
2023-08-31 11:49:35 +02:00
David Taylor
ed2dae6d1a
FIX: Ensure dialogs are still rendered if triggered during boot (#22511)
When the loading slider is enabled, the rendering of `application.hbs` is slightly delayed compared to the old 'spinner' strategy. This means that if a route tried to render a dialog during its `model()` hook, the dialog wrapper element would not be present and an error would occur.

This commit detects that situation and delays rendering the error until the next runloop iteration. If the element is still not found, we print a useful error to the console.

In the long term, we should ideally convert the dialog service to use a pure-ember rendering strategy instead of leaning on a11y-dialog. But for now, this workaround should resolve the problems identified by the chat system specs.
2023-07-10 11:29:04 +01:00
Penar Musaraj
4072786f5b
DEV: Support using Ember components in dialog service (#20230)
We often have the need to use rich HTML in dialog messages (to show lists, icons, etc.). Previously, our only option was to wrap the message in an `htmlSafe()` call. This PR adds the ability to pass a component name and model to the dialog, which means that we can write the HTML in regular Ember components. 

Example, whereas previously we would do this: 

```
    this.dialog.deleteConfirm({
      message: htmlSafe(`<li>Some text</li>`),
    });
```

instead we can now do this: 

```javascript
import SecondFactorConfirmPhrase from "discourse/components/dialog-messages/second-factor-confirm-phrase";

...

this.dialog.deleteConfirm({
  title: I18n.t("user.second_factor.disable_confirm"),
  bodyComponent: SecondFactorConfirmPhrase,
  bodyComponentModel: model,
})
```

The model passed to the component is optional and will be available as `@model` in the Handlebars template.
2023-02-13 13:03:31 -05:00
David Taylor
c8e2e37fa7 DEV: Apply prettier to hbs files 2022-12-28 13:11:12 +00:00
Krzysztof Kotlarek
e313190fdb
FEATURE: better UI to manage 2fa (#19338)
In this PR, we introduced an option, that when all authenticators are disabled, but backup codes still exists, user can authenticate with those backup codes. This was reverted as this is not expected behavior.

https://github.com/discourse/discourse/pull/18982

Instead, when the last authenticator is deleted, backup codes should be deleted as well. Because this disables 2fa, user is asked to confirm that action by typing text.

In addition, UI for 2fa preferences was refreshed.
2022-12-08 09:41:22 +11:00
Jarek Radosz
99dfdf70e8
DEV: Make dialog-holder a monorepo package (#19051) 2022-11-16 16:43:45 +01:00