Previously, when categories were not muted by default, we were sending message about unmuted topics (topics which user explicitly set notification level to watching)
The same mechanism can be used to fix a bug. When the user was explicitly watching topic, but category was muted, then the user was not informed about new reply.
The feedback we got here is that the contextual topic list link
behaviour is surprising and people prefer that the topic list sidebar
links always go to a consistent location.
Internal ref: /t/74666/16
This PR enables the [`no-action-modifiers`](https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rule/no-action-modifiers.md) template lint rule and removes all usages of the `{{action}}` modifier in core.
In general, instances of `{{action "x"}}` have been replaced with `{{on "click" (action "x")}}`.
In many cases, such as for `a` elements, we also need to prevent default event handling to avoid unwanted side effects. While the `{{action}}` modifier internally calls `event.preventDefault()`, we need to handle these cases more explicitly. For this purpose, this PR also adds the [ember-event-helpers](https://github.com/buschtoens/ember-event-helpers) dependency so we can use the `prevent-default` handler. For instance:
```
<a href {{on "click" (prevent-default (action "x"))}}>Do X</a>
```
Note that `action` has not in general been refactored away as a helper yet. In general, all event handlers should be methods on the corresponding component and referenced directly (e.g. `{{on "click" this.doSomething}}`). However, the `action` helper is used extensively throughout the codebase and often references methods in the `actions` hash on controllers or routes. Thus this refactor will also be extensive and probably deserves a separate PR.
Note: This work was done to complement #17767 by minimizing the potential impact of the `action` modifier override, which uses private API and arguably should be replaced with an AST transform.
This is a followup to #18333, which had to be reverted because it did not account for the default treatment of modifier keys by the {{action}} modifier.
Commits:
* Enable `no-action-modifiers` template lint rule
* Replace {{action "x"}} with {{on "click" (action "x")}}
* Remove unnecessary action helper usage
* Remove ctl+click tests for user-menu
These tests now break in Chrome when used with addEventListener. As per the comment, they can probably be safely removed.
* Prevent default event handlers to avoid unwanted side effects
Uses `event.preventDefault()` in event handlers to prevent default event handling. This had been done automatically by the `action` modifier, but is not always desirable or necessary.
* Restore UserCardContents#showUser action to avoid regression
By keeping the `showUser` action, we can avoid a breaking change for plugins that rely upon it, while not interfering with the `showUser` argument that's been passed.
* Revert EditCategoryTab#selectTab -> EditCategoryTab#select
Avoid potential breaking change in themes / plugins
* Restore GroupCardContents#showGroup action to avoid regression
By keeping the `showGroup` action, we can avoid a breaking change for plugins that rely upon it, while not interfering with the `showGroup` argument that's been passed.
* Restore SecondFactorAddTotp#showSecondFactorKey action to avoid regression
By keeping the `showSecondFactorKey` action, we can avoid a breaking change for plugins that rely upon it, while not interfering with the `showSecondFactorKey` property that's maintained on the controller.
* Refactor away from `actions` hash in ChooseMessage component
* Modernize EmojiPicker#onCategorySelection usage
* Modernize SearchResultEntry#logClick usage
* Modernize Discovery::Categories#showInserted usage
* Modernize Preferences::Account#resendConfirmationEmail usage
* Modernize MultiSelect::SelectedCategory#onSelectedNameClick usage
* Favor fn over action in SelectedChoice component
* Modernize WizardStep event handlers
* Favor fn over action usage in buttons
* Restore Login#forgotPassword action to avoid possible regression
* Introduce modKeysPressed utility
Returns an array of modifier keys that are pressed during a given `MouseEvent` or `KeyboardEvent`.
* Don't interfere with click events on links with `href` values when modifier keys are pressed
This commit makes pending reviewables show up in the main tab (a.k.a. "all notifications" tab). Pending reviewables along with unread notifications are always shown first and they're sorted based on their creation date (most recent comes first).
The dismiss button currently only shows up if there are unread notifications and it doesn't dismiss pending reviewables. We may follow up with another change soon that allows makes the dismiss button work with reviewables and remove them from the list without taking any action on them.
Follow-up to 079450c9e4.
No tests cause a missing icon regression is not the end of the world and
I don't feel like it will provide enough value as a regression test long
term.
This PR renames the old Sidebar::Section displaySection function
to displaySectionContent, and changes the meaning of displaySection
to hide the entire sidebar section including the header. This is
implemented via an arg passed to Sidebar::Section, which will default
to true if it is not passed, and the BaseCustomSidebarSection class
implements a default of `return true` for this function.
`discovery.category` route respects the default view of the category as
configured by `Category#default_view`. `discovery.latestCategory` forces
the latest filter when viewing the category which is not what we want.
https://meta.discourse.org/t/239999
This PR enables the [`no-action-modifiers`](https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rule/no-action-modifiers.md) template lint rule and removes all usages of the `{{action}}` modifier in core.
In general, instances of `{{action "x"}}` have been replaced with `{{on "click" (action "x")}}`.
In many cases, such as for `a` elements, we also need to prevent default event handling to avoid unwanted side effects. While the `{{action}}` modifier internally calls `event.preventDefault()`, we need to handle these cases more explicitly. For this purpose, this PR also adds the [ember-event-helpers](https://github.com/buschtoens/ember-event-helpers) dependency so we can use the `prevent-default` handler. For instance:
```
<a href {{on "click" (prevent-default (action "x"))}}>Do X</a>
```
Note that `action` has not in general been refactored away as a helper yet. In general, all event handlers should be methods on the corresponding component and referenced directly (e.g. `{{on "click" this.doSomething}}`). However, the `action` helper is used extensively throughout the codebase and often references methods in the `actions` hash on controllers or routes. Thus this refactor will also be extensive and probably deserves a separate PR.
Note: This work was done to complement #17767 by minimizing the potential impact of the `action` modifier override, which uses private API and arguably should be replaced with an AST transform.
Commits:
* Enable `no-action-modifiers` template lint rule
* Replace {{action "x"}} with {{on "click" (action "x")}}
* Remove unnecessary action helper usage
* Remove ctl+click tests for user-menu
These tests now break in Chrome when used with addEventListener. As per the comment, they can probably be safely removed.
* Prevent default event handlers to avoid unwanted side effects
Uses `event.preventDefault()` in event handlers to prevent default event handling. This had been done automatically by the `action` modifier, but is not always desirable or necessary.
* Restore UserCardContents#showUser action to avoid regression
By keeping the `showUser` action, we can avoid a breaking change for plugins that rely upon it, while not interfering with the `showUser` argument that's been passed.
* Revert EditCategoryTab#selectTab -> EditCategoryTab#select
Avoid potential breaking change in themes / plugins
* Restore GroupCardContents#showGroup action to avoid regression
By keeping the `showGroup` action, we can avoid a breaking change for plugins that rely upon it, while not interfering with the `showGroup` argument that's been passed.
* Restore SecondFactorAddTotp#showSecondFactorKey action to avoid regression
By keeping the `showSecondFactorKey` action, we can avoid a breaking change for plugins that rely upon it, while not interfering with the `showSecondFactorKey` property that's maintained on the controller.
* Refactor away from `actions` hash in ChooseMessage component
* Modernize EmojiPicker#onCategorySelection usage
* Modernize SearchResultEntry#logClick usage
* Modernize Discovery::Categories#showInserted usage
* Modernize Preferences::Account#resendConfirmationEmail usage
* Modernize MultiSelect::SelectedCategory#onSelectedNameClick usage
* Favor fn over action in SelectedChoice component
* Modernize WizardStep event handlers
* Favor fn over action usage in buttons
* Restore Login#forgotPassword action to avoid possible regression
* FIX: New general category changes preventing topic create
Follow up to: #18383
The logic in the previous commit was checking for null, but we are
seeding the SiteSetting.general_category_id with an id of -1 so we need
to check for a positive value as well as checking for null.
See: https://meta.discourse.org/t/240661
* Add js test for presence of category… dropdown option
* FEATURE: Make General the default category
* Set general as the default category in the composer model instead
* use semicolon
* Enable allow_uncategorized_topics in create_post spec helper for now
* Check if general_category_id is set
* Enable allow_uncategorized_topics for test env
* Provide an option to the create_post helper to not set allow_uncategorized_topics
* Add tests to check that category… is not present and that General is selected automatically
When a user enters a topic they have already visited they are navigated
to that post that is newest for them (post_number_last_read + 1). Above
that post there is a "last visited" line marker which is visible when
the user scrolls a bit above the post they landed on. This commit makes
sure that the "last visited" line marker is visible as soon as user is
landed in the topic.
A zero-width space character is inserted for icon-only buttons, but that
is unnecessary when the button has some rich-content and the block form
is used.
This commit adds non-archived group messages and `group_message_summary` notifications in the messages tab in the user menu. With this change, the messages tab in the user menu now includes 3 types of items:
1. Unread `private_message` notifications (notifications when you receive a reply in a PM)
2. Unread and read `group_message_summary` notifications (notifications when there's a new message in a group inbox that you track)
3. Non-archived personal and group messages
Unread `private_message` notifications are always shown first, followed by unread `group_message_summary` notifications, and then everything else (messages and read `group_message_summary` notifications) sorted by recency (most recent first).
Internal topic: t/72976.
In a recent commit when adding the review section link, I moved to a
pattern where we allowed the section links to be refreshed after the
section has been constructed. However, we were not tearing down the old
section links when refreshing. This made me realise that refreshing
section links in a section is not a pattern I want to adopt since people
can easily forget to teardown. Instead, each section link should be
responsible for defining a teardown function for cleanup which will
always be called when the sidebar is removed.
Currently, the reviewables tab in the user menu shows pending reviewables at the top of the menu and fills the remaining space in the menu with old/handled reviewables. This PR makes the revieables tab show only pending reviewables and hides the tab altogether from the menu if there are no pending reviewables. We're going to follow-up with another change soon that will show pending reviewables in the main tab of the user menu.
Internal topic: t/73220.
This commit addresses issues around starting new uploads in a composer etc.
when one or more uploads are already processing or uploading.
There were a couple of issues:
1. When all preprocessors were complete, we were not resetting
`completeProcessing` to 0, which meant that `needProcessing`
would never match `completeProcessing` if a new upload was
started.
2. We were relying on the uppy "complete" event which is supposed
to fire when all uploads are complete, but this doesn't seem to take
into account new uploads that are added. Instead now we can rely on
our own `inProgressUploads` tracker, and consider all uploads complete
when there are no `inProgressUploads` in flight
* REFACTOR: Improve reusability by Decoupling flag modal from flag target.
We want chat message's flags to have the same features as topic and posts' flags, but we prefer not having to duplicate core's logic. This PR moves target specific bits to different classes, allowing plugins to flag custom things by
providing their own.
* A couple of fixes for the flag modal:
- Make sure buttons are disabled until a flag type is selected.
- Don't throw an error when checking if the user can undo an action on a deleted topic.
- Disable flagging on deleted topics.
Previously we used `Category#category_excerpt` but the excerpt keeps the
HTML entities around if present and we can't really display HTML in the
title of a link.
This commit introduces an icon to all links in the sidebar. If an icon has not been configured, we will fall back to a generic "link" icon. As part of this commit, we also standardised the size of each prefix to 20px by 20px and set a fix margin. This is to allow sufficient space for text prefixes and image prefixes to be displayed.
Tests have been intentionally left out for now as I don't feel like asserting for the icons will bring much value at this point. Time shall prove me wrong.
Co-authored-by: awesomerobot <kris.aubuchon@discourse.org>
This commit renames all secure_media related settings to secure_uploads_* along with the associated functionality.
This is being done because "media" does not really cover it, we aren't just doing this for images and videos etc. but for all uploads in the site.
Additionally, in future we want to secure more types of uploads, and enable a kind of "mixed mode" where some uploads are secure and some are not, so keeping media in the name is just confusing.
This also keeps compatibility with the `secure-media-uploads` path, and changes new
secure URLs to be `secure-uploads`.
Deprecated settings:
* secure_media -> secure_uploads
* secure_media_allow_embed_images_in_emails -> secure_uploads_allow_embed_images_in_emails
* secure_media_max_email_embed_image_size_kb -> secure_uploads_max_email_embed_image_size_kb
The rationale behind this change is that quote notifications are almost always as important as replies notifications so it makes sense for them to be included in the replies tab instead of the "other" tab. Internal topic: t/74748.
This PR makes adjusted composer height persistent for a user. After dragging to change the composer height, the updated height will be stored in localStorage and will be restored when opening the composer again.
We subscribe to a couple of MessageBus channels when the review-index route is entered, but we should unsubscribe when exiting the route otherwise callbacks would leak every time the review-index is entered and that might cause subtle and weird bugs or errors.
When there are pending reviewables, the review section link is displayed
in the main section. When there are no pending reviewables, the review
section link is displayed under the more links drawer.
Internal ref: /t/74210
* FEATURE: add composer warning when user haven't been seen in a long time
When a user creates a PM and adds a recipient that hasn't been seen in a
long time then we'll now show a warning in composer indicating that the
user hasn't been seen in a long time.
- in group activity, allows avatars to be selectable by tabbing or screen readers
- in user activity > drafts, fixes a bug where for draft replies, the wrong avatar was being shown in the user card
- in both group and user activity, fixes the order of focusable items
* FIX: Better virtual keyboard detect on Android
Firefox has a bug where *sometimes* the visualViewport.height won't be
updated when the keyboard pops up until you scroll, making our composer
stay hidden behind the keyboard. This commit uses both window.innerHeight
and window.visualViewport.height using the minimum of both to check for
height changes.
For Chrome/Edge we feature detect the new VirtualKeyboard API and
opt-into it when the composer opens and use it to detect if a keyboard
is being draw. Opting into the API changes how the viewport is
calculated so we have to also change how the full height composer is
calculated. To minimize breakage we opt-out when the composer component
is destroyed.
This commit also moves the `--composer-ipad-padding` to only happen on
iPads.
Bug report at https://meta.discourse.org/t/-/228382
Although showPopover continues to toggle the popover (showing if hidden / hiding if shown), hidePopover now will only hide the popover. Furthermore, isPopoverShown has been introduced to provide insight into whether the popover is currently shown or not, and therefore whether it should be hidden or shown.
Also, the showPopover / hidePopover test has been refined to override `trigger` and `hideOnClick` settings to allow for full imperative control of showing / hiding the popover.
This will replace `enable_personal_messages` and
`min_trust_to_send_messages`, this commit introduces
the setting `personal_message_enabled_groups`
and uses it in all places that `enable_personal_messages`
and `min_trust_to_send_messages` currently apply.
A migration is included to set `personal_message_enabled_groups`
based on the following rules:
* If `enable_personal_messages` was false, then set
`personal_message_enabled_groups` to `3`, which is
the staff auto group
* If `min_trust_to_send_messages` is not default (1)
and the above condition is false, then set the
`personal_message_enabled_groups` setting to
the appropriate auto group based on the trust level
* Otherwise just set `personal_message_enabled_groups` to
11 which is the TL1 auto group
After follow-up PRs to plugins using these old settings, we will be
able to drop the old settings from core, in the meantime I've added
DEPRECATED notices to their descriptions and added them
to the deprecated site settings list.
This commit also introduces a `_map` shortcut method definition
for all `group_list` site settings, e.g. `SiteSetting.personal_message_enabled_groups`
also has `SiteSetting.personal_message_enabled_groups_map` available,
which automatically splits the setting by `|` and converts it into
an array of integers.
When `allow_uncategorized_topics` is set to `false`, we do not want to
show the uncategorized in sidebar by default.
This commit updates a couple of places in the code related to sidebar
which was incorrectly using `suppress_uncategorized_badge` site setting
which is mainly used for hiding the category badge for uncategorized
category and should not be used to determine if uncategorized categories
should be allowed or not.
This PR makes some updates to the prior keyboard accessibility commit (eb98746):
- Makes `tabindex` attribute only appear on emoji markup in the emoji picker.
- After pressing the Esc key, focus returns to the <textarea/> input (composer editor or chat input)
* DEV: Add test case for syntax highlight of complex HTML
The commit 685e0da upgrade HighlightJS to version 11, which deprecates
syntax highlight of complex HTML elements. See https://github.com/highlightjs/highlight.js/issues/2889
This brought a regression of syntax highlighting of GitHub oneboxes,
which was fixed in 09cec7d. This commit adds a test case to prevent
future regressions like this one.
* fix test and warning
* DEV: Make emoji elements focusable
Since emoji elements are of type `<img>` it requires a `tablindex="0"` in order to be focusable.
* WIP: Handle emoji focus/selection via arrow keys
Near completion, however, need a few fixes/improvements and overall code cleanup
* WIP: Testing
* DEV: Fixes and cleanup
* DEV: Follow conventions
* DEV: Improve up/down traversal when recents present
* DEV: Emoji markup in tests should include `tabindex`
* DEV: Add `tabindex` to topic tests
* DEV: Variable name as `searchInput` instead of `searchBar`
* DEV: Use appropriate method name (`_setNumEmojiPerRow`)
* DEV: Add comments and avoid nested if
* WIP: Adding test
* Fix first test
* DEV: Add assertions for arrow keys and escape key
* Some fixes for up/down navigation
This does not fix everything, when going from one section to another,
there are issues
* Fix a small regression
* FIX: Ability to focus on search results
Fixes regression
* Refactor calculating next up/down emoji
* Debugging test failure
* Skip stubborn CI test, add others
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
This isn't a security bug, because only admins can create user fields
and we have to trust admins, because they can change themes, which are
shown site-wide and can contain unrestricted JS.
Both versions are used with `--headless`, so labelling one "Firefox" and the other "Firefox Headless" doesn't really make sense. Evergreen / ESR are better descriptions.
Using the owner of `site` is not perfectly reliable, especially given that `site` is stubbed in tests. Instead, we can fetch the owner of the `context` object itself.
Also, Ember sets the owner of an EmberObject based on the first parameter to `create`. This is preferable to a separate `setOwner` call because it means the owner is available during initialization.
Unfortunately we don't have any way to compile raw templates inline during tests, so testing this behavior in core is very difficult. Given that we aim to remove the raw handlebars system in the not-too-distant future, it doesn't make sense to invest lots of time on tooling here. Regressions of this behavior will be detected by theme CI tests [like this](https://github.com/discourse/discourse-topic-thumbnails/pull/21).
This commits introduces a new SiteSetting.enable_new_user_profile_nav_groups
feature flag. When configured, users of the configured groups will see
the new user page navigation links.
As of this commit, only the user activity navigation link has been
converted to the newly proposed dropdown of navigation links.
Mobile support has not been considered.
Previously we were calculating both the minimum and maximum widths for
SK dropdowns using this Popper modifier. The max. width calculation was
causing issues with dropdowns in Firefox and was also sluggish when
rendering.
This switches to using CSS calculations for max. widths. It adds a 600px
global maximum and targeted maximums for the category composer dropdown
and the bookmark list dropdowns.
Highlight.js 11 deprecated the feature to highlight HTML blocks while
keeping the HTML structure, which broke our GitHub onebox syntax
highlight.
This patch adds it back by bringing the maintainers code as a plugin.
See https://github.com/highlightjs/highlight.js/issues/2889
This commit includes various accessibility improvements for the new user menu:
* Add `title` attributes to the user menu tabs
* Properly label lists (by adding `aria-labelledby` to `<ul>` elements) for screen readers
* Change the user menu structure so that the tabs come before the content panel in the DOM, but use CSS to reverse them visually.
Normally, changing the order of elements via CSS is bad for accessibility, but I believe this is one of the rare scenarios where it [makes sense](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Ordering_Flex_Items#use_cases_for_order). Prior to this change, if you want to reach the first notification item after you select a tab using the keyboard, you have to hit <kbd>ctrl</kbd>+<kbd>tab</kbd> because the notifications list is before the tabs list. However, with this change, <kbd>tab</kbd> will move you to the first item in the list after you select a tab using your keyboard.
* Aria-hide the unread notifications badge/count on the tabs because the `title` attribute on the tab indicates the unread count.
* Add some tests.
In itself, this change will not cause tests to run in parallel. It just unlocks the ability to use tools like `ember exam` to run tests in parallel. For example:
```
yarn ember exam --load-balance --parallel=3 --random
```
We previously had a system which would generate a 10x10px preview of images and add their URLs in a data-small-upload attribute. The client would then use that as the background-image of the `<img>` element. This works reasonably well on fast connections, but on slower connections it can take a few seconds for the placeholders to appear. The act of loading the placeholders can also break or delay the loading of the 'real' images.
This commit replaces the placeholder logic with a new approach. Instead of a 10x10px preview, we use imagemagick to calculate the average color of an image and store it in the database. The hex color value then added as a `data-dominant-color` attribute on the `<img>` element, and the client can use this as a `background-color` on the element while the real image is loading. That means no extra HTTP request is required, and so the placeholder color can appear instantly.
Dominant color will be calculated:
1. When a new upload is created
2. During a post rebake, if the dominant color is missing from an upload, it will be calculated and stored
3. Every 15 minutes, 25 old upload records are fetched and their dominant color calculated and stored. (part of the existing PeriodicalUpdates job)
Existing posts will continue to use the old 10x10px placeholder system until they are next rebaked
Upgrading to Markdown.it v13 broke empty inline BBCodes. This works around the problem by adding an empty token before a closing token if the previous token was a BBCode token.
It also removes the unused `jump` attribute which was removed in Markdown.it v12.3
The experimental user menu has a tab that displays recent reviewables and at the moment when a new signs up for the site and they need to be approved, admins see a very scary "suspicious user" copy in the reviewables tab in the user menu. We don't need the copy to be very scary because when a user needs to be approved, it's because the site operator has configured the site to force all new users to go through the review queue and it's not some kind of spam detector flagging the user.
The key fix in this commit is that it removes `this.replaceState(path)` for anchor-only URLs. We still intercept those routing changes to properly calculate the scroll position of the anchor via `jumpToElement`, but we no longer use the Ember router to override the browser's history. This fixes the subfolder issue and also lets the browser maintain its history correctly.
The commit also includes a small refactor to the `jumpToElement` helper to facilitate stubbing in tests.
Secure media requests go through the app. In topics with many images, this makes it very easy to hit rate limiters. Skipping the low-res placeholders reduces the chance of this problem occuring.
Reverts #18241 and fixes issues with the original PR:
1. Remove an extraneous `margin-left: auto` from a grid cell (this was causing the buggy behavior in webkit)
2. Add `grid-area` name to `.extra-info-wrapper`
3. Account for `.wrap` padding
4. Remove unused css (`.header-row` and inner styles)
This PR restores a small feature which was present in the old menu and allowed users to click on the active tab in the menu to navigate to some page that showed the same items in the menu but with more details.
For example, if you switch to the PMs tab and then click on it again, currently nothing happens. However, with this change, clicking on the tab again will take you to your messages page at `/my/messages`.
Note: plugins that register custom tabs in the menu can provide a `linkWhenActive` property for their tab if they wish to mimic core's tabs, but it's optional; if they don't provide one, the tab will do nothing if the user clicks on it again.
Internal topic: t/73349.
Because Discourse is a single-page application, clicks on the majority of `<a>` elements in the app need to be intercepted by JavaScript to prevent browsers' default action (full page reload). Links in the user menu - which include notifications, reviewables, bookmarks etc. - are no exception to this rule and currently clicks on these items are handled by the global [click-interceptor](1fa21ed415/app/assets/javascripts/discourse/app/lib/intercept-click.js (L20)) which calls the `preventDefault` function on the click event object and uses the `DiscourseURL.routeTo` function to route the user to the page they request.
However, for links in the user menu, there's an extra step which is to let the header know that it should close the user menu after clicking an item in the menu, but the global interceptor doesn't know that because the step is specific to links in the user menu. This can cause a bug on mobile devices where the menu remains open after clicking on a notification which results in the user having to close the menu to see the page that the notification takes them to.
This commit adds a click handler to user menu items that ensures the menu is closed when an item is clicked and navigates the user to wherever the item links to. There's a small downside to this change which is that user menu items now have their own click interceptor instead of relying on the global interceptor, i.e. duplicated logic, but since it's only a couple of lines, I think we can live with it for a while.
I did try to make the click handler of the user menu items only close the menu (call the `closeUserMenu` function), but for some reasons it caused a full page reload to happen when clicking a notification item due to some weird interactions between the header widget and the user menu. I didn't debug this thoroughly because we have plans to change the header implementation from widgets/virtual-dom to Glimmer component, which will likely resolve that weird full page reload issue and we'll be able to make the click handler just close the menu and let the global interceptor prevents the default action and do the routing.
Internal topic: t/71911/118.
This PR changes the icon for `posted` notification types (these are the notifications that you receive when someone posts in a topic you're watching) from `reply` to `discourse-bell-exclamation`. We're doing this to visually distinguish between the `posted` notifications and `replied` notifications which are the notifications that you receive when someone replies to you directly.
Internal topic: t72835.
In Safari, `img.complete` is sometimes true even before the image is loaded. Checking for the presence of `img.naturalHeight` seems to be more reliable. It is very difficult to write a test for this behaviour due to the dependence on network conditions, scroll location, etc.
`img.naturalHeight` is supported by all our target browsers, and I have verified the functionality of this commit in Chrome, Safari and Firefox.
This updates the ember-cli plugin detection logic to match the logic in `Plugin::Instance.find_all`. It will now ignore plugin directories which do not have a `plugin.rb` file.
This commit adds to the experimental user menu a new "other notifications" tab that's very similar to the "all notifications" tab, but with the main difference being that it doesn't show notification types that do have dedicated tabs in the menu (e.g. mentions, likes, replies etc.).
The rationale behind this is that the notification types that do have dedicated tabs tend to dominate the "all notifications" tab, leaving very small chances for the user to notice rarer or infrequent notification types. Adding a tab for all the other types gives the user a way to review those infrequent notification types.
Internal ticket: t72978.
Co-authored-by: OsamaSayegh <asooomaasoooma90@gmail.com>
We were using the directory name rather than the plugin's defined `name`. This was an unintended change in behaviour from the old sprockets implementation. This commit makes the ember-cli naming logic match the old sprockets logic.
If the server is configured to use a view like `categories_and_latest_topics`, it will preload data for the topic list. If the client doesn't actually use it (e.g. on mobile), then that preloaded data would remain cached and be used for the next loaded topic list. This commit ensures it's always removed, and adds a test for the behaviour.
https://meta.discourse.org/t/237126/35
Previously we were relying on a highly-customized version of the unmaintained Barber gem for theme template compilation. This commit switches us to use our own DiscourseJsProcessor, which makes use of more modern patterns and will be easier to maintain going forward.
In summary:
- Refactors DiscourseJsProcessor to move multiline JS heredocs into a companion `discourse-js-processor.js` file
- Use MiniRacer's `.call` method to avoid manually escaping JS strings
- Move Theme template AST transformers into DiscourseJsProcessor, and formalise interface for extending RawHandlebars AST transformations
- Update Ember template compilation to use a babel-based approach, just like Ember CLI. This gives each template its own ES6 module rather than directly assigning `Ember.TEMPLATES` values
- Improve testing of template compilation (and move some tests from `theme_javascript_compiler_spec.rb` to `discourse_js_processor_spec.rb`
The generate RSA key and import theme routes worked separate from each
other. The RSA key returned both the public and private key and it was
the frontend which posted the private key back to the server. With this
commit, only the public key is necessary as the server keeps a map of
public and private keys that is used to get the private key back from
a public key.
It used to return the next URL anyway which lead to an additional
request. On the frontend, if the result set was empty, it kept retrying
until at least one result was returned. This bug is fixed in this commit
too.
`popupAjaxError` is used by the controller to handle errors when saving the badge model. That only works properly when it gets the original exception from the ajax call. This manipulation of the error in the badge model was breaking that behavior.
The admin-badges controller is the only place which saves this model, so this shouldn't cause any issues elsewhere in the app.
This lets us use all our normal JS tooling like prettier, esline and babel on the splash screen JS. At runtime the JS file is read and inlined into the HTML. This commit also switches us to use a CSP hash rather than a nonce for the splash screen.
* FIX: hide welcome topic banner as soon as the welcome topic is edited
This commit adds a message bus listener on client to hide the welcome
topic banner as soon as the welcome topic is edited.
* update test
* only subscribe when show_welcome_topic_banner is true
* Do not lookup for messageBus service if it's not required
* Remove unneeded code
* Cache result for Site.show_welcome_topic_banner
* Update tests per latest changes
* Changes per PR review
Each new user menu notifications should have their own count. Therefore, we need to include all types to serializer and not only `grouped_unread_high_priority_notifications`
Additional PR will be created for chat and assign plugin, as they will have to switch to `grouped_unread_notifications` as well.
When installing private themes and theme components, the public key does
not show until the administrator types a valid Git repo URL. The regular
expression that checked the URL was too strict and it required the URL
to end with ".git".
In eb12daa7f8 when adding community
section support for anonymous users, we changed the `sectionLinks`
property into a getter method. This meant that if the getter method was
called again after the community section has been rendered, we would end
up reintializing the section links classes. As part of the
initialisation, some section links would setup a TopicTrackingState
onStateChange listener. However, the listener is only removed when the
entire community section is removed which resulted in us leaking the
onStateChange listeners.
This commit reverts the `sectionLinks` from being defined as a getter
method into a property which is only set once when the community section
is being constructor. Also, we changed it such that the community
section will register the listener instead of each section link since it
makes cleaning up much easier to reason about.
No tests have been added for this commit because the original bug is
not possible after this change and we already have an existing tests
ensuring that TopicTrackingState change listeners are cleaned up when
the community section is destroyed.
Internal ref: /t/73224
When you receive a new notification, Discourse prepends a small count `(n)` to the tab title (i.e. `document.title`) if the tab is in the background to alert the user that they have a new notification. The count that's shown in the tab title should reflect the numbers shown on the notification bubbles above the user's avatar. Prior to the experimental user menu, there were 2 bubbles: a blue one which was removed once the user opened the menu and a green one that indicated high priority notifications and it was only removed when the user read all of their high priority notifications.
In the new experimental user menu, we no longer have the green bubble; everything is now combined (including flags/reviewables) into the blue one with no change to its behavior (i.e. it's removed once the user opens the menu). However, the logic that is responsible for updating the tab title hasn't been updated and still updates the tab title to include the count of the old green bubble. This commit updates the logic for the tab title count so that it only reflects the number on the blue bubble when the experimental user menu is enabled.
This commit makes a number of improvements to the DiscourseJsProcessor:
1. Remove dependence on the out-of-date Ember template compiler from the ember-rails gem; switch to modern template compiler
2. Refactor to make use of a proper module system with `define`/`require`
3. Introduce `babel-plugin-ember-template-compilation` to enable inline hbs compilation
The `mini-loader` is upgraded to support relative lookup and `require.has`, so that these new JS packages work correctly.
We were already compiling the markdown bundle via ember-cli, but that version was only being used in the test environment. This commit improves the implementation, and updates the filename so it's also used in production.
This commit also
- Removes the vendored copy of `markdown-it.js` and fetches from node_modules instead
- Updates `pretty_text.rb` to remove the custom sprockets-manifest-parsing
- Removes `pretty-text-bundle.js`, which was only being used by `pretty_text.rb`
This adds a new framework for accessible dialogs that will eventually replace bootbox. Under the hood, it uses the a11y-dialog package and an in-repo Ember addon. See PR for usage details.
The old logic did not make sense and hid the selector from regular users
even if they could tag PMs or showed selector for admins even if they
could not tag PMs.
The preload key was changed in e7a84948b9 but this location was missed. This caused an extra AJAX request and left the cached topic list in the PreloadStore, which would then be accidentally used when navigating to the next topic-list route.
This commit extends the plugin API introduced in 40fd82e2d1 to the `Bookmark` and `Notification` models. It also refactors the code that's responsible for loading items in the experimental menu to use `async`...`await` instead of `Promise`s.
This API allows plugins to transform a list of model objects before they're rendered in the UI. At the moment, this API is limited to items/lists of the experimental user menu, but it may be extended in the future to other parts of the app.
Additional context can be found in https://github.com/discourse/discourse/pull/18046.
The previous sprockets implementation was including admin-specific JS in the plugin's main JS file, which would be served to all users regardless of admin status. This commit achieves the same result under the ember-cli plugin asset compiler with one difference: the admin js is compiled into a separate file. That means that in future, we'll be able to make it loaded only for admins. For now though, it's loaded for everyone, just like before.
When preloading topic_list data we were giving it a 'preload key' which was loosely based on the parameters of the list. However, it did not include all parameters, and mismatches between client/server-side logic would cause the preloaded data to be ignored.
This commit simplifies things by using a single key for all topic_list preloading. This works on the assumption that "The first topic_list the JS app will load is the one which was preloaded". That assumption also existed to some extent in the old design, so we don't expect any regressions here.
Omitting the flag from optional-features enables the runtime deprecation notice.
Also introduces `ember-jquery-legacy` which can be used to migrate to the new behaviour early. Details at https://deprecations.emberjs.com/v3.x/#toc_jquery-event
Core does not appear to make use of `originalEvent` in Ember event handlers. When searching for `originalEvent` there are some matches which relate to our pan-events mixin, but this is our own implementation and not affected by this deprecation.
Plugins often change core behavior, and thereby cause core's tests to fail. In CI, we work around this problem by running core CI without any plugins loaded.
In development, the only option to safely run the core tests is to uninstall all plugins, which is clearly a bad developer experience. This commit aims to improve that experience.
The `qunit_skip_plugins=1` flag would previously prevent the plugin **tests** from running. This commit extends that flag to also affect the plugin's application JS.
Default sidebar tags for not authenticated users can be defined in admin panel. Otherwise, top 5 categories and tags are taken.
Optionally, if categories are set up in permanent order, then the first 5 categories are taken.
`#main` in the test environment is replaced with `#ember-testing`, so this code would break. It never did only because we don't test these code paths 👀
The logic was added in commit ec8306835d,
to show the like action even if the user could not like the post. It is
not necessary for this logic to be implemented on the server side.
* FIX: Do not allow to remove like if topic is archived
* FIX: Always show like button
The like button used to be hidden if the topic was archived and it had
no likes. This commit changes that to always show the like button, but
with a not-allowed cursor if the topic is archived.
When `EMBER_CLI_PLUGIN_ASSETS=1`, plugin application JS will be compiled via Ember CLI. In this mode, the existing `register_asset` API will cause any registered JS files to be made available in `/plugins/{plugin-name}_extra.js`. These 'extra' files will be loaded immediately after the plugin app JS file, so this should not affect functionality.
Plugin compilation in Ember CLI is implemented as an addon, similar to the existing 'admin' addon. We bypass the normal Ember CLI compilation process (which would add the JS to the main app bundle), and reroute the addon Broccoli tree into a separate JS file per-plugin. Previously, Sprockets would add compiled templates directly to `Ember.TEMPLATES`. Under Ember CLI, they are compiled into es6 modules. Some new logic in `discourse-boot.js` takes care of remapping the new module names into the old-style `Ember.TEMPLATES`.
This change has been designed to be a like-for-like replacement of the old plugin compilation system, so we do not expect any breakage. Even so, the environment variable flag will allow us to test this in a range of environments before enabling it by default.
A manual silence implementation is added for the build-time `ember-glimmer.link-to.positional-arguments` deprecation while we work on a better story for plugins.
When there is not enough window width to display the admin menu on the
right, we display it on the left instead. Behavior is reversed on RTL
layout.
This commit also removes jQUery usage.
This commit adds the profile tab to the experimental user menu. We're adding it to the user menu because it contains links/buttons that are not available anywhere else. We may remove the tab again if we find better places for those links/buttons, but for now it'll stay.
For more context on the experimental user menu, see https://github.com/discourse/discourse/pull/17379.
This regressed when we switched these bundles to be compiled by ember-cli. Before/after sizes:
```
before after
admin.js: 1370 KB (190 KB gz) --> 782 KB (125 KB gzipped)
wizard.js: 127 KB ( 22 KB gz) --> 68 KB ( 18 KB gzipped)
```
The logic to determine what post excerpt to show for
a topic-level bookmark based on the last unread post
was complex and slow, so we decided to remove it and
always just use the first post excerpt.
This commit also fixes an issue where a couple of
instances of for_topic were missed when doing the
Bookmarkable refactors, so:
1. Clicking the topic bookmark link was not taking
the user to the last unread post
2. When replying to a topic where there was a topic
level bookmark with the auto delete preference
of "on owner reply", we were not removing the
bookmark from the UI correctly.
A test has been added for the former, the latter would
be quite time-consuming to test and not really worth
it considering it's quite an edge case UI bug.
Ever opened `/tests`, immediately tried to change the config, and got frustrated that focus keeps getting stolen by the running tests? Worry no more - this commit will make the tests auto-abort when you click any of the input/dropdowns in the QUnit header. It's not perfect - abort will wait until the end of the currently running test, so sometimes focus will be stolen one more time. But it's still a lot better than having to manually find and click the abort button.
The following changes are made in this commit:
1. Move caret icon in sidebar section header to the right.
1. Each row in sidebar takes the full width which enables us to do a
full width highlight on hover and when sidebar link is active.
1. Ensure each row in Sidebar is of the same height.
Internal refs: /t/70546, /t/72196, /t/71820
These packages are not published anywhere - they only exist for organizational purposes within this repository. Even so, it makes sense for their metadata to match that of the top-level discourse/discourse repository.
By default, in CI environments, Ember CLI does not output anything between "building..." and "cleaning up". Depending on configuration and hardware, Discourse asset builds can take upwards of 60s, and so this lack of output can make the build feel 'stuck'.
This commit introduces an addon which checks for CI mode, and then outputs status information periodically. The logic is very similar to Ember CLI's non-CI progress output implementation (https://github.com/ember-cli/ember-cli/blob/04a38fda2c/lib/models/builder.js#L183-L185).
Without this filter, a binary file (e.g. `.DS_Store`) in one of these addon directories will be concatenated into the output JS. Note that this filter is applied at the end of the build pipeline, so any hbs files have already been transpiled into `.js`.
This mirrors the filtering performed on the main application bundle by Ember CLI: https://github.com/ember-cli/ember-cli/blob/04a38fda2c/lib/broccoli/default-packager.js#L1255
We can finally rely on template colocation in our app and we'll be
standarizing on that in the near future. However, I want to have sidebar
adopt this convention earlier.
Instead of relying on another help to generate the icons, we want to
rely on the interface for adding prefix icons. This ensures that prefix
icons are consistent across the section links in Sidebar
If a widget toggles between displaying two different RenderGlimmer instances, the Widget framework treats them as the same, and so `update()` is called rather than destroy/init. This commit detects this scenario and manually destroys/inits to ensure the correct component is being rendered.
Before this commit, we carried custom code and styles for the sidebar on
mobile. This meant the look and feel of bringing up the sidebar on
mobile was very different from the user menu resulting in a very
inconsistent experience on mobile. Also, we could not leverage on the
existing swipe to close support on mobile.
In this commit, we made it such that the sidebar dropdown is always
rendered on mobile and made the interaction with the dropdown more
consistent with the user menu. There is also more parity with the old
hamburger dropdown when the experimental sidebar is disabled.
This commit introduces a new `{{on-resize}}` modifier along with its companion `resize-observer` Service. These automatically take care of setting up the observer and handling cleanup.
This commit includes the changes proposed in #17823. I've made these changes so that plugins that need to add tabs/lists with mixed item types - like the bookmarks tab that displays notifications and bookmarks - to the menu, don't have to write 2 templates like we currently do for the bookmarks/messages tabs (see user-menu/bookmark-notification-item.js that has been deleted in this commit).
These are in widespread use, and upgrading themes/plugins right now would break their compatibility with the stable branch. These should be unsilenced for the release of 2.9.0 stable.
Previously, this would require manually adding `?safe_mode=...` multiple times during the email-based login flow. `/u/admin-login` is often used when debugging a site, so it makes sense for this to be easier.
This commit introduces a new checkbox on the `/u/admin-login` screen. When checked, it'll set the safe_mode parameter on the `/email-login` link, and then pass it all the way through to the homepage redirect.
- `no_custom` -> `no_themes` (history: before themes existed, we had a similar tool called 'customizations')
- `only_official` -> `no_unofficial_plugins` (matches format of `no_themes` and `no_plugins`, and makes it clear that this doesn't affect themes)
- `?safe_mode=no_themes%2C%no_plugins` -> `?safe_mode=no_themes,no_plugins` (the query portion of a URL does not require commas to be encoded. This is much nicer to read)
- If `no_plugins` is chosen from `/safe-mode` the URL generated will omit the superfluous `no_unofficial_plugins` flag
- Some tweaks to copy on `/safe-mode`
There was existing logic for this, but it was broken because the values were being run through `encodeURI` before checking its type. This commit takes the opportunity to modernise the function to use `URLSearchParams`, which means we no longer need to handle encoding/joining strings manually.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
This was a temporary solution while we updated the resolver and migrated all our singletons to true ember services. Now that's done, we can switch to use `@glimmer/component` directly, and explicitly inject services as required.
This fix is for the experimental user menu. Some `bookmark_reminder` notifications may not be associated with a topic/post (e.g. bookmark reminder for a chat message) in which case the default notification renderer cannot figure out the `href` for those `bookmark_reminder` notifications. This commit teaches the `bookmark_reminder` notification type renderer to fallback to `bookmarkable_url` that's present in the notification data if the default notification renderer doesn't return a `href` for the notification.
At a certain point, the cost of debugging a flaky acceptance test is
just too high for what we're testing for here. I've decided to just
accept the risk of a minor UX feature.
Follow-up to 55fa94f759
Previously, PM only tags were being routed to the public topic list with
the tag added as a filter. However, the public topic list does not fetch
PMs and hence PM only tags did not provide any value when added to the
Sidebar. This commit changes that by allowing the client to
differentiate PM only tag and thus routes the link to the PM tags show
route.
Counts for PM only tags section links are not supported as of this
commit and will be added in a follow up commit.
1. Replace `{{did-insert` with the builtin `{{on` modifier
2. Move the i18n call into the template
With both of those changes, there is no logic left in the backing class, so we can switch to `templateOnly()` which is significantly faster. (granted, not a big deal for a component like this, but it makes for a good demonstration)
Now that all of our singletons have been converted to true Ember Services, we can remove our custom `discourse/component/glimmer` superclass and use explicit injection
This also updates `section-message` to be a templateOnly glimmer component rather than a classic component.
Now that all of our singletons have been converted to true Ember Services, we can remove our custom `discourse/component/glimmer` superclass and use explicit injection
Now that all of our singletons have been converted to true Ember Services, we can remove our custom `discourse/component/glimmer` superclass and use explicit injection
Makes displaying and hiding the list more deterministic.
```
Error: QUnit Test Failure: Exam Partition 1 - Acceptance: Sidebar - Community Section: clicking on more... link
not ok 491 Firefox 91.0 - [722 ms] - Exam Partition 1 - Acceptance: Sidebar - Community Section: clicking on more... link
---
actual: >
true
expected: >
false
stack: >
@http://localhost:7357/assets/core-tests.js:9826:14
message: >
additional section links are hidden
negative: >
false
browser log: |
```
A public key must be added to GitHub when installing private themes.
When the process happens asynchronously (for example if the admin does
not have admin permissions to the GitHub repository), installing
private themes becomes very difficult.
In this case, the Discourse admin can partially install the theme by
letting Discourse save the private key, create a placeholder theme and
give the admin a public key to be used as a deploy key. After the key
is installed, the admin can finish theme installation by pressing a
button on the theme page.
Some of the changes in this PR are extracted from https://github.com/discourse/discourse/pull/17379.
Similar to the bookmarks tab in the new user menu, the messages tab also displays a mix of notifications and messages. When there are unread message notifications, the tab displays all of these notifications at the top and fills the remaining space in the menu with a list of the user's messages. The bubble/badge count on the messages tab indicates how many unread message notifications there are.
* FEATURE: update bootstrap mode notice to add invite and wizard links
* Updates per feedback on PR
* Fix the wizard link not showing
* Remove unneeded function
* Remove router service injection
The new plugin list is based on the ones currently used in our ember-cli pipeline, and are based on our official browser support policy.
This commit includes an update to the raw-handlebars compiler to remove the 'very hacky but lets us use ES6' code. It's served us well for the last 6 years, but the babel config changes broke it (`const` -> `let`). This commit takes the opportunity to refactor it to take a similar approach to PrettyText, by leaning on `mini-loader.js`.
Some of the changes in this commit are extracted from https://github.com/discourse/discourse/pull/17379.
The bookmarks tab in the new user menu is different from the other tabs in that it can display a mixture of notifications and bookmarks. When there are unread bookmark reminder notifications, the tab displays all of these notifications at the top and fills the remaining space in the menu with the rest of the bookmarks. The bubble/badge count on the bookmarks tab indicates how many unread bookmark reminder notifications there are.
On the technical aspect, since this commit introduces a new `bookmark-item` component, we've done some refactoring so that all 3 "item" components (`notification-item`, `reviewable-item` and the new `bookmark-item`) inherit from a base component and get identical HTML structure so they all look consistent.
Internal tickets: t70584 and t65045.
We use the user-info component in several places, and we want to show status on some of them. If you want status to appear, do this:
{{user-info showStatus=true}}
Currently we can’t add a case-sensitive watched word if another one
exists with a different case. For example, the existing watched word
`Meta` has been created and is case-sensitive. Now an admin tries to add
`metA` while marking it as case-sensitive too, this won’t work and the
word won’t be added.
This patch changes this behavior by allowing to add same words that have
different cases, so the example above will now work as expected.
We still check for uniqueness but case-sensitivy is now taken
into account. It means that if the watched word `meta` already exists
and is not case-sensitive then it will not be possible to add `Meta`
(case-sensitive or not) as `meta` already matches every possible
variations of this word.
Prior to this commit, we had a default Glimmer component that was responsible for handling generic rendering of notifications in the user menu, and many notification types had a custom Glimmer component that inherited from the default component to customize how they were rendered. That implementation was less than ideal because it meant plugins would have to create Glimmer components to customize notification types added by them and that would make the surface area of the API too big.
This commit changes the implementation so there's only one Glimmer component for rendering notifications, and then notification types that need to be customized can create a regular JavaScript class - `renderDirector` in the code - that provides the Glimmer component with the content it should display. We also introduce an API for plugins to register a renderer for a notification type or override an existing one.
Some of the changes are partially extracted from https://github.com/discourse/discourse/pull/17379.
This will allow consumers to inject it using `topicTrackingState: service()` in preparation for the removal of implicit injections in Ember 4.0. `topic-tracking-state:main` is still available and will print a deprecation notice.
Ideally we would convert topic-tracking-state into a true service, rather than registering a model instance into the registry. However, inter-dependencies between service injections make this very difficult to achieve. We don't want to block Glimmer Component work, so this commit does the minimum for now.
When the route of the link is equal to the active route, we promote it
out of the "more..." links drawer and display it directly under the
community section. This commit fixes a bug where the secondary links in
the "more..." links drawer was not being marked as active.
Follow-up to e09fd7cde2
This commit extends the existing API bridge for supporting custom
general links in the old hamburger menu in Sidebar to support custom
footer links. Custom footer links can be added to the old hamburger
menu via the `api.decorateWidget("hamburger-menu:footerLinks")` API.
Footer links are added into the secondary section of the "More..." links
drawer in the Community section of the sidebar.
In the current hamburger menu dropdown, we have a link which allows users to toggle between mobile and desktop view on mobile and touch devices. This commit brings the same behaviour to sidebar.
Follow-up to ce9eec8606.
When the review-index route is entered, we listen to the `/reviewable_counts` (or `/reviewable_counts/<user_id>` when the new user menu is enabled) channel so we can listen for changes to reviewables and update the UI accordingly. However, we currently don't unsubscribe when leaving the route which means each time the route is entered, we setup a new listener causing the browser to do unnecessary work and potentially state leakage.
This will allow consumers to inject it using `site: service()` in preparation for the removal of implicit injections in Ember 4.0. `site:main` is still available and will print a deprecation notice.
Keegan George
Krzysztof Kotlarek
Alan Guo Xiang Tan
Dan Gebhardt
Osama Sayegh
Natalie Tay
Martin Brennan
David Taylor
Andrei Prigorshnev
dependabot[bot]
Blake Erickson
jbrw
Daniel Waterworth
Arpit Jalan
Bianca Nenciu
Frank
Roman Rizzi
Jarek Radosz
Renato Atilio
Penar Musaraj
Rafael dos Santos Silva
Kris
Vinoth Kannan
Gerhard Schlager
Jordan Vidrine
Joffrey JAFFEUX
communiteq
Ghassan Maslamani
Isaac Janzen
Joe
Sérgio Saquetim
Loïc Guitaut
Peter Wagenet
Jean
