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
At some point moved from hljs pure source to their CDN assets, but we
did not change the way we created the HLJS bundle. The CDN asset comes
with their "common" languages already included, so we were duplicating
around 35 languagues in the bundle we create.
This patch includes a list of their current common langs so we never
double bundle those.
Changes in size are significant. Numbers before minimization/compression
are 747.53 KB before and 117.57 KB after.
* 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.
We added `always()` on some steps so that they run even if previous steps fail. That helps give us a picture of all failures in one run, rather than having to re-run the workflow after fixing the first failure.
However, when we explicitly cancel a job, we should skip running these steps. `!cancelled()` is a better substitute for `always()` in this case.
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>
Martin Brennan
Keegan George
Kris
Joshua Rosenfeld
Bianca Nenciu
David Taylor
Ayke Halder
Alan Guo Xiang Tan
dependabot[bot]
Vinoth Kannan
Loïc Guitaut
Rafael dos Santos Silva
Daniel Waterworth
Sergei Mellow
Gerhard Schlager
Jarek Radosz
Penar Musaraj