In some cases, when having multiple tag filters selected and results in the list, deselecting one of the filters would cause no results. This is clearly incorrect behavior, as fewer filters should lead to more (or at least the same number of) results.
This happens when you have a list of selected filters, e.g. `foo|bar|baz`, and you deselect the "middle" one. This will result in the following filter: `foo||baz`, which causes the back-end to try and filter on empty string as well, and in turn leads to no results.
The order of the filter list depends on the order they were selected, which caused this to seem a bit erratic.
In the code, there's a regular expression that tries to remove consecutive `|` characters, but this is anchored to the beginning of the string, so it doesn't work for this case.
Instead of relying on a regular expression, this change splits the string into an array, filters out the deselected tag, and joins it back together into the filter string. This avoids the issues that regular expressions have.
The PR also includes unit tests for the three code paths of the filter selection.
* FEATURE: add a global setting to support custom docs url path
This commit adds a GlobalSetting `docs_path` to support custom docs url
path for sites that do not want docs page to live at `/docs` and have a
customized path.
* Fixed the route declaration
* Test and linting
* Update server.en.yml
* Fixed doc test
* Fixed linting.
* Testing qunit test fix
* Fixed tests
* Prettified tests
* Changed the implementation from SiteSetting to GlobalSetting instead.
* Fixed tests
* Cleanup
* Using Site instead of .js.erb to pass GlobalSetting.docs_url to the front end.
Also fixed front end tests
* Remove references to obsolete site setting
* remove unused fixture file
* Rename `docs_url` to `docs_path` and use camelCase in JavaScript
* Add serializer tests
Co-authored-by: Arpit Jalan <er.ajalan@gmail.com>
We can rip out the `click` handler completely and just lean on the _logic_ we have in `docs-index`.
0cef82aec0/assets/javascripts/discourse/routes/docs-index.js (L12)
It will always refresh the `selectedTopic` so there will be no need to update it within the click handler. Which then nullifies the need for `setSelectedTopic`.
When a documentation topic is viewed, corresponding TopicViewItem and TopicUser should be created.
A method from a TopicController is called, however, specs should warn us if ever that core method would change.
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.
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.
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.
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.
Currently linking directly to Knowledge Explorer topics shows a generic onebox, which isn't super helpful in some cases.
This commit mimics how the theme creator plugin handles adding metadata to special occurrences. However, to get this to work, how the plugin handles showing topic contents needed to be refactored. Instead of hitting the existing topic route, the plugin implements its own version of this, including adding restrictions for topics that are not in a selected Knowledge Explorer category or tag.