We must set `treatAsTextarea` to true when using autocomplete
in the chat composer, since it is at the bottom of the screen
we always want to show it above the composer. This fixes the
issue where the hashtag autocomplete results went behind the
keyboard on mobile (which was not happening for mentions).
Currently, we check if the site is loaded over `https` before
registering the service worker. This prevents the service worker from
being registered in a standard dev/test setup.
This change replaces the protocol check with `isSecureContext`
property check.
In addition to resources delivered over `https`, `isSecureContext`
returns `true` for resources loaded over `http://127.0.0.1`, `http://localhost`,
`http://*.localhost` and `file://`.
Use the `Discourse.base_path` when linking to hard coded images used in
the UI so that the correct subfolder path is used if present.
Follow up: 5c67b073ae
* FIX: broken emoji url on password reset w/ subfolder
* Use Discourse.base_path to account for subfolder
I do like where you are going with using Emoji.url_for but due to the
lack of svg support currently I think we need to use the current svg
file we have. The emoji png files we have render too blurry at high
resolution.
This commit uses the `Discourse.base_path` so that a subfolder install
will have the correct image path.
I do think in the future we should do some work around using a helper
similar to Emoji.url_for with svg support so that we better standardize
our use of these emojis.
Co-authored-by: Blake Erickson <o.blakeerickson@gmail.com>
A translator noted that this string is odd: "We'll email you immediately
if you haven't read the thing we're emailing you about." We show this
note in the user profile when the user has chosen to be emailed "only
when away" and the site has `email_time_window_mins` off. The message
essentially says that "only when away" in this particular site's config
means "Always".
I think it is best to show no description here. In an ideal world, the
"Only when away" option shouldn't be there when `email_time_window_mins`
is off. But it is rare to choose that override, and adding proper support
for that use case would be complicated.
* FIX: Use Category.secured(guardian) for hashtag datasource
Follow up to comments in #19219, changing the category
hashtag datasource to use Category.secured(guardian) instead
of Site.new(guardian).categories here since the latter does
more work for not much benefit, and the query time is the
same. Also eliminates some Hash -> Model back and forth
busywork. Add some more specs too.
* FIX: Server-side hashtag lookup cooking user loading
When we were using the PrettyText.options.currentUser
and parsing back and forth with JSON for the hashtag
lookups server-side, we had a bug where the user's
secure categories were not loaded since we never actually
loaded a User model from the database, only parsed it
from JSON.
This commit fixes the issue by instead using the
PretyText.options.userId and looking up the user directly
from the database when calling hashtag_lookup via the
PrettyText::Helpers code when cooking server-side. Added
the missing spec to check for this as well.
* FEATURE: Show similar users when penalizing a user
Moderators will be notified if other users with the same IP address
exist before penalizing a user.
* FEATURE: Allow staff to penalize multiple users
This allows staff members to suspend or silence multiple users belonging
to the same person.
If configured, this will be used for static JS assets which are stored on S3. This can be useful if you want to use different CDN providers/configuration for Uploads and JS
This commit allows us to type # in the UI and present autocomplete
results immediately with the following logic for the topic composer,
and reversed for the chat composer:
* Categories the user can access and has not muted sorted by `topic_count`
* Tags the user can access and has not muted sorted by `topic_count`
* Chat channels the user is a member of sorted by `messages_count`
So in effect, we allow searching for hashtags without a search term.
To do this we add a new `search_without_term` to each data source so
each one can define how it wants to handle this logic.
This new site setting replaces the
`enable_experimental_sidebar_hamburger` and `enable_sidebar` site
settings as the sidebar feature exits the experimental phase.
Note that we're replacing this without depreciation since the previous
site setting was considered experimental.
Internal Ref: /t/86563
This prevents long inbox names from causing issues in the dropdown on /my/messages and tries a new mobile layout that makes better use of the available space:
When looking up hashtags which were conflicting (e.g.
management::tag and management) where the user did
not have permission for one of them, we ended up returning
the one they did have permission to (e.g. the tag) twice
because of the way the lookup fallback code worked. This
fixes the issue, and another related one where the
::type was not added to the found item's .ref, and
so the hashtag replacement on the client was not working
correctly.
In this PR, we introduced an option, that when all authenticators are disabled, but backup codes still exists, user can authenticate with those backup codes. This was reverted as this is not expected behavior.
https://github.com/discourse/discourse/pull/18982
Instead, when the last authenticator is deleted, backup codes should be deleted as well. Because this disables 2fa, user is asked to confirm that action by typing text.
In addition, UI for 2fa preferences was refreshed.
* FIX: Save only visible fields from the sidebar page
* FIX: Do not reset seen popups when set to false
If the option was unchecked, but it was not changed at all by the user
it was still sent to the server as a 'false' value which reset all seen
popups. This removes that behavior and resetting the list of seen popups
must be done using the "skip new user tips" button.
That was a weird UX (why hide the preferences navigation?) and a deprecated implementation (manually rendering a template into a named outlet)
This PR replaces it with an inline component.
When finding the candidates for `Topic.similar_to`, we will now ignore
topics in categories where `Category#search_priority` has been set to
ignore and also topics in categories which the user has specifically
muted.
Internal Ref: /t/87132
The repro for the bug:
Add a post with a mention of a user
Post another post below
Delete the first post with a mention
Reload the page and try to attempt to view hidden reply
- Only display topic actions (reply / notification bell) under correct circumstances (multiple posts present, etc)
- Moves topic actions from `glimmer-topic-timeline` into `glimmer-topic-timeline/container` where it should be
* FEATURE: Enforce mention limits for chat messages
The first part of these changes adds a new setting called `max_mentions_per_chat_message`, which skips notifications when the message contains too many mentions. It also respects the `max_users_notified_per_group_mention` setting
and skips notifications if expanding a group mention would exceed it.
We also include a new component to display JIT warning for these limits to the user while composing a message.
* Simplify ignoring/muting filter in chat_notifier
* Post-send warnings for unsent warnings
* Improve pluralization
* Address review feedback
* Fix test
* Address second feedback round
* Third round of feedback
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Note that we don't have a database table and a model for post mentions yet, and I decided to implement it without adding one to avoid heavy data migrations. Still, we may want to add such a model later, that would be convenient, we have such a model for mentions in chat.
Note that status appears on all mentions on all posts in a topic except of the case when you just posted a new post, and it appeared on the bottom of the topic. On such posts, status won't be shown immediately for now (you'll need to reload the page to see the status). I'll take care of it in one of the following PRs.
When a screened IP address is matched because it is either blocked or
allowed it should update match_count. This did not work because it
tried to validate the IP address and it failed as it matched with
itself.
Follow-up to 6357a3ce33
where we allowed a general API key scope for user status
GET/PUT/DELETE, this commit allows the same for the
UserApiKey system.
Previously we would trigger the event before the `Topic#deleted_at`
column has been updated making it hard for plugins to correctly work
with the model when its new state has not been persisted in the
database.
* FIX: Only modify secured sidebar links on user promotion/demotion
If a user is created populate their sidebar with the default
categories/tags that they have access to.
If a user is promoted to admin populate any new categories/tags that
they now have access to.
If an admin is demoted remove any categories/tags that they no longer
have access to.
This will only apply for "secured" categories. For example if these are
the default sitebar categories:
- general
- site feedback
- staff
and a user only has these sidebar categories:
- general
when they are promoted to admin they will only receive the "staff"
category. As this is a default category they didn't previously have
access to.
* Add spec, remove tag logic on update
Change it so that if a user becomes unstaged it used the "add" method
instead of the "update" method because it is essentially following the
on_create path.
On admin promotion/demotion remove the logic for updating sidebar tags because
we don't currently have the tag equivalent like we do for User.secure_categories.
Added the test case for when a user is promoted to admin it should
receive *only* the new sidebar categories they didn't previously have
access to. Same for admin demotion.
* Add spec for suppress_secured_categories_from_admin site setting
* Update tags as well on admin promotion/demotion
* only update tags when they are enabled
* Use new SidebarSectionLinkUpdater
We now have a SidebarSectionLinkUpdater
that was introduced in: fb2507c6ce
* remove empty line
* FEATURE: Show warning if group cannot be mentioned
A similar warning is displayed when the user cannot be mentioned because
they have not been invited to the topic.
* FEATURE: Resolve mentions for new topic
This commit improves several improvements and refactors
/u/is_local_username route to a better /composer/mentions route that
can handle new topics too.
* FEATURE: Show warning if only some are notified
Sometimes users are still notified even if the group that was mentioned
was not invited to the message. This happens because its members were
invited directly or are members of other groups that were invited.
* DEV: Refactor _warnCannotSeeMention
User options were serialized at the root level of CurrentUserSerializer,
but UserSerializer has a user_option field. This inconsistency caused
issues in the past because user_option fields had to be duplicated on
the frontend.
The `Set-Cookie` header is an exceptional case where multiple values are allowed, and should not be joined into a single header. Because of its browser-focussed origins (where set-cookie is not visible), `fetch()` does not have a clean API for this. Instead we have to access the `raw()` data.
This fixes various authentication-related issues when developing via the Ember CLI proxy.
Jarek Radosz
jbrw
Martin Brennan
Alan Guo Xiang Tan
dependabot[bot]
Selase Krakani
Kris
Blake Erickson
Renato Atilio
Penar Musaraj
Krzysztof Kotlarek
Jordan Vidrine
Rafael dos Santos Silva
Bianca Nenciu
David Taylor
Andrei Prigorshnev
Isaac Janzen
Roman Rizzi
Ayke Halder