Categories that had a CategoryUser record and the notification level
set to "Normal" were not selectable in any of the "Watched", "Tracked",
"Watching First Post" or "Muted" inputs. This happened because the
category seemed to be already selected in the "Normal" input, but that
does not exist (it is the default value if category is not present in
any of the other inputs).
This makes it easier to find PMs involving a particular user, for
example by searching for `in:messages thisUser` (previously, that query
would only return results in posts where `thisUser` was in the post body).
The composer is displayed over the bottom part of the page. To make sure
that no content is covered by the composer, a bottom padding is added
equal to the height of the composer. When the composer is opened or
closed that padding is added after around 300ms because of a debounce.
This commit makes sure that the padding is added as soon as the composer
state changes by using a CSS custom property (variable) and transition
property for a smooth user interface.
The title had to be added both on the 404 page generated by the server
side, displayed when the user reaches a bad page directly and the 404
page rendered by Ember when a user reaches a missing topic while
navigating the forum.
If userA has multiple tab/devices on the same topic, and:
1. userA likes a post in tab1
2. userB likes the same post
3. userA post like `acted` attr would desync in tab2
This fix handles this case and also the reverse one when removing likes
interleaved with other users acting on the same post.
Reported in Meta at https://meta.discourse.org/t/-/227239/3
- Only validate if custom_fields are loaded, so that we don't trigger a db query
- Only validate public user fields, not all custom_fields
This commit also reverts the unrelated spec changes in ba148e08, which were required to work around these issues
cf273ec6 removed ie11 as a target. A side effect is that this also removed support for Safari 12, which we will be maintaining support for until January 2023
https://meta.discourse.org/t/224747
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.
The cache was causing state to leak between tests since the `WatchedWord` record in the DB would have been rolled back but `WordWatcher` still had the word in the cache.
An SRV RR contains a priority value for each of the SRV targets that
are present, ranging from 0 - 65535. When caching SRV records we may want to
filter out any targets above or below a particular threshold.
This change adds support for specifying a lower and/or upper bound on
target priorities for any SRV RRs. Any targets returned when resolving
the SRV RR whose priority does not fall between the lower and upper
thresholds are ignored.
For example: Let's say we are running two Redis servers, a primary and
cold server as a backup (but not a replica). Both servers would pass health
checks, but clearly the primary should be preferred over the backup
server. In this case, we could configure our SRV RR with the primary
target as priority 1 and backup target as priority 10. The
`DISCOURSE_REDIS_HOST_SRV_LE` could then be set to 1 and the target with
priority 10 would be ignored.
See /t/66045.
