We're expecting the tags parameter to be a string. But the client can send an array or a nested parameter (thanks to the Rack protocol.) We're seeing exceptions in logs where the application is erroring out because of this.
As of this commit we raise a Discourse::InvalidParameters exception if we get a non-stringy tags parameter.
Not all categories are preloaded when lazy_load_categories is enabled.
In this case, the category objects that are loaded through /docs.json
must be complete.
* 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>
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.
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 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.
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.
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.
Previously search was only searching through the title of topics
This introduces full text search.
It also means we get automatic stemming which gives far better results.
* Create custom query lib file
* Get topic list by category
* Get topic list with both categories and tags
* Count tags and pass back to controller in object
* Filter topic list by param-passed tag list
* FIX: Correctly serialize topic list data
* Filter results by search term (title only
* Debug commit
* Working multi-tag filtering
* FIX: case insensitive search terms
* Begin refactor of front end for new api changes
* REFACTOR: Use model for refreshing data
Instead of just using a route, which introduces full page refreshes, use
the route to pull the data initially, then update it using a model as to
refresh only the relevant parts of the page.
* Working topic load
* FIX: Visual alignment
* Refactor tests to follow new patterns
* Fixes suggested by eviltrout
* FEATURE: Load more topics
* FIX: Paginate records on return to the front end in a better fashion
* FIX: Prevent loadMore while loading more
* Fix pagination of topics to truncate list properly
* Inherit rubocop from discourse
* Make rubocop happynated
* Set list to unordered
Ted Johansson
Bianca Nenciu
Loïc Guitaut
Jean
David Taylor
Penar Musaraj
Frank
Krzysztof Kotlarek
Justin DiRose
Sam Saffron