This commit fixes a bug on subfolder setups where the user messages
inbox dropdown will always be blank. This is because we were comparing
URLs using values from `router.currentURL` and `router.urlFor` where
`router.currentURL` does not include `router.rootURL` while
`router.urlFor` does.
Ember's implicit injections feature is removed in Ember 4.x. We want to give ourselves more time to migrate to explicit injections, so this commit re-implements our implicit injections as extensions to the base framework classes.
Incremental migration to newer patterns can be achieved using the `@disableImplicitInjections` class decorator (available from `discourse/lib/implicit-injections').
This resolves and unsilences the `implicit-injections` deprecation.
When navigating with the keyboard, the select-kit would not close when
focus was moved to an element outside of the body. For example, when
navigating via Tab or Shift+Tab, once the end (or beginning) of the list
was reached, focus would move out of the SK element, but the SK itself
would stay visible.
Switching from a click event to a focusout event solves the issue and
covers both mouse and keyboard navigation.
Before this fix if the underlying model of a reviewable was changed, the filter wouldn't work anymore as it was expecting a 1:1 relation between filter type and model name.
This commit also relies on the `Reviewable.types` array to check against valid types instead of a regex not checking much.
Finally this commit adds a spec to ensure chat reviewables are listable from the review index page.
Ran into an issue with these hooks preventing click events on anchors from completing (because the triggered rerender cancels the click). See:
https://github.com/discourse/discourse-header-search/pull/24
This change should have no effect on existing usage of these hooks. Current usage is limited to:
- legacy navigation (should be a no-op)
- reactions plugin (should be a no-op)
- discourse-header-search (will fix the issue!)
* FIX: Empty video thumbnails
This fix ensures that topic video thumbnail generation is completed
before the composer is allowed to submit which should prevent some bugs
around missing thumbnails on video topics.
* move callback to on upload-success
This will automatically adjust when browser UI is shown/hidden (e.g. when scrolling up/down on mobile Safari).
Similar approach to c82094cd9d, which targeted the 'slide-in' version of menus.
Many blog posts use these to illustrate and images were previously omitted
Additionally strip superfluous HTML and BODY tags from embed HTML.
This was incorrectly returned from server.
Followup to c03f83bbea.
The `flair_group_id` parameter is now required to show the flair, and this serializer was missing that detail.
This also fixes a typo in the `include_flair_group_name?` method.
Group user event webhooks filtered by group fail silently
because the `group_ids` job arg wasn't being passed into the job.
This change add's `group_ids` to the `EmitWebHookEvent` jobs queued for
`user_added_to_group` and `user_removed_from_group` events.
User status updates come from the server in a map where keys are user IDs.
If user.trackStatus() is called for a user model without an ID, the model
cannot identify its status updates and silently misses them. It's quite hard to
notice that a user rendered in the UI doesn't receive live status updates.
Also, it's not immediately obvious what's the reason of the problem.
A warning will be very helpful here.
Named outlets are deprecated and will be removed in Ember 4.x.
Backwards-compatibility shims are introduced so that plugin overrides to `controller:composer` are ported to `service:composer`.
After removing `TextareaTextManipulation` from `ChatComposer` and using `TextareaInteractor` as a proxy, one function has been forgotten: `paste(event)` which is not available in glimmer components anymore, and even less avaiable now that the mixin is not tied to a component anymore but a real DOM node. As a solution we now add a manual paste event listener which will call `paste(event)`.
Adds a bit more information to the categories view for crawlers, for better indexing of deep content.
This only works when the "Subcategories with Featured Topics" is the selected layout.
We call the `/u/search/users` URL when autocompleting users. It returns
user's name, username and avatar template, but not user ID.
We need it to return user IDs in order to display user status in certain situations.
I could add ID to FoundUserWithStatusSerializer, so it will be added only if
user status is enabled in site settings. But I feel that it's good to always return it,
it's not a lot of data comparing to what we already return, and it should be useful
in other scenarios.
This pull request is a full overhaul of the chat-composer and contains various improvements to the thread panel. They have been grouped in the same PR as lots of improvements/fixes to the thread panel needed an improved composer. This is meant as a first step.
### New features included in this PR
- A resizable side panel
- A clear dropzone area for uploads
- A simplified design for image uploads, this is only a first step towards more redesign of this area in the future
### Notable fixes in this PR
- Correct placeholder in thread panel
- Allows to edit the last message of a thread with arrow up
- Correctly focus composer when replying to a message
- The reply indicator is added instantly in the channel when starting a thread
- Prevents a large variety of bug where the composer could bug and prevent sending message or would clear your input while it has content
### Technical notes
To achieve this PR, three important changes have been made:
- `<ChatComposer>` has been fully rewritten and is now a glimmer component
- The chat composer now takes a `ChatMessage` as input which can directly be used in other operations, it simplifies a lot of logic as we are always working a with a `ChatMessage`
- `TextareaInteractor` has been created to wrap the existing `TextareaTextManipulation` mixin, it will make future migrations easier and allow us to have a less polluted `<ChatComposer>`
Note ".chat-live-pane" has been renamed ".chat-channel"
Design for upload dropzone is from @chapoi
Due to the order we were parsing markdown, bbcode [url] elements were not
handled properly.
`[url]https://example.com/path[/url]` was not currectly parsing cause
linkify was detecting the url as: `https://example.com/path[/url]` which is
legit.
To resolve this I swapped url to use a replace rule, and instead re-parsed
the internal payload and injected the tokens in.
This fix is complex cause we support stuff like
`[url][b]test.com[/b][/url]`
So we need to parse the content inside url `[b]test.com[/b]`
Currently, only user badge grants emit webhook events. This change
extends the `user_badge` webhook to emit user badge revocation events.
A new `user_badge_revoked` event has been introduced instead of relying
on the existing `user_badge_removed` event. `user_badge_removed` emitted
just the `badge_id` and `user_id` which aren't helpful for generating a
meaningful webhook payload for revoked(deleted) user badges.
The new event emits the user badge object.
* FIX: Blank video thumbnails
On some mobile and possibly other browsers, the automatic video
thumbnail generation would create blank or all white images.
This commit addresses several different issues that was preventing image
generation from working correctly on mobile.
* fix typo
On the client-side, message-bus subscriptions and reviewable count UI is based on the 'redesigned_user_menu_enabled' boolean. We need to use the same logic on the server-side to ensure things work correctly when legacy navigation is used alongside the new user menu.
The value field of ThemeField is only used when viewing a diff in the staff action logs and local theme editing. value is being serialized into the theme index as well, which is not used. It's a huge amount of JSON that we can cut by removing it.
This also breaks up the various theme serializers into separate classes so they autoload properly (or at least restart the server on edit)
When revising a post, if the topic that post belonged to did not have a category attached it would error with
> NoMethodError (undefined method `read_restricted' for nil:NilClass)
The updated user menu is the default for new sites, and will soon be enabled on older sites. This commit removes the 'EXPERIMENTAL' warning from the new `registerUserMenuTab` API, and adds a note to the `addUserMenuGlyph` documentation.
* FIX: Do not overwrite existing thumbnails
When auto generating video thumbnails they should not overwrite any
existing topic thumbnails.
This also addresses an issue with capitalized file extensions like .MOV
that were being excluded.
* Update app/models/post.rb
Remove comment
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
---------
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
Followup to 17ba00c395.
Fix for https://meta.discourse.org/t/-/261917
This fixes a usability issue where the user couldn't switch to the user
menu when the search menu was visible and the text in the input was
selected.
Explanation: The `click` event is triggered both when clicking and when
selecting some text and clicking. This means that when selecting text in
the search input, at the end of the selection event, a click event was
triggered. And if that click event happened to be outside of the search
menu, then the menu would be dismissed.
Previously, we fixed this by checked if a current text selection was
present. But that results in a small side-effect of not switching to
other menus. This PR switches to setting a flag during `mouseDown` and
then using that flag when evaluating whether to trigger clickOutside or
not.
We are seeing issues with the composer not being able to close due to the addition of a error message when rescuing from `Draft::OutOfSequence`. This PR will revert to the original solution implemented prior to https://github.com/discourse/discourse/pull/21148 that just silently rescues from `Draft::OutOfSequence`
This PR adds the ability to destroy reviewables for a passed user via the API. This was not possible before as this action was reserved for reviewables for you created only.
If a user is an admin and calls the `#destroy` action from the API they are able to destroy a reviewable for a passed user. A user can be targeted by passed either their:
- username
- external_id (for SSO)
to the request.
In the case you attempt to destroy a non-personal reviewable and
- You are not an admin
- You do not access the `#destroy` action via the API
you will raise a `Discourse::InvalidAccess` (403) and will not succeed in destroying the reviewable.
Responding to negative behaviour tends to solicit more of the same. Common wisdom states: "don't feed the trolls".
This change codifies that advice by introducing a new nudge when hitting the reply button on a flagged post. It will be shown if either the current user, or two other users (configurable via a site setting) have flagged the post.
This commit fixes the following scenario:
1. The user is searching for hashtags in chat, where the subcategory
type is not highest-ranked in priority order.
2. There can, but doesn't have to be, a higher-ranked matching chat
channel that has the same slug as the subcategory.
3. Since it is not the highest-ranked type, the subcategory, which
normally has a ref of parent:child, has its ref changed to
child::category, which does not work
This was happening because whenever a hashtag type was not highest
ranked, if _any_ other hashtag results conflicted slugs, we would
append the ::type suffix. Now, we only append this suffix if a
higher-ranked type conflicts with the hashtag, and we use the current ref
to build the new typed ref to preserve this parent:child format as well,
it's more accurate.
This PR adds the ability to destroy drafts for a passed user via the API. This was not possible before as this action was reserved for only your personal drafts.
If a user is an admin and calls the `#destroy` action from the API they are able to destroy a draft for a passed user. A user can be targeted by passed either their:
- username
- external_id (for SSO)
to the request.
In the case you attempt to destroy a non-personal draft and
- You are not an admin
- You do not access the `#destroy` action via the API
you will raise a `Discourse::InvalidAccess` (403) and will not succeed in destroying the draft.
It's backward compatible so still supports our 3.28 ember-source.
The visible change is finally getting rid of this message:
```
WARNING: Node v18.12.0 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js. See https://git.io/v7S5n for details.
```
---
`@ember/string` dependency is added for future compatibility. See: https://github.com/ember-cli/ember-cli/pull/10125
---
`tests/helpers/index.js` is unused for now, but is a nice pattern. We could move some of our test setup into local `setupApplicationTest/setupRenderingTest/setupTest` helpers.
Co-authored-by: David Taylor <david@taylorhq.com>
All supported browsers use `transitionend` event now, so this code is not necessary and makes it difficult to use that event in tests (you'd have to trigger all variants to cover the bases)
That function was used only in core (no hits in all-the*) in two places, so I think it's rather safe to just trash it without deprecating it first.
(History Corner – this helper was originally added in the initial commit of Discourse! 1839614bcc/app/assets/javascripts/discourse/components/transition_helper.js.coffee)
* FEATURE: add a setting to allowlist DiscourseConnect return path domains
This commit adds a site setting to allowlist DiscourseConnect return
path domains. The setting needs supports exact domain or wildcard
character (*) to allow for any domain as return path.
* Add more specs to clarify what is allowed in site setting
* Update setting description to explain what is allowed
Following a change in e9f7262813 which prevents the notification level to be returned from the update endpoint, the model couldn't update itself. This commit makes the update manually and adds a test to prevent future regressions.
Note we could also change the backend endpoint, but this should work correctly with minimum risk.
As a single example, if a `<kbd>` tag is wrapped by a `<a>` link, it doesn't inherit the link color:
`[<kbd>❓ **Support**</kbd>](https://meta.discourse.org)`
It's because the `<kbd>` tag has a `color: var(--primary);` CSS rule which seems superfluous.
If we disable it, the `<kbd>` tag inherits all the normal colors (including the link color 👌).
The direct `<kbd>` parent that assigns the text color is `<html>` (can't go higher!) which has an identical `color: var(--primary);`.
WCAG palettes don't seem to assign specific colors in this context.
It seems fairly safe to remove `color: var(--primary);` from `<kbd>` so it won't interfere anymore with its content.
This feature will allow sites to define which emoji are not allowed. Emoji in this list should be excluded from the set we show in the core emoji picker used in the composer for posts when emoji are enabled. And they should not be allowed to be chosen to be added to messages or as reactions in chat.
This feature prevents denied emoji from appearing in the following scenarios:
- topic title and page title
- private messages (topic title and body)
- inserting emojis into a chat
- reacting to chat messages
- using the emoji picker (composer, user status etc)
- using search within emoji picker
It also takes into account the various ways that emojis can be accessed, such as:
- emoji autocomplete suggestions
- emoji favourites (auto populates when adding to emoji deny list for example)
- emoji inline translations
- emoji skintones (ie. for certain hand gestures)
2e78045a fixed the anonymization job so that it correctly updated self-mentions, which are not logged in the post_actions table. The solution was to scan the entire `posts` table with an `raw ILIKE` query. On sites with many posts, this can take a very long time.
This commit updates the job to take a two-pass approach:
First, we update posts based on the post_actions table. This is much more efficient than a full table scan, and takes care of all 'non-self' mentions.
Then, we make a second pass using the `raw ILIKE` approach. Since we already took care of most posts, we can scope this down to self-mentions only. By filtering the query to a specific posts.user_id, it is significantly more performant than a full table scan.
EmberObject's `reopen` feature allows changes to be made to the prototype of the class, but it does not work with native class fields. Native class field values are set on the instance in the constructor, and therefore override any values from the prototype.
This commit implements a workaround which detects possible field overrides and then sets the values during the `init()` function of the EmberObject. This isn't perfect - old field values will still be present while any constructor function is running. But in the vast majority of cases, it should provide parity with old non-native-class EmberObject properties.
This commit also adds a warning when trying to override fields on non-EmberObject classes. There is no change in behavior here - we're just warning about the fact it doesn't work.
When running `yarn install` in a yarn workspace, the lifecycle hooks in the root package.json are not triggered. https://github.com/yarnpkg/yarn/issues/5790
As a workaround, we can additionally run `patch-package` from the `javascripts/discourse/package.json` `postinstall` hook. `patch-package` is idempotent, so it doesn't matter if it is triggered multiple times.
Longer term we intend to move to pnpm, which has built-in patch support.
Currently, we’re performing a check when a user is suspended in the
`UserEmail` job and we’re assuming a `post` is always available, which
is not the case. The code indeed breaks when the job is called with the
`account_suspended` type option.
This patch fixes this issue by making the check use the safe navigation
operator, thus making it working when `post` is not provided.
Previously, Discourse's password hashing was hard-coded to a specific algorithm and parameters. Any changes to the algorithm or parameters would essentially invalidate all existing user passwords.
This commit introduces a new `password_algorithm` column on the `users` table. This persists the algorithm/parameters which were use to generate the hash for a given user. All existing rows in the users table are assumed to be using Discourse's current algorithm/parameters. With this data stored per-user in the database, we'll be able to keep existing passwords working while adjusting the algorithm/parameters for newly hashed passwords.
Passwords which were hashed with an old algorithm will be automatically re-hashed with the new algorithm when the user next logs in.
Values in the `password_algorithm` column are based on the PHC string format (https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md). Discourse's existing algorithm is described by the string `$pbkdf2-sha256$i=64000,l=32$`
To introduce a new algorithm and start using it, make sure it's implemented in the `PasswordHasher` library, then update `User::TARGET_PASSWORD_ALGORITHM`.
Fixes the unnecessary message when starting ember server:
```
Invalid watchman found, version: [2023.04.03.00] did not satisfy [>= 3.0.0].
Visit https://ember-cli.com/user-guide/#watchman for more info.
```
Moves a couple things from discourse-boot.js to a different JS file imported from app/app.js.
This is a forwards compatible technique to import and throw data on the window.
One thing to make note of, though, is that if the virtual-dom and discourse-widget-hbs/helpers were previously included in the build elsewhere, they will now become part of the app bundle.
Later, when using embroider, all bundles will be chunks, and webpack will optimize which chunk contains which modules appropriately.
When selecting the "Keep bookmark" in the user preference for what to do after a bookmark reminder is sent, it does not propagate to the drop-down in the "Create bookmark" modal. Instead it defaults to "Keep bookmark and clear reminder". All other options work fine.
We set a default ("Keep bookmark and clear reminder") if no user preference is found, However, this uses the index of the option, and the index of the first option ("Keep bookmark") is 0, which is treated as falsey in JavaScript, thus causing the default to be selected.
This change switches from logical "or" conditional `||` operator to nullish coalescing `??` operator.
Previously, public custom sections were only visible to logged-in users. In this PR, we are making them visible to anonymous as well.
The reason is that Community Section will be moved into custom section model to be easily editable by admins.
Followup to 6ad9e4ad06,
I was not aware that `site.categories` is undefined if
the user is anon and the site is login_required, this
handles that scenario and does not continue trying to
generate CSS.
This commit adds a system to generate CSS variables and classes for categories
and hashtags, which will be used in an effort to remove baked icons for hashtags
and add color to those icons.
This is in two parts. First I added an initializer generate a category color CSS
variable style tag in the head tag that looks like this:
```css
:root {
--category-1-color: #0088CC;
--category-2-color: #808281;
--category-3-color: #E45735;
--category-4-color: #A461EF;
--category-5-color: #ee56c9;
--category-6-color: #da28c2;
--category-7-color: #ab8b0a;
--category-8-color: #45da37;
...
}
```
The number is the category ID. This only generates CSS variables for categories
the user can access based on `site.categories`. If you need the parent color variable
you can just use the `category.parentCategory.id` to get it.
Then, I added an initializer to generate a hashtag CSS style tag using these variables.
Only the category and channel hashtags need this, the category one generates the
background-gradient needed for the swatch, and the channel just generates a color
for the icon. This is done in an extendable way using the new `api.registerHashtagType`
JS plugin API:
```css
hashtag-color--category-1 {
background: linear-gradient(90deg, var(--category-1-color) 50%, var(--category-1-color) 50%);
}
hashtag-color--category-2 {
background: linear-gradient(90deg, var(--category-2-color) 50%, var(--category-2-color) 50%);
}
hashtag-color--category-5 {
background: linear-gradient(90deg, var(--category-5-color) 50%, var(--category-4-color) 50%);
}
...
.hashtag-color--channel-4 {
color: var(--category-12-color);
}
.hashtag-color--channel-92 {
color: var(--category-24-color);
}
```
Note if a category has a parent, its color is used in the gradient correctly. The numbers
here are again IDs (e.g. channel ID, category ID) and the channel’s chatable ID is used
to find the category color variable.
The status should use the word "user" instead of "flag", for example
"approved user" instead of "approved flag". The problem was caused by
a mismatched type.
Using the `mouseDownOutside` event was problematic here because two
events were being triggered consecutively: `mouseDown`
would toggle the menu off and `click` would then toggle it back on. This
switches the logic to use `clickOutside` again, but with two changes:
- it limits the action to the `search-menu` key (so that theme component
overrides can do their own handling)
- it does not trigger the event when there is an active text selection
(this was the original reason for switching to `mouseDownOutside`, see
https://github.com/discourse/discourse/pull/14788)
The translation key is built using the name of the reviewable as it was
defined in Ruby. The chat plugin uses the `Chat` namespace and defines
`Chat::ReviewableMessage`. This was then transformed to
`chat::reviewable_message`, but it should be `chat_reviewable_message`
to resemble the other translation keys.
This commit adds support for filtering for topics in specific
subcategories via the categories filter query language.
For example: `category:documentation:admins` will filter for topics and
subcategory topics in
the category with slug "admins" whose parent category has the slug
"documentation".
The `=` prefix can also be used such that
`=category:documentation:admins` will exclude subcategory topics of the
category with slug "admins" whose parent category has the slug
"documentation".
Previously, we used the schema type "DiscussionForumPosting" for all the posts including replies. This is not recommended as per Google search experts. This commit changes the schema type to "Comment" for replies.
`Rails.application.routes.recognize_path(value)` was not working for /admin paths because StaffConstraint.new requires user to check permission.
This validation is not bringing much value, and the easiest way is to drop it. In the worse case scenario, a user will have an incorrect link in their sidebar.
Bug reported: https://meta.discourse.org/t/custom-sidebar-sections-being-tested-on-meta/255303/66
Back in d0e1c222f7 we added
performance measuring for uppy uploads using the Performance
API in the browser. However we recently discovered that
sometimes performance.measure can fail if for whatever reason
one of the marks passed to it does not exist:
> Failed to upload ... Performance.measure: Given mark name, upload-uppy-....-create-multipart-success, is unknown
This would cause the entire upload to fail, which is unnecessary
for a debugger. Improve the situation so if this happens again
the error does not stop the upload.
There is no need to validate the user's emails when
promoting/demoting their trust level, this can cause
issues in things like Jobs::Tl3Promotions, we don't
need to fail in that case when all we are doing is changing
trust level.
The following are the changes being introduced in this commit:
1. Instead of mapping the query language to various query params on the
client side, we've decided that the benefits of having a more robust
query language far outweighs the benefits of having a more human readable query params in the URL.
As such, the `/filter` route will just accept a single `q` query param
and the query string will be parsed on the server side.
1. On the `/filter` route, the tags filtering query language is now
supported in the input per the example provided below:
```
tags:bug+feature tagged both bug and feature
tags:bug,feature tagged either bug or feature
-tags:bug+feature excluding topics tagged bug and feature
-tags:bug,feature excluding topics tagged bug or feature
```
The `tags` filter can also be specified multiple
times in the query string like so `tags:bug tags:feature` which will
filter topics that contain both the `bug` tag and `feature` tag. More
complex query like `tags:bug+feature -tags:experimental` will also work.
Previously, reorder on touch screens was disabled https://github.com/discourse/discourse/pull/20769.
This PR enables it again. However, link has to be hold for 300 ms to enable drag&drop. Otherwise, normal scroll is performed.
When user.last_seen was less than push_notification_time_window_mins we
where delaying the notification for the whole
push_notification_time_window_mins PLUS the time the user was away from.
Originally reported in https://meta.discourse.org/t/-/259688
`default_categories_*` site settings will update the category preferences on user creation. But it shouldn't update the user's category preference if a group's setting already updated it for that user.
This corrects two issues:
1. We were double serializing topic tracking state (as_json calls were not cached)
2. We were inefficiently serializing items by instantiating extra objects
We perform lookups on sidebar section links based on sidebar_section_id
totally ignoring user. This ensures we have an index to work with.
This removes the previous index `links_user_id_section_id_position` which
partially doubled up `idx_unique_sidebar_section_links`
As part of another regression, we realized that the plugins tab is visible to moderators, but they cannot interact with anything inside without triggering authorization errors.
This change hides the plugin tab for non-admin users.
When an admin removes all the categories from their personal sidebar configuration, the section should remain visible to them with the “Configure default categories” prompt.
Similar solution for tags.
/t/95036
Instead of being tied to the old implementation and constraints, a
dedicated route and controller for the `discovery.filter` app route will
allow us to iterate on changes much faster.
Before, incorrectly filled fields were marked with red border. Now, additional information under the field is displayed to notify the user what is incorrect.
/t/93696
In some languages, labels on the site settings navigation menu
get truncated. This adds titles to menu items, so users can see
untruncated labels on hover.
Previously we disabled the hamburger reviewable count badge when the redesigned user menu was enabled. This commit updates the logic so that the hamburger reviewable count is tied the legacy navigation mode instead. This ensures that there is always a persistent reviewable count visible. (in the non-legacy navigation modes, the total reviewable count is shown in the sidebar)
In the future we'll be looking at things like tree-shaking and code-splitting. Using 'magic strings' to resolve components is not compatible with those techniques. It makes sense to switch to a more modern pattern now, before the new user-tab API is used too widely.
This commit is backwards-compatible. API consumers which pass a string will see a deprecation message asking them to pass a component class instead.
This commit also turns some unneeded getters into simple class properties (no need to use a getter when it just returns a constant).
This commit turns the new user menu tabs into `<a href` elements. This means that the tab's associated URL is shown on mouseover, and also allows the browser to handle navigation when a modifier key is pressed (e.g. ctrl, shift, mod).
Actions are moved from actions: {} to top-level functions with @action decorator. Previously we had a save() action and a top-level function of the same name, so this commit renames the action to avoid a clash.
