The `Composer - current time` test would sometimes fail due to a
1-second difference. We don't really need per-second fidelity here, the
key thing this needs to test is that the shortcut works and adds today's
date. I have updated the test to reflect that.
Ember CLI will automatically run babel transformations in parallel when the config is 'serializable', and can therefore be applied in multiple processes automatically. If any plugin is defined in an unserializable way, parallelisation will be disabled.
Our discourse-widget-hbs transformer was causing parallelisation to be disabled. This commit fixes that, and also enables the throwUnlessParallelizable flag so that we catch this kind of issue more easily in future.
This commit also refactors our deprecation silencing system into its own file, and uses a fake babel plugin to ensure deprecations are silenced in babel worker processes.
In our GitHub CI jobs, this doubles the speed of ember builds (1m30s -> 45s). It should also improve production deploy times, and cold-start dev builds.
When a user pauses a youtube video and scrolls up high enough to load
new posts, the video either rewinds or restarts depending on the browser.
The problem is solved by patching virtual-dom to handle element prepends
without reordering old elements.
Long-term, Discourse intends to move away from the vdom/widget implementation, so this is intended as a short-term solution. More context at https://meta.discourse.org/t/57692
Co-authored-by: David Taylor <david@taylorhq.com>
Remove the per user groups based site setting in favor of a global site setting as we want to roll the glimmer topic timeline out to anon users as well as site users.
- Add `enable_experimental_topic_timeline` site setting
- Remove `enable_experimental_topic_timeline_groups` site setting
Improvements for this PR: https://github.com/discourse/discourse/pull/20057
What was fixed:
- [x] Use ember transitions instead of full reload
- [x] Link was inaccurately kept active
- [x] "+ save" renamed to just "save"
- [x] Render emojis in link name
- [x] UI to set icon
- [x] Delete link is trash icon instead of "x"
- [x] Add another link to on the left and rewording
- [x] Raname "link name" -> "name", "points to" -> link
- [x] Add limits to fields
- [x] Move add section button to the bottom
Prior to this fix on mobile the card-cloak would not get removed if the user/group card was leading to a non existing user/group.
The fix ensures hidden class is removed each time we call show.
We recently had a bug which caused auto-bumping to "not work". The problem was that the value had been set to 0.5, which when coerced to an integer turned into 0. So the feature is "working as intended", but there's a possibility of misconfiguration.
When looking into this, I noticed that the inputs on the category settings page doesn't have any particular sanitisation in the front-end, and also one or two validations missing in the back-end.
This change:
- Takes an existing component, NumberField and enhances that by only allowing numeric input, essentially turning it into a managed input using the same approach as our PasswordField.
- Changes the numeric inputs on category settings page to use this component.
- Adds appropriate min constraints to the fields to disallow out-of-range values.
- Adds missing back-end validations to relevant fields.
This commits adds the ability to add a header to the embedded comments
view. One use case for this is to allow `postMessage` communication
between the comments iframe and the parent frame, for example, when
toggling the theme of the parent webpage.
This is an alternative way to use `RenderGlimmer` which can be more ergonomic for iterative updates of a codebase. For documentation, see `widgets/render-glimmer.js`
Fixed had been added when autocomplete was used in the discourse header. This shouldn't be needed anymore. This was causing the preventOverflow to not work correctly on Android.
This fix fix also adds an optimisation to refer top of the input when on mobile. This is done to avoid cases where the screen is actually slightly taller than the viewport with keyboard visible on Android leading popper to think there's space under the input.
- Move docking logic (intersection / dockAt / etc) from `glimmer-topic-timeline` -> `topic-timeline/container` to live alongside the `postScrolled` hook.
- Toggle `timeline-docked` and `timeline-docked-bottom` when we are at the bottom of a topic. This returns the missing animation to the glimmer-topic-timeline (pictured below).
https://user-images.githubusercontent.com/50783505/216655735-906ccd2a-b77e-45af-9a7b-c22680eca2dc.mov
Previously `helper.renderGlimmer()` would always create a new wrapper element. This is required when using `RenderGlimmer` within widgets, where there is no direct access to DOM elements. However, when using within `decorateCooked`, we have the ability to pass an existing element to `{{#in-element}}` and have the glimmer content appended with no additional wrappers.
This commit makes the `renderInto` accept an existing DOM node for this 'append' behavior. The previous 'new wrapper element' behaviour is still used when a string is passed.
# Context
The class of `widget-button` was kept in the upgraded version of the topic timeline to keep the preexisting logic of how we open / close child and parent modals.
# Problem
<img width="1242" alt="Screenshot 2023-02-02 at 3 45 53 PM" src="https://user-images.githubusercontent.com/50783505/216456778-11a3d0ce-5e33-4b85-89af-a2a32e39a1f6.png">
With the `widget-button` class removed from the topic timeline, clicking the button (highlighted in the image above) would close itself when populating the `jumpToPostPrompt` modal. This is not the behavior we want so class was kept on the button. The upgrade to ember octane entails moving away from widgets and all of its functionality... so we don't want to carry the debt of utilizing the `widget-button` class.
# Solution
Create a new class `.timeline-open-jump-to-post-prompt-btn` to be added to the `_expanded` function. When this class is present on a child or a parent of the button clicked, we do not collapse the modal. This gives us the expected behavior of maintaining both modals open at the same time.
<img width="1176" alt="Screenshot 2023-02-02 at 3 50 59 PM" src="https://user-images.githubusercontent.com/50783505/216457612-ab313758-bfa9-4913-bd29-d5224faf5187.png">
# Other
Obviously adding this as jquery is not ideal, but to prevent scope creep we will need to refactor this in a separate PR.
Allows users to configure their own custom sidebar sections with links withing Discourse instance. Links can be passed as relative path, for example "/tags" or full URL.
Only path is saved in DB, so when Discourse domain is changed, links will be still valid.
Feature is hidden behind SiteSetting.enable_custom_sidebar_sections. This hidden setting determines the group which members have access to this new feature.
- Rename `class` getter -> `classes` seeing that we are dealing with multiple classes
- Add `show` class to fullscreen topic timeline via `did-insert` to handle how CSS transitions only apply when an existing element changes its properties. We need to wait until `timeline-fullscreen` is painted to the DOM, and then add the `show` class later.
# Problem
Creating a post on a topic, where the timeline is not shown by default, does not update the visibility state dynamically. You must refresh the page to have the timeline appear.
# Solution
This PR hooks into the `post-stream:posted` app event and checks if we can now display the timeline after a post has been created. This will update the visibility state dynamically.
This PR introduces a proper `action` to the topic timeline `back-button` which will fix the button not being clickable (or functional) as well as removing a duplicate setting of `this.lastReadTop` which was causing odd positionings of the button.
This is very difficult to test due to the fact you have to manage the "read history" for a user to have the back button populate. We will have to move forward without one (as we did in the last version of the timeline 😅) for now.
`helper.renderGlimmer` will return an HTML element which can be added to a post's `cooked`
Example usage:
```
import { hbs } from "ember-cli-htmlbars";
api.decorateCookedElement((cooked, helper) => {
const glimmerElement = helper.renderGlimmer(
"div.my-wrapper-class",
hbs`<DButton @icon={{@data.param}} @translatedLabel="Hello world from Glimmer Component"/>`,
{ param: "user-plus" }
);
cooked.appendChild(glimmerElement);
}, { onlyStream: true, id: "my-id" });
```
See `widgets/render-glimmer.js` for more detailed usage information.
For a user whose username has an uppercase character, the new user menu
dropdown was not defaulting to "Inbox" because the Ember router uses
lowercased usernames which were not matching with the `username`
property. Switching to `username_lower` fixes the issue.
In a private plugin, we need to show an error message containing HTML
when the Grant Admin action fails. This change introduces a new flag
(`html_message: true`) that when used will allow the dialog to render
the HTML tags in the error message correctly.
We don't need a full glimmer component here - the class definition was empty. We can use templateOnly() for slightly improved performance.
Setting `component.name` improves how MountWidget is displayed for debugging in the Ember Inspector browser extension.
1. What is the problem here?
When a user's reviewables count changes, the changes are published via
MessageBus in a background Sidekiq job which means there is a delay before the
client receives the MessageBus message with the updated count. During
the time the reviewables count for a user has been updated and the time
when the client receives the MessageBus message with the updated count,
a user may view the reviewables list in the user menu. When that happens, the number of
reviewables in the list may be out of sync with the count shown.
2. What is the fix?
Going forward, the response for the `ReviewablesController#user_menu_list` action will include the user's reviewables count as
the `reviewables_count` attribute. This is then used by the client side
to update the user's reviewables count to ensure that the reviewables
list and count are kept in sync.
Due to the way templates work, the incorrect variable (user instead of item) was not causing any error, and just failing silently to display the avatar.
This commit is also providing a basic spec for completion of users and groups.
## Why do we need this change?
When loading the ember app, [MessageBus does not start polling immediately](f31f0b70f8/app/assets/javascripts/discourse/app/initializers/message-bus.js (L71-L81)) and instead waits for `document.readyState` to be `complete`. What this means is that if there are new messages being created while we have yet to start polling, those messages will not be received by the client.
With sidebar being the default navigation menu, the counts derived from `topic-tracking-state.js` on the client side is prominently displayed on every page. Therefore, we want to ensure that we are not dropping any messages on the channels that `topic-tracking-state.js` subscribes to.
## What does this change do?
This includes the `MessageBus.last_id`s for the MessageBus channels which `topic-tracking-state.js` subscribes to as part of the preloaded data when loading a page. The last ids are then used when we subscribe the MessageBus channels so that messages which are published before MessageBus starts polling will not be missed.
## Review Notes
1. See https://github.com/discourse/message_bus#client-support for documentation about subscribing from a given message id.
The `tagName` argument is now deprecated. This commit uses a codemod (https://github.com/discourse/discourse-ember-codemods/tree/main/transforms/extract-plugin-outlet-tagname) to automatically remove the `@tagName` from all PluginOutlet invocations, and create a matching wrapper element so that the HTML structure is unchanged. We may want to remove some/all of these wrappers entirely in future, but that would be a riskier change which we should tackle on a case-by-case basis.
This outlet is the only one to pass an `@classNames` argument, which is no longer supported in the glimmer version of PluginOutlet. This commit moves the wrapper outside, thereby maintaining the old HTML structure.
This commit updates the PluginOutlet component so that it calculates the list of connectors in an autotracking context. Accessing arguments or any other `@tracked` values during `shouldRender` means that the set of connectors will be re-calculated whenever those tracked values change.
PluginConnector remains a Classic Component, so this commit does not require any changes from plugin/theme developers.
Two shims are introduced for backwards compatibility:
- The component variable passed to shouldRender is replaced with a helperContext instance which includes all the common injections (the new PluginOutlet component instance does not have any of these)
- A custom component manager is introduced so that parentView continues to work. Using parentView was never really intended as an API, so it's now deprecated and will print a warning to the console. Users should switch to using the outlet's explicit arguments, or data from a service (e.g. the Router service).
The presence service would retry `/presence/update` requests every second (or immediately in tests) in case where server returns 429 (rate limit) errors. That could lead to infinite spamming (until user refreshed tab/tabs)
Co-authored-by: David Taylor <david@taylorhq.com>
Currently `Topic#pm_topic_count` is a count of all personal messages tagged for a given tag. As a result, any user with access to PM tags can poll a sensitive tag to determine if a new personal message has been created using that tag even if the user does not have access to the personal message. We classify this as a minor leak in sensitive information.
With this commit, `Topic#pm_topic_count` is hidden from users by default unless the `display_personal_messages_tag_counts` site setting is enabled.
A while back the definition of TL was changed but many
areas in the codebase still use the term 'Regular user'
despite it having some implicit meaning (TL2).
See 20140905055251_rename_trust_level_badges.rb
This is necessary so MacOS Ventura (and in 2023 iOS) can use our new
default push notifications.
We still disable caching of dynamic routes on Apple devices due to it's
always being buggy there.
Partial username or name matches were shown together with metadata
matched results. This created a bad user experience because results
that look unrelated were before even partial or exact group matches.
Behavior should be very similar but the code is simplified and it should fix various bugs where the card was showing out of screen even if we had available space.
Using a shared channel with per-message permissions means that every client is updated with the channel's 'last_id', even if there are no messages available to them. Per-user channel names avoid this problem - the last_id will only be incremented when there is a message for the given user.
This commits adds a database migration to limit the user status to 100
characters, limits the user status in the UI and makes sure that the
emoji is valid.
Follow up to commit b6f75e231c.
* FIX: Ensure soft-deleted topics can be deleted
The topic was not found during the deletion process because it was
deleted and `@post.topic` was nil.
* DEV: Use @topic instead of finding the topic every time
When creating a group membership request, there is no character
limit on the 'reason' field. This can be potentially be used by
an attacker to create enormous amount of data in the database.
Co-authored-by: Ted Johansson <ted@discourse.org>
When a user checks "Open all external links in a new tab" preference
he expects not to be overruled by unrelated text selections.
Yet if text is selected during a link click the link is followed on
the same tab. This change corrects that.
In the group member bulk edit menu we are displaying staff-only options
to non-staff. The requests are blocked by the back-end, so there is no
harm other than to the user experience.
Notably the individual user edit menu is correctly filtering out
unavailable options. This change brings the bulk edit menu in line with
that.
This was previously disabled because of incompatibility with the ember-cli proxy. This commit fixes that incompatibility, and restores the development behaviour to match production.
There were three issues at play:
1. Our bootstrap-js addon handles the forwarding of most requests in the ember-cli proxy. This is not built to handle streaming responses. Solution: skip our custom request processing for `/message-bus/*` and use ember-cli's default `http-proxy`.
2. The request/response size-limiting middleware (`rawMiddleware`) would apply even to unhandled paths, causing request and response bodies to be buffered. Solution: skip it for any paths which are not handled by our custom addon.
3. Expressjs servers will buffer/compress responses. Solution: add `Cache-Control: no-transform` to message-bus responses. For now I've done this in development only, but it may be useful to add it to message-bus's default headers in future
Data Explorer queries have a `user_id` assigned to each query created. DE Reports can be bookmarked for later reference.
When creating the bookmark notification there was the possibility of a notification error being thrown (that made the notification menu inaccessible) due to a DE Query not having a owner (associated user_id). This can happen in a couple ways:
- having a query created by a user that was then later deleted leaving the query without ownership
- having a TA create a query for a customer using a temporary account, that would then later be deleted leaving the query without ownership
Since there is a case that `bookmark.user` is not valid the PR makes the `bookmark.user.username` optional for a bookmark notification. As [tested](https://github.com/discourse/discourse/pull/19851/files#diff-5b5154de37f96988d551feff6f1dfe5ba804fbcbc1c33b5478dde02a447a634f) in the case a username is not present, we will still render the `content` of the notification minus the username. This creates a safe fallback when looking up non-valid users.
* Firefox now finally returns PerformanceMeasure from performance.measure
* Some TODOs were really more NOTE or FIXME material or no longer relevant
* retain_hours is not needed in ExternalUploadsManager, it doesn't seem like anywhere in the UI sends this as a param for uploads
* https://github.com/discourse/discourse/pull/18413 was merged so we can remove JS test workaround for settings
There are various performance issues with the Canvas in iOS Safari
that are causing crashes when processing images with spikes of over 100%
CPU usage. The cause of this is unknown, but profiling points to
CanvasRenderingContext2D.getImageData() and
CanvasRenderingContext2D.drawImage().
Until Safari makes some progress with OffscreenCanvas or other
alternatives we cannot support this workflow. We will revisit in 6
months.
This is gated behind the hidden `composer_ios_media_optimisation_image_enabled`
site setting for people who really still want to try using this.
This commit introduces the experimental `registerUserCategorySectionLinkCountable`
and `refreshUserSidebarCategoriesSectionCounts` plugin APIs that allows
a plugin to register custom countables to category section links on top
of the defaults of unread and new.
This feature is stable enough now to make it the default going forward
for new sites. Existing sites that have not yet set enable_experimental_hashtag_autocomplete
to `true` will have it set to `false` for their site settings, which was the old default.
c.f https://meta.discourse.org/t/hashtags-are-getting-a-makeover/248866
This commit fixes an issue where the chat message bookmarks
did not respect the user's `bookmark_auto_delete_preference`
which they select in their user preference page.
Also, it changes the default for that value to "keep bookmark and clear reminder"
rather than "never", which ends up leaving a lot of expired bookmark
reminders around which are a pain to clean up.
Using a shared channel means that every user receives an update to the 'last_id' when *any* other user is logged out. If many users are being programmatically logged out at the same time, this can cause a very large number of message-bus polls.
This commit switches to use a user-specific channel, which means that each user has its own 'last id' which will only increment when they are logged out
* Remove unused strings
* Remove trailing quote from string
* Remove even more unused strings (they were removed in c4e10f2a9d)
* Don't use translations in tests which are only available on server
* Use more specific translation (and fix missing translation)
Rather than hardcoding `.hashtag-autocomplete__fadeout` as the
div element to scroll in autocomplete, instead pass it in as
an option via `scrollElementSelector`, then we don't have hashtag
template specific things in the autocomplete lib.
# Context
When a topic is reviewable by a group we give those group moderators some admin abilities including the ability to delete a topic.
# Problem
There are two main problems:
1. Currently when a group moderator deletes a topic they are redirected to root (not the same for staff)
2. Viewing the categories deleted topics (`c/foo/1/?status=deleted`) does not display the deleted topic to the group moderator (not the same for staff).
# Fix
If the `deleted_by` user is part a group that matches the `reviewable_by_group` on a topic then don't redirect. This is the default interaction for staff to give them the ability to do things like restore the topic in case it was accidentally deleted.
To render the deleted topics as expected for the group moderator I am utilizing [the guardian scope of `guardian.can_see_deleted_topics?` for said category](https://github.com/discourse/discourse/pull/19618/files#diff-288e61b8bacdb29d9c2e05b42da6837b0036dcf1867332d977ca7c5e74a44297R802-R803)
We need to set the local state of a channel before performing any async operations. Otherwise, multiple leave/join calls can race against each other and cause the local state to get out-of-sync with the server.
Followup to e70ed31a
Group names will be used as CSS classes in some components while rendering the public HTML output. It will happen when a group is set as the default primary for users. Or when a group has either a flair icon or flair upload. So we should warn the admins when they restrict the group's visibility level.
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
Autocomplete with fadeout was not scrolling on arrow
key press in chat, since the input is treated slightly
differently. We just need to find the fadeout div sooner.
Follow up to 64a7a2aac2
The way our markdown raw_html hoisting worked, we only
supported one level of hoisting the HTML content. However
when nesting [chat] transcript BBCode we need to allow
for multiple levels of it. This commit changes opts.discourse.hoisted
to be more constant, and the GUID keys that have the hoisted
content are only deleted by unhoistForCooked rather than
the cook function itself, which prematurely deletes them
when they are needed further down the line.
Follow up to 8820e9418a,
only the hashtag autocomplete has a fadeout scroll, so
we still need to scroll on the original div in some
cases (e.g. mentions)
Note this is a very large PR, and some of it could have been splited, but keeping it one chunk made it to merge conflicts and to revert if necessary. Actual new code logic is also not that much, as most of the changes are removing js tests, adding system specs or moving things around.
To make it possible this commit is doing the following changes:
- converting (and adding new) existing js acceptances tests into system tests. This change was necessary to ensure as little regressions as possible while changing paradigm
- moving away from store. Using glimmer and tracked properties requires to have class objects everywhere and as a result works well with models. However store/adapters are suffering from many bugs and limitations. As a workaround the `chat-api` and `chat-channels-manager` are an answer to this problem by encapsulating backend calls and frontend storage logic; while still using js models.
- dropping `appEvents` as much as possible. Using tracked properties and a better local storage of channel models, allows to be much more reactive and doesn’t require arbitrary manual updates everywhere in the app.
- while working on replacing store, the existing work of a chat api (backend) has been continued to support more cases.
- removing code from the `chat` service to separate concerns, `chat-subscriptions-manager` and `chat-channels-manager`, being the largest examples of where the code has been rewritten/moved.
Future wok:
- improve behavior when closing/deleting a channel, it's already slightly buggy on live, it's rare enough that it's not a big issue, but should be improved
- improve page objects used in chat
- move more endpoints to the API
- finish temporarily skipped tests
- extract more code from the `chat` service
- use glimmer for `chat-messages`
- separate concerns in `chat-live-pane`
- eventually add js tests for `chat-api`, `chat-channels-manager` and `chat-subscriptions-manager`, they are indirectly heavy tested through system tests but it would be nice to at least test the public API
<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
Follow-up to 8db1f1892d,
this makes the hashtag autocomplete scrolling with arrow
keys work with the new fadeout element that is now used
for the scroll container.
* UX: Wizard Step Enhancements
- Remove illustrations
- Add Emoji graphic to top of steps
- Add description below step title
- Move point of contact to last step
* Move step count to header, plus some button navigation tweaks
* add remaining emoji to step headers
* fix button logic on steps
* Update Point of Contact
* remove automated messages field
* adjust styling for counter, title, and emoji
* Update wording for logos
* Fix tests
* fix prettier
* fix specs
* set same with for steps except for styling screen
* use sentence case; remove duplicate copy under your organization fields
* fix missing buttons on small screens
* add spacing to buttons; adjust font weight to labels
* adjust styling for community logo step; use sentence case for button
* update copy for point of contact text helper
* use sentence case for field labels
* fix ui tests
* use btn-back class to fix ui tests
* reduce bottom margin for toggle fields
* clean up
Co-authored-by: Ella <ella.estigoy@gmail.com>
* UX: added fadeout + hashtag styling
UX: add full name to autocomplete
UX: autocomplete mentions styling
UX: emoji styling user status
UX: autocomplete emoji
* DEV: Move hashtag tag counts into new secondary_text prop
* FIX: Add is-online style to mention users via chat
UX: make is-online avatar styling globally available
* DEV: Fix specs
* DEV: Test fix
Co-authored-by: Martin Brennan <martin@discourse.org>
* DEV: Remove enable_whispers site setting
Whispers are enabled as long as there is at least one group allowed to
whisper, see whispers_allowed_groups site setting.
* DEV: Always enable whispers for admins if at least one group is allowed.
We decided to rename the "Do Not Disturb" mode to "Pause Notifications". I am starting from changing strings on the client, that will update user interface. And I'm going to do renamings in frontend and backend code after some time.
This PR adds a new "Pause notifications" checkbox to the user status modal. This checkbox allows enabling the Do-Not-Disturb mode together with user status. Note that we don't remove and don't rename the existing DnD menu item in this PR, so the old way of entering the DnD mode is still available.
Also, we're not making DnD mode a part of user status on backend and in database. The reason is that the DnD mode should still be available on sites with disabled user status, having them separated helps keep the implementation simple.
* FEATURE: Add support for desktop push notifications in core
Default to push for live notifications on desktop if available and
`enable_desktop_push_notifications` site setting set to true.
This removes the need for desktop-push-notifications plugin.
* DEV: Ensure live notifications are enabled explicitly
Allow a user with push notification access who has directly
enabled notifications via the browser settings to trigger push subscription
flow.
Way back in 90100378b8 when
we first added hashtag autocompletion, we added a rule to
say we should not trigger autocomplete when backspacing into
a hashtag. I think this is because we used to also not trigger
it at the start of the line because of how markdown headers
used to work. We removed this rule in 6f0b9bb1c4
so we are safe to remove the backspace exception here too.
Now you can backspace into a hashtag to trigger the autocomplete.
The autocomplete container has not needed to be
scrolled with arrow keys until we introduced the new
hashtag autocomplete, which shows more options and allows
scrolling. This commit scrolls the options up/down when
selecting an item outside the scroll with arrow keys.
We were changing the user's user_option.bookmark_auto_delete_preference
to whatever they changed it to in the bookmark modal to use as default
for future bookmarks. However this was leading to a lot of confusion
since if you wanted to set it for one bookmark you had to remember to
change it back on the next one.
This commit removes that automatic functionality, and instead moves
the bookmark auto delete preference to User Preferences > Interface
in an explicit dropdown.
This commit adds a new notification that gets sent to admins when the site gets new features after an upgrade/deploy. Clicking on the notification takes the admin to the admin dashboard at `/admin` where they can see the new features under the "New Features" section.
Internal topic: t/87166.
We update `og:title`, `og:url`, might as well update `twitter:title`
and `twitter:url`. This might also fix a Chrome/Android issue where the
root URL is shared instead of the current page's URL.
FEATURE: Chat and Sidebar are now on by default
- Set the sidebar site setting to be enabled by default
- Set the chat site setting to be enabled by default
- Updated existing specs that assumed the original default
- Use a migration to keep old defaults for existing sites
When user is watching category or tag (watching or watching first post) notifications are moved to other tab.
To achieve that and distinguish between post create to directly watched topics and indirectly watched topics, new notification type called `watching_category_or_tag` was introduced.
Fixes an issue on mobile where navigating away from search and returning
results in confusing UI where there are no results but headings says "N
results found".
This fixes the problem reported in https://meta.discourse.org/t/trackstatus-error-in-docs-topics/248717 and also guarantees that the same problem won't appear in other plugins.
The problem was that we're calling trackStatus() and on() on a user object, but that only works if it's a user model and fails on plain js objects.
I'm not adding tests here because in Core we always have a properly wrapped user model here. But this fix makes sure that plugins that don't won't fail here.
1. The events table had broken styling, making each row overflow
2. It had confusing routes: `/:id` for "edit" and `/:id/events` for "show" (now it's `/:id/edit` and `/:id` respectively)
3. There previously was an unused backend action (`#edit`) - now it is used (and `web_hooks/:id/events` route has been removed)
4. There was outdated/misplaced/duplicated CSS
5. And more
1. "What Goes Up Must Come Down" – if you subscribe to message bus, make sure you also unsubscribe
2. When you unsubscribe - remove only your subscription, not **all** subscriptions on given channel
Attempt #2. The first attempt tried to extend a core `@bound` method in new-user-narrative plugin which did not work. I reworked that plugin in the meantime. This new PR also cleans up message bus subscriptions in now core-merged chat plugin.
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://`.
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.
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.
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.
* 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.
