See https://meta.discourse.org/t/discourse-email-messages-are-incorrectly-threaded/233499
for thorough reasoning.
This commit changes how we generate Message-IDs and do email
threading for emails sent from Discourse. The main changes are
as follows:
* Introduce an outbound_message_id column on Post that
is either a) filled with a Discourse-generated Message-ID
the first time that post is used for an outbound email
or b) filled with an original Message-ID from an external
mail client or service if the post was created from an
incoming email.
* Change Discourse-generated Message-IDs to be more consistent
and static, in the format `discourse/post/:post_id@:host`
* Do not send References or In-Reply-To headers for emails sent
for the OP of topics.
* Make sure that In-Reply-To is filled with either a) the OP's
Message-ID if the post is not a direct reply or b) the parent
post's Message-ID
* Make sure that In-Reply-To has all referenced post's Message-IDs
* Make sure that References is filled with a chain of Message-IDs
from the OP down to the parent post of the new post.
We also are keeping X-Discourse-Post-Id and X-Discourse-Topic-Id,
headers that we previously removed, for easier visual debugging
of outbound emails.
Finally, we backfill the `outbound_message_id` for posts that have
a linked `IncomingEmail` record, using the `message_id` of that record.
We do not need to do that for posts that don't have an incoming email
since they are backfilled at runtime if `outbound_message_id` is missing.
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).
The `add_column` `limit` parameter has no effect on a postgres `text` column. Instead we can perform the check in ActiveRecord.
We never expect this condition to be hit - users cannot control this value. It's just a safety net.
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.
Adds limits to location and website fields at model and DB level
to match the bio_raw field limits. A limit cannot be added at the
DB level for bio_raw because it is a postgres text field.
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
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.
Martin Brennan
Keegan George
Kris
David Taylor
Ayke Halder
Alan Guo Xiang Tan
Vinoth Kannan
Loïc Guitaut
dependabot[bot]
Rafael dos Santos Silva
Daniel Waterworth
Jarek Radosz
Penar Musaraj
Osama Sayegh
Andrei Prigorshnev
Gerhard Schlager
Jordan Vidrine