Related to https://github.com/discourse/discourse/pull/12688.
The tags and categories count queries are failing on Rails 6.1 with `ERROR: column "topics.bumped_at" must appear in the GROUP BY clause or be used in an aggregate function`. The reason these queries didn't fail prior to 6.1 was because Active Record would automatically drop the `ORDER BY` clause from the queries when we called `count` on them. This behavior has been [changed](5812feffe3) in 6.1 so now Active Record only drops the `ORDER BY` clause if there is no `GROUP BY` clause. Our queries do have `GROUP BY` clauses, so we need to drop the `ORDER BY` clauses ourselves before we call `count` to make them work on 6.1.
Linking directly to a Docs item like so `http://localhost:3000/docs?topic=16` would result in a generic inline onebox link. This adds logic to the Rails view so a proper title is rendered when the `InlineOneboxer` in core queries the route.
Core made buttons to use flexbox recently, which changed the behavior of
the go back button on Docs topics. The local justify-content declaration
overrides the core declaration causing problems.
After internal discussion, the team decided to rename this plugin to `discourse-docs`. No substantial changes made here aside from a settings migration.
We recently merged a Discourse core's PR to replace usages of Ember's debounce and discourseDebounce with a new debounce wrapper. The new wrapper works exactly like Ember's debounce but internally calls "run" when called in test mode.
This PR replaces all usages of other debounce functions with the new wrapper and fallbacks to Ember's debounce for backward-compatibility.
There was a weird case where when filtering topics by solved status did not properly show the count of filtered topics. I took this opportunity to lightly refactor the backend. There was a duplicate size operation when we searched and when calculating pagination. I've eliminated the second size call and refactored the front end to be a little bit simpler while solving the bug.
In many cases it makes sense to show muted topics in the Knowledge Explorer view. One such case might be if a user mutes a documentation category, but wants to be able to search them via this plugin.
To implement this, I've called TopicQuery.default_results via an added class method, which does the same thing as latest_results except skips the muted topics removal.
One issue I ran into with this is with the no_definitions option set to true, the query was not able to see the categories table. This appears to work correctly in core as I dug into it, but was not able to root out the source of the issue in the plugin. Everything seems to be generated correctly compared to how core methods use TopicQuery, but this issue remained. This is the reason for the results.references(:categories) call on line 25 of query.rb, as then the query can properly access the categories table.
Pre-loading/pre-assigning isn't necessary. `Topic.category` uses `Category.findById` which in turn uses an identity map, so there are no N+1 calls to the backend.
In Spec we were creating two topics:
```ruby
fab!(:topic) { Fabricate(:topic, category: category) }
fab!(:topic2) { Fabricate(:topic, category: category) }
```
Because we didn't set title explicitly it was using sequence from Fabricator
```ruby
title { sequence(:title) { |i| "This is a test topic #{i}" } }
```
If you have two titles `This is a test topic 9` and `This is a test topic 10` Spec testing if topics are sorted will fail. Therefore, we should explicitly set topic title when creating test instances to avoid that randomness.
After implementing changes to tagging, this introduced ambiguity in the SQL query for sorting by activity. This commit fixes the ambiguity by explicitly defining the table from where the columns are used. Also adds tests to check for regressions in the future.
When using a single Ember route, the query param filters did not
properly reset when, for example, clicking the Knowledge Explorer link
in the hamburger menu.
This commit introduces a subroute where most of the logic takes place.
We needed a subroute so that refresh doesn't take out the entire UI part.
This allows us to use the `refreshModel` option for query params on the
route and remove the refresh controller action. Doing so also retains
state of the search field instead of fully reloading the parent route.
If using more than two tags to filter, we'd run into an SQL alias
collision on a few joins. Resolved by ensuring unique names are used across the query.
Previously you had to clear the search results out by deleting them.
This introduces a friendlier way to clear the search UX, especially if
you didn't find what you're looking for.
When trying to onebox topics, the canonical URL overrides the generated
OpenGraph tags, causing a less than ideal onebox for a linked KE
article.
This commit uses the existing options for the `crawlable_meta_data`
method to generate the `og:ignore_canonical` tag.
1504fe7231/app/helpers/application_helper.rb (L267-L269)