Normally, arguments passed to components are lazily evaluated. `get prefixElementColors` will only be evaluated for `@prefixType="span"`. However, when using the Ember Inspector in development, arguments are eagerly evaluated and their values displayed in the inspector. Therefore we need to make sure that getters can always be evaluated without exceptions being thrown.
This allows plugins to colocate component JS and HBS under `/plugins/{name}/assets/javascripts/discourse/components`.
`discourse-presence` is updated to use this new pattern, which also serves as an integration test for this part of the build pipeline.
Ember's default resolver only looks for components/services/etc. which are namespaced under the app's `modulePrefix` (`discourse`, in our case). To use addon components/services/etc., the addon must re-export them in its `app/` directory.
In order to support plugins, our custom resolver does a 'suffix match'. This has an unintended side-effect of matching things which are not part of the discourse app or themes/plugins. We've come to rely on this for a few in-repo addons like `select-kit`, `admin` and `wizard`.
This unrestricted 'suffix matching' can cause some very unexpected behaviour. For example, the ember-inspector browser extension has a module called `ember_debug/service/session`. When looking up `service:session`, our resolver was choosing that third-party service over our own Session service. This means Discourse fails to boot when the Ember Inspector is open.
This commit restricts the 'suffix matching' to a known set of namespaces. This brings us one step closer to the default Ember Resolver implementation, and reduces the chance of unexpected behaviour like the ember-inspector issue.
This commit also updates the `dialog-holder` addon to export its service under the app directory, so that we don't need to account for it in the resolver. We may want to consider doing the same for things like `select-kit` and `truth-helpers`, but is beyond the scope of this commit.
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
Tab order acts strangely in Chrome when the last focusable element in a
modal is a radio group: it switches focus to the address bar. This is a
problem, because for keyboard users, it becomes very hard to return to
the previous context.
This PR adds a focusable "Cancel" button, whose mere presence fixes the
issue.
This commit fixes an issue where we had a typo in the
UserAction.stream query which meant that action_code_path
was not loaded correctly. Once that was fixed, we were also
not actually using the action_code_path in the user-stream-item,
so that has been fixed here too.
The bug this caused was that, when the link for the action was
clicked within the user-stream-item, the user would be redirected
to a URL ending with `[missing%20%%7Bpath%7D%20value]` because
the I18n call did not have the path present.
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
