This PR improves the performance of the `most_replied_to_users` method on the `UserSummary` model.
### Old Query
```ruby
post_query
.joins(
"JOIN posts replies ON posts.topic_id = replies.topic_id AND posts.reply_to_post_number = replies.post_number",
)
# We are removing replies by @user, but we can simplify this by getting the using the user_id on the posts.
.where("replies.user_id <> ?", @user.id)
.group("replies.user_id")
.order("COUNT(*) DESC")
.limit(MAX_SUMMARY_RESULTS)
.pluck("replies.user_id, COUNT(*)")
.each { |r| replied_users[r[0]] = r[1] }
```
### Old Query with corrections
```ruby
post_query
.joins(
"JOIN posts replies ON posts.topic_id = replies.topic_id AND replies.reply_to_post_number = posts.post_number",
)
# Remove replies by @user but instead look on loaded posts (we do this so we don't count self replies)
.where("replies.user_id <> posts.user_id")
.group("replies.user_id")
.order("COUNT(*) DESC")
.limit(MAX_SUMMARY_RESULTS)
.pluck("replies.user_id, COUNT(*)")
.each { |r| replied_users[r[0]] = r[1] }
```
### New Query
```ruby
post_query
.joins(
"JOIN posts replies ON posts.topic_id = replies.topic_id AND posts.reply_to_post_number = replies.post_number",
)
# Only include regular posts in our joins, this makes sure we don't have the bloat of loading private messages
.joins(
"JOIN topics ON replies.topic_id = topics.id AND topics.archetype <> 'private_message'",
)
# Only include visible post types, so exclude posts like whispers, etc
.joins(
"AND replies.post_type IN (#{Topic.visible_post_types(@user, include_moderator_actions: false).join(",")})",
)
.where("replies.user_id <> posts.user_id")
.group("replies.user_id")
.order("COUNT(*) DESC")
.limit(MAX_SUMMARY_RESULTS)
.pluck("replies.user_id, COUNT(*)")
.each { |r| replied_users[r[0]] = r[1] }
```
# Conclusion
`most_replied_to_users` was untested, so I introduced a test for the logic, and have confirmed that it passes on both the new query **AND** the old query.
Thank you @danielwaterworth for the debugging assistance.
We will be collecting the logo URL and the site's default locale values along with existing basic details to display the site on the Discourse Discover listing page. It will be included only if the site is opted-in by enabling the "`include_in_discourse_discover`" site setting.
Also, we no longer going to use `about.json` and `site/statistics.json` endpoints retrieve these data. We will be using only the `site/basic-info.json` endpoint.
- Add a "Skip tips" button to first notification tip
- Add a "Skip tips" button to the admin guide tip
- Fixes the timeline tip showing when no timeline was present
- Fixes post menu tip showing when no "..." button is present
- Adds system tests
- Marks each tip as seen as soon as it is displayed so that refreshing,
clicking outside, etc. won't show it again
- Change just above means we no longer need a MessageBus track
Co-authored-by: Bianca Nenciu <nbianca@users.noreply.github.com>
Some of the properties, like 'categoriesById', 'parentCategory' and
'subcategories', were updated manually when categories were loaded.
This was not ideal because it required a lot of code to keep the
objects in sync and some of the properties were not updated correctly.
Why this change?
Instead of dealing with a generic object for `Theme#settings`, we want
to always be dealing with `ThemeSettings` objects.` Previously, we
converted the generic objects to `ThemeSettings` objects in the theme's
adapter `afterFindAll` function. This is not correct because updating
or saving the theme individual reverted the `Theme#settings` back to an
array of generic object.
To fix this problem, the proper way with our REST models is to overwrite
the static `munge` method and create `ThemeSettings` instances there.
When a user is manually deactivated, they should not be deleted by our background job that purges inactive users.
In addition, site settings keywords should accept an array of keywords.
Originally we planned to do this rename after dropping the old widget implementation. However, as we continue rolling out the update, there is a risk that people will start depending on the component names (e.g. for modifyClass) so it seems best to make the rename now to reduce risk later.
In this PR, all references in the UI to the word "`upgrade`" are changed to "`update`". This is to differentiate the update process in self-hosted sites from the plan "upgrade" process in hosted sites.
Follow-up to the PR: https://github.com/discourse/docker_manager/pull/208
Plugins that are hidden or disabled aren't shown in the plugins list at `/admin/plugins` because they cannot be changed. However, the `#show` route doesn't check for the plugin's state and responds with 200 and the plugin's info even if the plugin is hidden or disabled. This commit makes the `#show` route respond with 404 if the plugin is hidden or disabled.
Prior to this fix the `swipe` modifier could not be disabled and we were not using the `this.dimissable` property to apply/not apply it.
This commit adds a new `enabled` param to the `swipe` modifier, which is used in modals with the value of `this.dismissable`.
Note this commit also adds tests for this modifier.
Why this change?
Before this change, the validation error message shown to the user when
saving a theme objects setting is very cryptic. This commit changes the
validation error messages to be displayed on top of the editor instead.
Note that I don't think this way of displaying is the ideal state we
want to get to but given the time we have this will do for now.
Why this change?
In the categories, groups and tags selectors, we were showing a
validation error message when a property that is not required but
has a min validation is empty. In this case, we should not be displaying
the min validation error message because the property is allowed to be
empty.
Why this change?
When adding a new object, we want to switch to the input fields of the
new object instead of just appending the new object to the list of
objects as we believe this is a better UX flow.
Why this change?
The field components to select categories, groups and tags had quite a
bit of logic duplicated between them. This commit refactors the logic
to remove most of the duplication so that we can introduce changes
without having to make the changes in multiple places.
* DEV: Various bulk-select dropdown tweaks
- Setting is no longer hidden
- descriptions have been moved to the modal
- Removed ... from one of the dropdown titles
This adds a hidden site setting of `skip_email_bulk_invites`
If set to `true`, the `BulkInvite` job will pass the value to `Invite`, meaning the generated invite wont trigger an email notification being sent to the newly invited user.
(This is useful if you want to manage the sending of the invite emails outside of Discourse.)
... rather than just the category id.
In order for the user to have selected a category, the category must
have been loaded and it's useful for the category chooser to provide
this fetched category so that it doesn't need to be refetched.
In the future, it would be better to store the categories that the
chooser knows about in local component state, so that the category
doesn't need to be fetched from the id map, but this, at least, puts the
API in place.
Why this change?
This is a follow-up to 86b2e3a.
Basically, we want to allow people to select more than 1 group as well.
What does this change do?
1. Change `type: group` to `type: groups` and support `min` and `max`
validations for `type: groups`.
2. Fix the `<SchemaThemeSetting::Types::Groups>` component to support the
`min` and `max` validations and switch it to use the `<GroupChooser>` component
instead of the `<ComboBoxComponent>` component which previously only supported
selecting a single group.
Why this change?
Prior to this change, the `SchemaThemeSetting::Editor#tree` was creating a
new `Tree` instance which holds instances of `Node`. Both classes
consisted of tracked properties. The problem with this approach is that
when any tracked properties is updated, Ember will revaluate
`SchemaThemeSetting::Editor#tree` and because that method always return
a new instance of `Tree`, it causes the whole navigation tree to
rerender just because on tracked property changed.
This rerendering of the whole navigation tree every time made it hard to
implement simple features like hiding a section in
9baa820d53. Instead of being able to just
declare a tracked property to hide/show a section, we end up with a more
complicated solution.
This commit rewrites `SchemaThemeSetting::Editor` to depend on Ember
components to form the tree structure instead. As needed, each component
in the tree structure can declare its own tracked property as necessary.
