The test was un-skipped in 6f25f17360 but
has since been flaky again. Removing the test completely as it has
resulted in more pain for us than the value the test provides.
Previously, draft get destroyed accidentally when we switch to PM with the below steps
1. Click “New Topic”
2. Type in the body
3. Switch to “New Message”
4. Click “cancel”
This commit seeks to only handle the `f=tracked` and `filter=tracked`
query params for a topic list. There are other "hidden" filters for a
topic list which can be activated by passing the right query param to
the request. However, they are hidden because there is no way to
activate those filters via the UI. We are handling the `f=tracked`
filter because we will soon be adding a link that allows a user to
quickly view their tracked topics.
Since the default for the bookmark modal is to have no
reminder if you create a bookmark by clicking out of
the modal or pressing the Save button, this commit highlights
None by default.
Also changes the bookmark component to not use @on for Ember
lifecycle, we don't use that style
The commit fcc2e7ebbf to promote
polymorphic bookmarks did not correctly set the username for
the quick access bookmark menu based on the new serializer
values, so the username is not being shown in the bookmark
quick access menu. This commit fixes it, and also adds additional
tests for that menu and updates the user fixtures to reflect
the current state of the bookmarks endpoint.
This commit migrates all bookmarks to be polymorphic (using the
bookmarkable_id and bookmarkable_type) columns. It also deletes
all the old code guarded behind the use_polymorphic_bookmarks setting
and changes that setting to true for all sites and by default for
the sake of plugins.
No data is deleted in the migrations, the old post_id and for_topic
columns for bookmarks will be dropped later on.
While editing a reviewable's tags, the tag chooser did not show the tags
restricted to a specific category. This happened because the tag-chooser
did not pass the categoryId to the server while it was requesting the
list of tags the user can use.
If you happen to mention someone with the wrong capitalization for that
person's username (e.g. `@sAm`), that incorrect capitalization would get
displayed on their user card.
This update will fix that by displaying the `user.username` value, which
will have the correct capitalization.
I also added some tests that will ensure `username` and `name` are
displayed on the user card in the correct order based on the
`prioritize_username_in_ux` setting.
This issue was reported here:
https://meta.discourse.org/t/capitalization-does-not-match-when-you-open-user-cards-using-mentions/217166
There was an edge when a user re-quoted a nested quote that it would return an incorrect `full name` but the correct `username` for the original quote. This PR updates the logic to fall back to using the OP user's username.
The complexity of the changes required to allow for full names to be displayed on nested quotes far outweighs how rare quoting nested quotes is.
This updates the fix in commit eb70ea4.
Co-authored-by: Osama Sayegh <asooomaasoooma90@gmail.com>
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
This PR will include `suspended` attribute in post serializer to check it in post widget and add a CSS class name.
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
The error would happen when emoji_autocomplete_min_chars site setting is set to anything superior to 0, in this case until we reach the min chars length, emojiSearch would return "skip" and the code was currently expecting an array.
Discourse has the Discourse Connect Provider protocol that makes it possible to
use a Discourse instance as an identity provider for external sites. As a
natural extension to this protocol, this PR adds a new feature that makes it
possible to use Discourse as a 2FA provider as well as an identity provider.
The rationale for this change is that it's very difficult to implement 2FA
support in a website and if you have multiple websites that need to have 2FA,
it's unrealistic to build and maintain a separate 2FA implementation for each
one. But with this change, you can piggyback on Discourse to take care of all
the 2FA details for you for as many sites as you wish.
To use Discourse as a 2FA provider, you'll need to follow this guide:
https://meta.discourse.org/t/-/32974. It walks you through what you need to
implement on your end/site and how to configure your Discourse instance. Once
you're done, there is only one additional thing you need to do which is to
include `require_2fa=true` in the payload that you send to Discourse.
When Discourse sees `require_2fa=true`, it'll prompt the user to confirm their
2FA using whatever methods they've enabled (TOTP or security keys), and once
they confirm they'll be redirected back to the return URL you've configured and
the payload will contain `confirmed_2fa=true`. If the user has no 2FA methods
enabled however, the payload will not contain `confirmed_2fa`, but it will
contain `no_2fa_methods=true`.
You'll need to be careful to re-run all the security checks and ensure the user
can still access the resource on your site after they return from Discourse.
This is very important because there's nothing that guarantees the user that
will come back from Discourse after they confirm 2FA is the same user that
you've redirected to Discourse.
Internal ticket: t62183.
After this commit, category group permissions can only be seen by users
that are allowed to manage a category. In the past, we inadvertently
included a category's group permissions settings in `CategoriesController#show`
and `CategoriesController#find_by_slug` endpoints for normal users when
those settings are only a concern to users that can manage a category.
The test was dependent on a translation string. Under certain seeds, the translation string for `{{category-drop}}`'s `noCategoriesLabel` is broken. This is because the value is calculated the first time a `{{category-drop}}` is rendered during the suite. If that first time happens to be during a test which is messing with `I18n.translations`, then it will cache a broken value. Maybe this should be fixed in a future commit... but for now moving to `data-value` will make the `tags-test` more robust and will stop the flakiness.
Moderators don't have access to notifications of other users. So we shouldn't display the notifications tab on other user profiles for them.
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
There are still some, but those are in actual code that's used outside core, so the change there would need to go through the deprecation cycle. That's a task for another day.
Previously we only supported a single 'required tag group' for a category. This commit allows admins to specify multiple required tag groups, each with their own minimum tag count.
A new category_required_tag_groups database table replaces the existing columns on the categories table. Data is automatically migrated.
