This commit automatically ensures that category channels
have slugs when they are created or updated based on the
channel name, category name, or existing slug. The behaviour
has been copied from the Category model.
We also include a backfill here with a simplified version
of Slug.for with deduplication to fill the slugs for already
created Category chat channels.
The channel slug is also now used for chat notifications,
and for the UI and navigation for chat. `slugifyChannel`
is still used, but now does the following fallback:
* Uses channel.slug if it is present
* Uses channel.escapedTitle if it is present
* Uses channel.title if it is present
In future we may want to remove this altogether
and always rely on the slug being present, but this
is currently not possible because we are not generating
slugs for DM channels at this point.
* Remove old bookmark column ignores to follow up b22450c7a8
* Change some group site setting checks to use the _map helper
* Remove old secure_media helper stub for chat
* Change attr_accessor to attr_reader for preloaded_custom_fields to follow up 70af45055a
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.
It is likely that a new admin user was created as just a regular user
before being promoted to admin so this change will update the sidebar
link records for any users that are promoted to admin. This way if any
of the default side bar categories or tags are restricted to admins
these new admins will have those added to their sidebar as well.
You can easily replicate this issue locally (prior to this fix) by using
`rails admin:create` where it creates a user first, then it is promoted
to admin. This means it would receive the default categories of regular
user, but never receive the ones they should have access to as an admin.
As part of this change I did drop the `!` from
`SidebarSectionLink.insert_all` so that it would add any new records
that were missing, but not throw a unique constraint error trying to add
any existing records.
Follow up to: 1b56a55f50
And: e320bbe513
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.
Meta topic: https://meta.discourse.org/t/meta-theme-color-is-not-respecting-current-color-scheme/239815
Currently, the dark mode theme-color `<meta>` tag doesn't apply because the light mode tag has `media="all"`. This means that the dark mode `<meta>` tag with `media="(prefers-color-scheme: dark)"` won't override it. This PR updates the light mode tag to `media="(prefers-color-scheme: light)"` if `dark_scheme_id` is defined and leaves it as `media="all"` otherwise.
Since the system user is a regular user, it can have its
`allow_private_messages` user option turned off, which
with our current `can_send_private_message?(Discourse.system_user)`
check inside the CurrentUserSerializer, will prevent any
user from sending messages in the UI if the system user is not
accepting PMs.
This commit adds a new `can_send_private_messages?` method to
the Guardian, which can be used in serializers and not depend
on the system user. When the user actually sends a message
we still rely on the old `can_send_private_message?(target)`
call to see if they are allowed to send the message to the target.
The new method is just to say they can "generally" send
private messages.
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
* DEV: Add a dedicated Admin::StaffController base controller
The current parent(Admin:AdminController) for all admin-related controllers
uses a filter that allows only staff(admin, moderator) users.
This refactor makes Admin::AdminController filter for only admins as the name suggests and
introduces a base controller dedicated for staff-related endpoints.
* DEV: Set staff-only controllers parent to Admin::StaffController
Refactor staff-only controllers to inherit newly introduced
Admin::StaffController abstract controller. This conveys the
purpose of the parent controller better unlike the previously used parent
controller.
* FIX: Follow up fixes for password-reset error page
Pass in `base_url` to the template
Use `.html_safe` since the message now contains html
Follow up to: 9b1536fb83
* Update specs to pass in the base_url
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.
This commit fixes a regression introduced in 8979adc where under certain conditions the groups syncing logic in Discourse Connect would try to add users to groups they're already members of and cause errors when users try to sign in using Discourse Connect.
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).
Having the group name in the `class` attribute can cause a clash with 'real' CSS classes. Putting it in a data attribute is much safer, and can still be targetted via CSS if desired.
Before this commit, we did not have guardian checks in place to determine if a
topic's title associated with a user badge should be displayed or not.
This means that the topic title of topics with restricted access
could be leaked to anon and users without access if certain conditions
are met. While we will not specify the conditions required, we have internally
assessed that the odds of meeting such conditions are low.
With this commit, we will now apply a guardian check to ensure that the
current user is able to see a topic before the topic's title is included
in the serialized object of a `UserBadge`.
The previous sidebar default tags and categories implementation did not
allow for a user to configure their sidebar to have no categories or
tags. This commit changes how the defaults are applied. When a user is being created,
we create the SidebarSectionLink records based on the `default_sidebar_categories` and
`default_sidebar_tags` site settings. SidebarSectionLink records are
only created for categories and tags which the user has visibility on at
the point of user creation.
With this change, we're also adding the ability for admins to apply
changes to the `default_sidebar_categories` and `default_sidebar_tags`
site settings historically when changing their site setting. When a new
category/tag has been added to the default, the new category/tag will be
added to the sidebar for all users if the admin elects to apply the changes historically.
Like wise when a tag/category is removed, the tag/category will be
removed from the sidebar for all users if the admin elects to apply the
changes historically.
Internal Ref: /t/73500
Before this commit, there was no way for us to efficiently check an
array of topics for which a user can see. Therefore, this commit
introduces the `TopicGuardian#can_see_topic_ids` method which accepts an
array of `Topic#id`s and filters out the ids which the user is not
allowed to see. The `TopicGuardian#can_see_topic_ids` method is meant to
maintain feature parity with `TopicGuardian#can_see_topic?` at all
times so a consistency check has been added in our tests to ensure that
`TopicGuardian#can_see_topic_ids` returns the same result as
`TopicGuardian#can_see_topic?`. In the near future, the plan is for us
to switch to `TopicGuardian#can_see_topic_ids` completely but I'm not
doing that in this commit as we have to be careful with the performance
impact of such a change.
This method is currently not being used in the current commit but will
be relied on in a subsequent commit.
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
Meta topic: https://meta.discourse.org/t/meta-theme-color-is-not-respecting-current-color-scheme/239815/7?u=osama.
This commit renders an additional `theme-color` `<meta>` tag for the dark scheme if the current user/request has a scheme selected for dark mode. We currently only render one `theme-color` tag which is always based on the user's selected scheme for light mode, but if the user also selects a scheme for dark mode and uses a device that's configured to use/prefer dark mode, the Discourse UI will be in dark mode, but any parts of the browser/OS UI that's colored based on the `theme-color` tag, would use a color from the user's selected light scheme and look inconsistent with the Discourse UI because the `theme-color` tag is based on the user's selected light scheme.
The additional `theme-color` tag has `media="(prefers-color-scheme: dark)"` and is based on the user's selected dark scheme which means any browser UI that's colored based on `theme-color` tags should be able to pick the right tag based on the user's preference for light/dark mode.
If there's an error loading a topic, and later you load it successfully - the the stale error message would still briefly show up every time you navigate to that topic
Related to aeee7ed.
Before the change in aeee7ed, notifications for direct replies to your posts and notifications for replies in watched topics looked the same in the notifications menu -- they both used the arrow icon.
We decided in aeee7ed to distinguish them by changing "watched topics" notifications to use the bell icon because it was confusing for users who watch topics to see the same icon for direct replies and "watched topics". However, that change also means that non-power/new users who receive replies to topics _they create_ will get notifications with the bell icon because technically they're watching the topic, but the arrow icon is more appropriate for this case because we use it throughout the app to indicate "replies".
This commit adds a special-case so that if a user is watching a topic AND the topic is created by them, they receive notifications with the arrow icon (type `replied`) instead of the bell icon (type `posted`) for new posts in the topic.
Internal topic: t/79051.
Discourse Connect can be used to manage group memberships of users by including a `add_groups`, `remove_groups` or `groups` attribute in the Discourse Connect payload. However, additions/deletions of users from groups aren't logged to the groups logs (available at `/g/<group>/manage/logs`) which can cause confusions to admins they try to figure out when/how users were added or removed from a group. This commit makes Discourse Connect add entries to the groups logs when it makes changes to users' group memberships.
Adds sorting for the HashtagAutocompleteService to
sort the results by case-insensitive text _within_
the type sort order specified by the params. This
should fix some flaky specs as well.
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.
In test mode we reinitialize the Application for every test. We only want to apply the class reopens once to avoid performance regressions and memory leaks in the test suite.
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 complex regex-based detection was based on Ember CLI's implementation, which is necessarily generic and needs to auto-detect the name. In our case, we know the name of the plugin so we can just pass it in - no need for dynamic detection. This resolves issues when there are other files in the `discourse/plugins/{name}` directory which are sorted before `discourse/`
Lone hbs files in the `/components` are automatically assumed to be template-only Glimmer components. The `templateOnly()` stub is only required when templates are in the `/templates/components` directory.
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
Given that the category structure is generally speaking the backbone of most Discourse instances, it makes sense to show the edit button for the category even when the user is in a category/tag intersection route.
Debouncing inline anonymous functions does not work.
This fixes all instances of that error by extracting the function or using the new `@debounce(delay)` decorator
Our theme system injects a magical `settings` object at the top of themes JS modules to allow theme authors to access the settings as configured by admins in the UI. Within this `settings` object, there are a couple of special objects `theme_uploads` and `theme_uploads_local` that contain URLs for all the assets/uploads that the theme has.
For test modules/files, the theme system also injects a `settings` object at the top of tests modules, but it's not the same object as the object that's injected in non-test files. The difference is that in tests we want the settings to have their default values as opposed to any custom values that may exist in the site's database. This ensures that test results are consistent no matter the site that runs them.
However, the `settings` object in tests files currently doesn't have the special objects `theme_uploads` and `theme_uploads_local` which means that if a theme includes an asset that's lazy-loaded, it's not possible to write tests for anything that depends on the lazy-loaded asset because the theme will not be able to load the asset during the tests since `theme_uploads_local` and `theme_uploads` don't exist. This PR adds these special objects inside the `settings` object for test files.
Internal topic: t/71825/52.
Multiple things in the app need the height of the header to be correct (for example, scrolling to a post), so we need the header offset calculation. However, we shouldn't be calculating it on scroll, it's too resource intensive and it causes flickering on iPads (and possible other devices too).
This commit removes header offset calculation on scroll and adds a one-time calculation as soon as the header is first rendered. This ensures that users get scrolled to the correct post even if they open it in a new tab.
This commit adds a new `/hashtag/search` endpoint and both
relevant JS and ruby plugin APIs to handle plugins adding their
own data sources and priority orders for types of things to search
when `#` is pressed.
A `context` param is added to `setupHashtagAutocomplete` which
a corresponding chat PR https://github.com/discourse/discourse-chat/pull/1302
will now use.
The UI calls `registerHashtagSearchParam` for each context that will
require a `#` search (e.g. the topic composer), for each type of record that
the context needs to search for, as well as a priority order for that type. Core
uses this call to add the `category` and `tag` data sources to the topic composer.
The `register_hashtag_data_source` ruby plugin API call is for plugins to
add a new data source for the hashtag searching endpoint, e.g. discourse-chat
may add a `channel` data source.
This functionality is hidden behind the `enable_experimental_hashtag_autocomplete`
flag, except for the change to `setupHashtagAutocomplete` since only core and
discourse-chat are using that function. Note this PR does **not** include required
changes for hashtag lookup or new styling.
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.
This commit excludes posts from hidden topics from the latest posts and user activity RSS feeds. Additionally, it also excludes small actions from the first one.
This view can show multiple posts from the same topic and the aria labels
will now include the post number to more easily differentiate posts in
screen readers.
Theme javascript is now minified using Terser, just like our core/plugin JS bundles. This reduces the amount of data sent over the network.
This commit also introduces sourcemaps for theme JS. Browser developer tools will now be able show each source file separately when browsing, and also in backtraces.
For theme test JS, the sourcemap is inlined for simplicity. Network load is not a concern for tests.
Previously, compiling theme 'extra_js' was done with a number of steps. Each theme_field would be compiled into its own value_baked column, and then the JavascriptCache content would be built by concatenating all of those compiled values.
This commit streamlines things by removing the value_baked step. The raw value of all extra_js theme_fields are passed directly to the ThemeJavascriptCompiler, and then the result is stored in the JavascriptCache.
In itself, this commit should not cause any behavior change. It is designed to open the door to more advanced compilation features which have interdependencies between different source files (e.g. template colocation, sourcemaps).
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
* FIX: Reset related site settings on general category delete
If the new seeded General category is deleted we also need to delete the
corresponding site setting for it so that we don't try and reference it.
This fixes a bug in the category dropdown composer.
This change creates the `clear_related_site_settings` after destroy
hook that could also be used by other features in the future, like maybe
when we have a `default_category_id` site_setting.
Looks like if `nil` out a site setting it is set to `0`?
```
[9] pry(main)> SiteSetting.general_category_id = nil
SiteSetting Load (0.4ms) SELECT "site_settings".* FROM "site_settings" WHERE "site_settings"."name" = 'general_category_id' LIMIT 1
=> nil
[10] pry(main)> SiteSetting.general_category_id
=> 0
```
That is why the tests check if the value is `< 1` and not `nil`.
* Use -1 instead of nil because it is the default
This commit introduces a new framework for building user tutorials as
popups using the Tippy JS library. Currently, the new framework is used
to replace the old notification spotlight and tips and show a new one
related to the topic timeline.
All popups follow the same structure and have a title, a description and
two buttons for either dismissing just the current tip or all of them
at once.
The state of all seen popups is stored in a user option. Updating
skip_new_user_tips will automatically update the list of seen popups
accordingly.
This commit merges the mentions and "watching" tabs into the replies tab of the user menu. This change is kind of experimental, so we may change it back either fully or partially. Internal topic: t/76474.
