Why this change?
There are two problematic queries in question here when loading
notifications in various tabs in the user menu:
```
SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338 AND (topics.id IS NULL OR topics.deleted_at IS NULL)
ORDER BY notifications.high_priority AND NOT notifications.read DESC,
NOT notifications.read AND notifications.notification_type NOT IN (5,19,25) DESC,
notifications.created_at DESC
LIMIT 30;
```
and
```
EXPLAIN ANALYZE SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338
AND (topics.id IS NULL OR topics.deleted_at IS NULL)
AND "notifications"."notification_type" IN (5, 19, 25)
ORDER BY notifications.high_priority AND NOT notifications.read DESC, NOT notifications.read DESC, notifications.created_at DESC LIMIT 30;
```
For a particular user, the queries takes about 40ms and 26ms
respectively on one of our production instance where the user has 10K notifications while the site has 600K notifications in total.
What does this change do?
1. Adds the `index_notifications_user_menu_ordering` index to the `notifications` table which is
indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read)
DESC, created_at DESC)`.
1. Adds a second index `index_notifications_user_menu_ordering_deprioritized_likes` to the `notifications`
table which is indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read AND notification_type NOT IN (5,19,25)) DESC, created_at DESC)`. Note that we have to hardcode the like typed notifications type here as it is being used in an ordering clause.
With the two indexes above, both queries complete in roughly 0.2ms. While I acknowledge that there will be some overhead in insert,update or delete operations. I believe this trade-off is worth it since viewing notifications in the user menu is something that is at the core of using a Discourse forum so we should optimise this experience as much as possible.
* DEV: add topic-map-expanded glimmer component
* DEV: remove topic-map-expanded widgets from topic-map
* DEV: add noreferrer for _blank target and add table grouping to template
* DEV: negate base styling of tbody element so expanded topic map retains current look
* DEV: pass in title to TopicParticipants as internationalized string instead of renderable HTML and set TRUNCATED_LINKS_LIMIT constant
Why this change?
The `/admin/customize/themes/:id/schema/name` route is a work in
progress but we want to be able to start navigating to it from the
`/admin/customize/themes/:id` route.
What does this change do?
1. Move `adminCustomizeThemes.schema` to a child route of
`adminCustomizeThemes.show`. This is because we need the model
from the parent route and if it isn't a child route we end up
having to load the theme model again from the server.
1. Add the `objects_schema` attribute to `ThemeSettingsSerializer`
1. Refactor `SiteSettingComponent` to be able to render a button
so that we don't have to hardcode the button rendering into the
`SiteSettings::String` component
* UX: chat message creator scss cleanup + design tweak to username display
* add user status with live updates to modal
* show user status description in modal
* add tests for user status
* UX: add user-status styling to chat message creator
---------
Co-authored-by: David Battersby <info@davidbattersby.com>
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Skipping babel for qunit is part of the default embroider blueprint. Adding these doesn't seem to have a measurable effect on build time, but it does stop this message from being printed in the build log:
```
The code generator has deoptimised the styling of /Users/david/discourse/discourse/node_modules/sinon/pkg/sinon-esm.js as it exceeds the max of 500KB
```
Adds a site setting to include a post's content in penalty message.
When silencing/suspending a user from a post, or a reviewable with
a post, adds an option to include a post's content in the email
message by default.
When a post is created by an incoming email, we show
an envelope icon on it which then opens a modal with the
raw email contents. Previously this was staff (admin+mod)
only, but now this commit adds the `view_raw_email_allowed_groups`
site setting, so any group can be added to give users permission
to see this.
CategoryChooser component usually displays just categories, but
sometimes it can show two none values: a "no category" or Uncategorized.
This commit makes sure that these are rendered correctly.
The problem was that the "none" item was automatically inserted in the
list of options, but that should not always happen. Toggling option
`autoInsertNoneItem` requires setting `none` too.
With the adjustments of `btn-transparent` in https://github.com/discourse/discourse/pull/24666, there are more buttons that could use this class instead of `btn-flat`. This mostly relates to `x` close buttons, but also includes composer and chat toggles.
The primary difference between these styles is that `btn-transparent` never has a background, where `btn-flat` may have a hover or focus background.
Why this change?
Prior to this change, the `CategoryList#find_relevant_topics` method was
loading and allocating all `CategoryFeaturedTopic` records in the
database to eventually only just use its `category_id` and `topic_id`
column. On a site with many `CategoryFeaturedTopic` records, the loading
of the ActiveRecord objects is a source of bottleneck.
The other problem with the `CategoryList#find_relevant_topics` method is
that it is unconditionally loading all records from the database even if
the user does not have access to the category. This again is wasteful.
What does this change do?
This commit makes it such that `CategoryList#find_relevant_topics` is
called only after `CategoryList#find_categories` in the `CategoryList#initialize`
method so that we can filter featured topics against categories that the
user has access to.
The second change is that Instead of loading `CategoryFeaturedTopic` records, we make an
inner join agains the `topics` table instead and skip any allocation of
`CatgoryFeaturedTopic` ActiveRecord objects.
When we send a bookmark reminder, there is an option to delete
the underlying bookmark. The Notification record stays around.
However, if you want to filter your notifications user menu
to only bookmark-based notifications, we were not showing unread
bookmark notifications for deleted bookmarks.
This commit fixes the issue _going forward_ by adding the
bookmarkable_id and bookmarkable_type to the Notification data,
so we can look up the underlying Post/Topic/Chat::Message
for a deleted bookmark and check user access in this way. Then,
it doesn't matter if the bookmark was deleted.
In this PR, the admin panel remembers the previous state and restores it when the admin panel is deactivated.
https://github.com/discourse/discourse/pull/25781
However, it would be better to have a more generic solution. When the panel is changed, the previous state is saved in the sidebarState. When a user returns to the specific panel, a previously remembered state is restored.
And normalize `<PasswordField />` arguments
(we were getting `[DOM] Input elements should have autocomplete attributes (suggested: "current-password")` in smoke test logs, this may or may not fix that 😛)
When tagging a user in composer, the autocomplete div has a fixed width, causing longer names and usernames to get cut off. This change allows the div to expand up until a max-width of 600px on desktop.
As part of problem checks refactoring, we're moving some data to be DB backed. In this PR it's the tracking of problem check execution. When was it last run, when was the last problem, when should it run next, how many consecutive checks had problems, etc.
This allows us to implement the perform_every feature in scheduled problem checks for checks that don't need to be run every 10 minutes.
Continue from https://github.com/discourse/discourse/pull/25673.
This commit starts building the inputs pane of schema theme settings. At the moment only string fields are rendered, but more types will be added in future commits.
This commit adds a loading spinner when installing a theme as sometimes
installing a theme can take quite a bit of time this way we have some
indication that things are still working as the theme is being
installed.
Before this commit, we had a yarn package set up in the root directory and also in `app/assets/javascripts`. That meant two `yarn install` calls and two `node_modules` directories. This commit merges them both into the root location, and updates references to node_modules.
A previous attempt can be found at https://github.com/discourse/discourse/pull/21172. This commit re-uses that script to merge the `yarn.lock` files.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
Users can hide their public profile and presence information by checking
“Hide my public profile and presence features” on the
`u/{username}/preferences/interface` page. In that case, we also don't
want to return user status from the server.
This work has been started in https://github.com/discourse/discourse/pull/23946.
The current PR fixes all the remaining places in Core.
Note that the actual fix is quite simple – a5802f484d.
But we had a fair amount of duplication in the code responsible for
the user status serialization, so I had to dry that up first. The refactoring
as well as adding some additional tests is the main part of this PR.
In safe mode plugins are not loaded, so the plugin admin
routes are not loaded. This was causing errors in the
admin sidebar because we are trying to show links to the plugin
admin routes.
This fixes the issue by just not adding the plugin links if
we are in safe mode.
Now forums can enroll their sites to be showcased in the Discourse [Discover](https://discourse.org/discover) directory. Once they enable the site setting `include_in_discourse_discover` to enroll their forum the `CallDiscourseHub` job will ping the `api.discourse.org/api/discover/enroll` endpoint. Then the Discourse Hub will fetch the basic details from the forum and add it to the review queue. If the site is approved then the forum details will be displayed in the `/discover` page.
Also, remove experimental setting and simply use top_menu for feature detection
This means that when people eventually enable the hot top menu, there will
be topics in it
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
Previously, problem checks were all added as either class methods or blocks in AdminDashboardData. Another set of class methods were used to add and run problem checks.
As of this PR, problem checks are promoted to first-class citizens. Each problem check receives their own class. This class of course contains the implementation for running the check, but also configuration items like retry strategies (for scheduled checks.)
In addition, the parent class ProblemCheck also serves as a registry for checks. For example we can get a list of all existing check classes through ProblemCheck.checks, or just the ones running on a schedule through ProblemCheck.scheduled.
After this refactor, the task of adding a new check is significantly simplified. You add a class that inherits ProblemCheck, you implement it, add a test, and you're good to go.
I was using adminPlugins instead of adminPlugins.index for the Installed Plugins
link in admin sidebar, which was causing Ember to highlight the main link and a plugin
link at the same time.
We only want to highlight the top level Installed Plugins link if we are on that page,
not if we are on e.g. the chat plugin admin route.
Subcategories were not returned when lazy loaded categories are enabled.
This commit implements the old behavior which displayed only top level
categories when there was no search term, but when there was one, it
searched subcategories too.
This commit also removes the client-side ordering of categories, because
the results are already ordered on the server-side.
Recently, Discourse introduced the concept of wrapper plugin outlets, which enables plugins and theme-components lo replace the wrapped content:
```
<PluginOutlet @name="wrapper-outlet-example" @outletArgs={{hash model=@model}}>
<div>Overridable content</div>
</PluginOutlet>
```
This commit adds automatic outlets that are placed `before` and `after wrapper plugin outlets. Connectors them can leverage these new automatic outlets to mount content at these positions, which greatly enhances the use case of the wrapper outlets.
These new auto outlets can be used in two ways:
- Using the standard folder base structure: the folder name that identifies the outlet in which the connector must be mounted must add the suffixes `__before`or `__after` to the outlet name. For the outlet in the example above, the connector should be placed into the `.../connectors/wrapper-outlet-example__before`or `.../connectors/wrapper-outlet-example__after`folders.
- Using API calls: this commit also introduces two new plugin APIs, `api.renderBeforeWrapperOutlet` and `renderAfterWrapperOutlet`. These new APIs can be used in the same way as `api.renderInOutlet`but will only work for wrapper outlets.
For the outlet above when using these new APIs alongside the gjs file format, one could define a component to be placed before the content of the outlet like:
```
api.renderBeforeWrapperOutlet('wrapper-outlet-example', <template>Hello from before the content</template>);
```
or after:
```
api.renderAfterWrapperOutlet('wrapper-outlet-example', <template>Hello from after the content</template>);
```
The uncategorized category was not rendered correctly and it was also
sometimes displayed twice. This commit is a similar bug fix to commit
76647d3a34 and is a follow up to commit
63a50b12fd.
Why this change?
The previous test setup did not actually act as a regression test
because the test will still pass even when the fix is removed. This
commit uses a rendering test instead to ensure that Ember is tracking
the property change.
Why this change?
We have been getting customisation requests about adding stuff
before/after the sidebar sections so we are adding plugin outlets to
support those requests.
Why this change?
This regressed in b797434376 where
the count property in `ExtraNavItem` needs to be tracked as plugins can
be updating the count property directly.
Add categories to the serialized search results together with the topics
when lazy load categories is enabled. This is necessary in order for the
results to be rendered correctly and display the category information.
We're starting to use this system for non-ember-5 deprecations, so linking to the Ember 5 topic doesn't make sense. Instead, we can include the deprecation ID to help with identifying the issue.
We have separated and combined modes for sidebar panels.
Separated means the panels show only their own sections,
combined means sections from all panels are shown.
The admin sidebar only shows its own panels, so it must set
the mode to separated; however when we navigate to chat or
home we must revert to the initial mode setttings.
When hiding/showing the sidebar, as is the case on mobile
and using the toggle in the top left on desktop, we delete
and recreate the ember component on the page. This causes
the `sections` for each sidebar panel to get re-evaluated
every time.
For the admin sidebar, this means that we were constantly
re-adding the plugin links to the sidebar, causing duplication.
This can be fixed by just adding @cached to the getter for
sections.
The Digital Services Act requires a checkbox for any user who's flagging a post as illegal to confirm that they are flagging in good faith. This PR adds that.
Why this change?
Firstly, note that this is not a security commit because this feature is
still in development and should not be used anywhere.
The reason we want to set a limit here is to greatly reduce the
possibility of a DoS attack in the future via `ThemeSetting` where
someone would set an arbituary large json string in
`ThemeSetting#json_value` and causing the server to run out of resources
trying to serialize/deserialize the value.
What does this change do?
Adds an ActiveRecord validation to ensure that the bytesize of the json
string being stored is smaller than or equal to 0.5mb. We believe 0.5mb
is a decent limit for now but we can review the limit in the future if
we believe it is too small.
Why this change?
The logic for validating a theme setting's value and default value was
not consistent as each part of the code would implement its own logic.
This is not ideal as the default value may be validated differently than
when we are setting a new value. Therefore, this commit seeks to
refactor all the validation logic for a theme setting's value into a
single service class.
What does this change do?
Introduce the `ThemeSettingsValidator` service class which holds all the
necessary helper methods required to validate a theme setting's value
A while ago we increased group SMTP read and open timeouts
to address issues we were seeing with Gmail sometimes giving
really long timeouts for these values. The commit was:
3e639e4aa7
Now, we want to increase all SMTP read timeouts to 30s,
since the 5s is too low sometimes, and the ruby Net::SMTP
stdlib also defaults to 30s.
Also, we want to slightly tweak the group smtp email job
not to fail if the IncomingEmail log fails to create, or if
a ReadTimeout is encountered, to avoid retrying the job in sidekiq
again and sending the same email out.
* Remove unnecessary properties
* Use rem unit
* Add a drop shadow
* Make the "box shadow" slightly more subtle
* Use --d-border-radius
* Don't scale the "box shadow" on hover
* Scale down the on-hover size
* Make the button slightly larger
* Respect prefers-reduced-motion
* Use white rather than --secondary-or-primary
* Don't animate on-hover on mobile
During extensibility when we add post menu buttons we very much want access
to the topic.
The transformer does not include a `topic` attribute due to historical reasons.
Given we are going to move away from transforming long term and need to give
plugins access to topic when they are adding buttons, just add the extra
property
This commit moves some code out of UploadController#show_secure
so it can be reused in other controllers if a secure upload
needs to have permission checks run.
This commit adds another plugin modifier related to post
actions, similar to ae24e04a5e.
This will be used to exclude users who liked _and_ reacted to
the post, since now in discourse-reactions we make a Like when
a user reacts too. This will affect the display of the post footer.
Recently we changed the code to check permission in the backend. Example PR https://github.com/discourse/discourse/pull/25735
After those changes, `isInAnyGroups` and `userInAnyGroups` functions are not used anymore.
If you upload a portrait video or just a video that doesn't fit in the
normal video dimensions we want it to have a black background instead of
trying to render parts of the placeholder image as the video background.
This change removes the placeholder image for the video background when
the play button is clicked and replaces it with an all black background.
Affects the following settings:
delete_all_posts_and_topics_allowed_groups
experimental_new_new_view_groups
enable_experimental_admin_ui_groups
custom_summarization_allowed_groups
pm_tags_allowed_for_groups
chat_allowed_groups
direct_message_enabled_groups
chat_message_flag_allowed_groups
This turns off client: true for these group-based settings,
because there is no guarantee that the current user gets all
their group memberships serialized to the client. Better to check
server-side first.
Full post jump "SHIFT+K/J" not working if related topics are displayed
Amended logic so we unconditionally use full post jump on topic pages by
checking for .post-stream
The video placeholder play button is white, so on a video placeholder
that is also white it is very hard to see where the play button is, so
this change adds a dark grey transparent background to the play button
so that it stands out. This is similar to how we have done the
play/pause button on animated gifs.
When "lazy load categories" is enabled, only the categories present in
the sidebar are preloaded. This is insufficient because the parent
categories are necessary too for the sidebar to be rendered properly.
The strict-dynamic CSP directive is supported in all our target browsers, and makes for a much simpler configuration. Instead of allowlisting paths, we use a per-request nonce to authorize `<script>` tags, and then those scripts are allowed to load additional scripts (or add additional inline scripts) without restriction.
This becomes especially useful when admins want to add external scripts like Google Tag Manager, or advertising scripts, which then go on to load a ton of other scripts.
All script tags introduced via themes will automatically have the nonce attribute applied, so it should be zero-effort for theme developers. Plugins *may* need some changes if they are inserting their own script tags.
This commit introduces a strict-dynamic-based CSP behind an experimental `content_security_policy_strict_dynamic` site setting.
This commit is the first of a series of commits that will allow themes to define complex settings types by declaring a schema of the setting structure that Discourse core will use to build a UI for the setting automatically. We implement the navigation logic and support for multiple levels of nesting in this commit and we'll continue building this new system gradually in future commits.
Internal topic: t/116870.
Reactions needs this to be able to filter out likes received
actions, where there is also an associated reaction, since
now most reactions also count as a like.
* FEATURE: shift+j and shift+k will scroll entire posts
When scrolling through topics with very long posts we would like to use
`shift+j` and `shift+k` to quickly move between posts.
This allows users to bypass the scroll within post behavior when zooming
through topics with keyboard shortcuts
This overloads the behavior of shift+k and j which can be used to scroll
through sections (new/latest/etc...)
* remove useless tests
These tests are testing nothing, no point carrying them around
When making sensitive changes to an account (adding 2FA or passkeys), we
require users to confirm their password. This is to prevent an attacker
from adding 2FA to an account they have access to.
However, on newly created accounts, we should not require this, it's an
extra step and it doesn't provide extra security (since the account was
just created). This commit makes it so that we don't require session
confirmation for accounts created less than 5 minutes ago.
The `-ping` option significantly speeds up the ImageMagick `identify` command per our testing and the [documentation](https://imagemagick.org/script/command-line-options.php#ping):
> -ping
Efficiently determine these image characteristics: image number, the file name, the width and height of the image, whether the image is colormapped or not, the number of colors in the image, the number of bytes in the image, the format of the image (JPEG, PNM, etc.). Use +ping to ensure accurate image properties.
We already pass the `-ping` option in other places where the `identify` command is used, so it makes sense to use the option everywhere.
Internal topic: t/121431.
This would allow a theme component (or an API call) to reset the bump
date of a topic to a given post's created_at date.
I picked `post_id` as the parameter here because it provides a bit of
extra protection against accidentally resetting the bump date to a date
that doesn't make sense.
I attempted to add a test for related topics, as they are untested. This was a massive challenge as related topics are only rendered after
- a user has stopped typing
- there is a timeout after typing
Between system tests, acceptance tests, and stubbing requests, this was difficult. So here is the pr san test.
Why this change?
Backfilling can take a long time on a site with many users. As a
result, the `DistriburedMutex` will warn in the logs when the block takes
more than 60 seconds to complete. We can increase the lock validity but
the method is currently only called from a job which has a
`cluster_concurrency` set to `1`. Therefore, it is actually not
necessary for us to hold a `DistributedMutex` here.
What does this change do?
1. Removes the distributed mutex and adds a comment about the risk of
calling the `SidebarSiteSettingsBackfiller#backfill!` method.a
2. Delete old sidebar category section links in batches for all users
to avoid a single long running query.
When we launched the new illegal flag type, there were a few problems with the translations:
The translation for the message in the e-mail was missing and in the review queue, the message read: "Is this it's illegal?"
In this PR the missing translation key has been added. For the review queue there was a coupling of the name rendering to whether the flag is of "custom" type, but this is also used for deciding whether we render the textbox for additional details. I think these two things should not be coupled together. For now I have instead hard-coded the existing "custom" types when formatting the name. We can potentially improve this later.
This commit was created with a combination of the ember-native-class-codemod and manual cleanup.
User-status-related functionality was previously encapsulated in its own `User.reopen` call, which is essentially an 'inline mixin'. This commit refactors it into a utility class, with an instance accessible on `User#statusManager`
`create topic allowed groups` site setting controls permission to create a new topic.
If a user cannot create a topic, a reply as a new topic button should not be visible as well.
The only addition is PosterSerializer is this:
discourse/app/serializers/poster_serializer.rb
Line 4 in 4a5616f
Which allows themes to check the posters' primary group!
This commit includes several changes to make hashtags work when "lazy
load categories" is enabled. The previous hashtag implementation use the
category colors CSS variables, but these are not defined when the site
setting is enabled because categories are no longer preloaded.
This commit implements two fundamental changes:
1. load colors together with the other hashtag information
2. load cooked hashtag data asynchronously
The first change is implemented by adding "colors" to the HashtagItem
model. It is a list because two colors are returned for subcategories:
the color of the parent category and subcategory.
The second change is implemented on the server-side in a new route
/hashtags/by-ids and on the client side by loading previously unseen
hashtags, generating the CSS on the fly and injecting it into the page.
There have been minimal changes outside of these two fundamental ones,
but a refactoring will be coming soon to reuse as much of the code
and maybe favor use of `style` rather than injecting CSS into the page,
which can lead to page rerenders and indefinite grow of the styles.
When we show the links to installed plugins in the admin
sidebar (for plugins that have custom admin routes) we were
previously only doing this if you opened /admin, not if you
navigated there from the main forum. We should just always
preload this data if the user is admin.
This commit also changes `admin_sidebar_enabled_groups` to
not be sent to the client as part of ongoing efforts to
not check groups on the client, since not all a user's groups
may be serialized.
When we insert into the hot set we add things with a score of 0
This means that if hot has more than batch size items in it with a score, then the 0s don't get an initial score
This corrects the situation by always ensuring we re-score:
1. batch size high scoring topics
2. (new) batch size recently bumped topics
* Update spec/models/topic_hot_scores_spec.rb
Co-authored-by: Isaac Janzen <50783505+janzenisaac@users.noreply.github.com>
---------
Co-authored-by: Isaac Janzen <50783505+janzenisaac@users.noreply.github.com>
Removes duplication from LimitedEdit to see who can edit
posts, and also removes the old trust level setting check
since it's no longer necessary.
Also make it so staff can always edit since can_edit_post?
already has a staff escape hatch.
Why this change?
This commit introduces an experimental `type: objects` theme setting
which will allow theme developers to store a collection of objects as
JSON in the database. Currently, the feature is still in development and
this commit is simply setting up the ground work for us to introduce the
feature in smaller pieces.
What does this change do?
1. Adds a `json_value` column as `jsonb` data type to the `theme_settings` table.
2. Adds a `experimental_objects_type_for_theme_settings` site setting to
determine whether `ThemeSetting` records of with the `objects` data
type can be created.
3. Updates `ThemeSettingsManager` to support read/write access from the
`ThemeSettings#json_value` column.
Affects the following settings:
* whispers_allowed_groups
* anonymous_posting_allowed_groups
* personal_message_enabled_groups
* shared_drafts_allowed_groups
* here_mention_allowed_groups
* uploaded_avatars_allowed_groups
* ignore_allowed_groups
This turns off `client: true` for these group-based settings,
because there is no guarantee that the current user gets all
their group memberships serialized to the client. Better to check
server-side first.
When enabled, the workbox caching logic in the service worker will be replaced with a very simple offline error page. We plan to use this as an experiment to see how it affects performance and stability of Discourse.
This commit also updates a handful of simple adapters which overrode the jsonMode or primaryKey options. These updates are necessary because class fields cannot be overwritten via `EmberObject`'s `.extend()` syntax. These options do not appear to be widely used by themes/plugins.
Why this change?
This is caused by a regression in
59839e428f, where we stopped saving the
`Theme` object because it was unnecessary. However, it resulted in the
`after_save` callback not being called and hence
`Theme#update_javascript_cache!` not being called. As a result, some
sites were reporting that after runing a theme migration, the defaults
for the theme settings were used instead of the settings overrides
stored in the database.
What does this change do?
Add a call to `Theme#update_javascript_cache!` after running theme
migrations.
Some versions of Firefox will throw a TypeError when calling
PublicKeyCredential.isConditionalMediationAvailable() because the
method does not exist. That would previously lead to a "Sorry, an error
has occurred." modal when trying to login.
This commit fixes the issue by properly checking if the method exists.
Since it only affects older Firefox versions, no tests are added.
We had two issues which were present for a long time I think:
- one that impacts both core discourse and chat. We were not setting top on the header when `footer-nav-ipad` was present, meaning that you could make it scroll under if you try to scroll up by putting your finger on the discourse header
- one that impacted only chat. It's also present in core, but in core it's not a probem because we don't have a fixed height div. The body height was higher than the screen which would cause a second scrollbar to appear and would slightly break layout, if you scroll on this scrollbar (body).
This fixes a bug where the sidebar categories would not be loaded when
the categories were lazy loaded because the sidebar uses the preloaded
category list, which was empty.
We just completed the 3.2 release, which marks a good time to drop some previously deprecated columns.
Since the column has been marked in ignored_columns, it has been inaccessible to application code since then. There's a tiny risk that this might break a Data Explorer query, but given the nature of the column, the years of disuse, and the fact that such a breakage wouldn't be critical, we accept it.
1. Don't show visited line for hot filter, it is in random order
2. Don't count likes on non regular posts (eg: whispers / small actions)
3. Don't count participants in non regular posts
Checking group permissions on the client does not work,
since not all groups are serialized to the client all
the time. We can check `uploaded_avatars_allowed_groups`
on the server side and serialize to the current user
instead.
Since https://github.com/discourse/discourse/pull/25501 this behavior was broken. This PR attempts to fix it by being more fine grain.
Also note that this PR is moving `footer-nav-ipad` and `footer-nav-visible` to the `html` element and not the `body`. It makes more sense as we are already adding most of other global state class like `keyboard-visible` to the `html` element.
Tested on:
- chrome desktop
- safari ios - iphone
- PWA ios - iphone
- PWA ios - ipad
- DiscourseHub iphone
1. Serial likers will just like a bunch of posts on the same topic, this will
heavily inflate hot score. To avoid artificial "heat" generated by one user only count
the first like on the topic within the recent_cutoff range per topic
2. When looking at recent topics prefer "unique likers", defer to total likes on
older topics cause we do not have an easy count for unique likers
3. Stop taking 1 off like_count, it is not needed - platforms like reddit
allow you to like own post so they need to remove it.
Why this change?
Returning an array makes it hard to immediately retrieve a setting by
name and makes the retrieval an O(N) operation. By returning an array,
we make it easier for us to lookup a setting by name and retrieval is
O(1) as well.
This commit sets a default of 0px for `--footer-nav-height` and set it only when `body.footer-nav-visible` allowing us to safely use `--footer-nav-height` wherever it will be needed if set.
This change removes the regex we used previously, which only allowed ASCII characters in fast-edit. Now multi-language content can be used with fast-edit.
It also removes the string replacement we relied on in the past to catch various forms of punctuation marks, as this no longer appears necessary (possibly since this component was updated to use Glimmer).
The `deprecate_column` helper would change its behavior based on the current `Discourse::VERSION`. This means that 'finalizing' a stable release introduces a previously untested behavior change.
Much better to keep it as a deprecation until manual action is taken to introduce the breaking change.
These routes were previously rendered using Rails, and had a fairly fragile 2fa implementation in vanilla-js. This commit refactors the routes to be handled in the Ember app, removes the custom vanilla-js bundles, and leans on our centralized 2fa implementation. It also introduces a set of system specs for the behavior.
Internal links always notify and add internal connections in topics.
This adds a special feature that lets you append `?silent=true` to a link
to have it excluded from:
1. Notifications - users will not be notified for these links
2. Post links below posts in the UI
This is specifically useful for large reports where adding all these connections
just results in noise.
Safari has a bug which means that scripts with the `defer` attribute are executed before stylesheets have finished loading. This is being tracked at https://bugs.webkit.org/show_bug.cgi?id=209261.
This commit works around the problem by introducing a no-op inline `<script>` to the end of our HTML document. This works because defer scripts are guaranteed to run after inline scripts, and inline scripts are guaranteed to run after any preceding stylesheets.
Technically we only need this for Safari. But given that the cost is so low, it makes sense to include it everywhere rather than incurring the complexity of gating it by user-agent.
Running Discourse 3.2 stable under Ember 3 will technically be possible, but is only intended as a short-term migration point. This commit adds an admin warning for sites which are using this configuration, to make it clear that themes and plugins are unlikely to support the configuration.
https://meta.discourse.org/t/287211
In a handful of situations, we need to verify a user's 2fa credentials before `current_user` is assigned. For example: login, email_login and change-email confirmation. This commit adds an explicit `target_user:` parameter to the centralized 2fa system so that it can be used for those situations.
For safety and clarity, this new parameter only works for anon. If some user is logged in, and target_user is set to a different user, an exception will be raised.
When exporting a csv file and the size of the file exceeded the
max_export_file_size_kb it will still send the PM that the export
succeeded with a broken link to a missing export file. This change
ensures that a failed message will be sent instead.
* Revert "FEATURE: Use native number fields for integer inputs (#24984)"
This reverts commit 8fce890ead.
* FIX: Deprecate NumberField, use <input> instead
This reverts #24984 as it introduced regressions (behavioral and visual) and instead it deprecates the NumberField component and replaces its uses in core with native `<input>` elements.
CategoryRow component uses allowUncategorized SelectKit option to
decide whether to show the "Uncategorized" category or not. This was
undefined which lead to "Uncategorized" category being always hidden
causing a minor visual glitch.
Currently when exporting a list of users and there is an error we just
log that there was an error, but we don't show what the issue is in the
logs which makes it really hard to debug in production. This change will
output any errors to the logs.
Some parts of our code (e.g. some types of reviewable) set `topic.category`. In the past this would override the computed property value, but with recent Ember it raises an error. This commit adds a setter which handles the situation cleanly
Having the admin sidebar code in an instance initializer is not
ideal because:
* It runs during app boot which may not even be necessary based on site settings
* It makes it hard for plugins to register additional links in time without resorting
to before/after initializer gymnastics
This PR moves the admin sidebar into a lib and creates the panel
in custom-sections.js, then the sections and links are loaded when
the main sidebar component is rendered, which leaves plugins enough
time to add additional links in an initializer.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
We want to exclude the system user from group user counts, since intuitively admins wouldn't include them.
Originally this was accomplished by booting said system user from the groups, but this is causing problems, because the system user needs TL group membership to perform certain tasks.
After this PR, system user is still in the TL groups, but excluded when refreshing the user count.
Previously, it was not possible to modify the sorting order of the `TopicQuery` result from a plugin. This feature adds support to specify custom sorting functionality in a plugin. We're using the `apply_modifier` method in the `DiscoursePluginRegistry` module to achieve it.
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
Some preparatory refactoring as we're working on TL groups for the system user. On User we have a scope #human_users to exclude the system user, DiscoBot, etc. This PR adds the same scope (delegated to User) on Group.
* FIX: Minor bookmark issues
* We were showing "missing %{name} value" when the name for the
bookmark was undefined with title translations
* There was no way to see the bookmark details on hover in chat
for a message where the bookmark icon was in the left gutter.
We can show the title on the bookmark button in the chat message
actions instead.
* Minor fix
* DEV: Test fix
We added support for radar type charts in #24274. However, radar charts work with three variables, meaning we can't display any report that way.
Unfortunately, by adding `:radar` to the `Report#modes` variable, I made them widely available.
Related bug report: https://meta.discourse.org/t/report-radar-graph-uncaught-typeerror/292360
The keydown event fires as soon as the key is pressed down. This is often preferred for actions that need to occur immediately, like stopping a process, closing a modal window, or canceling an ongoing operation. The immediacy of keydown makes it more responsive, as the user doesn't have to fully press and release the key.
Moreover, it allows us to not close chat on escape when the search menu is open.
This is a temporary fix to address an issue where the
system user is losing its automatic groups when the server
is running. If any auto groups are provided, and the user is
a system user, then we return true. The system user is admin,
moderator, and TL4, so they usually have all auto groups.
We can remove this when we get to the bottom of why the auto
groups are being deleted.
We're changing the implementation of trust levels to use groups. Part of this is to have site settings that reference trust levels use groups instead. It converts the min_trust_level_for_user_api_key site setting to user_api_key_allowed_groups.
This isn't used by any of our plugins or themes, so very little fallout.
