Earlier on in the migration, the update of the user directory query was erroneously switched to use post creation date instead of the date the post was solved.
This commit fixes that.
When an answer already exists, clicking "✅ Solution" on another post works, but does not commit.
This commit fixes that and also adds a test, and a transaction around accepting a solution (deleting the topic timer, previous user action, etc).
There are three locations where a user's solution query is defined
- user summary
- user card
- user directory
This PR updates the queries to use data from the new `SolvedTopics` table instead of the `UserActions` table. And adds testssssss
As part of https://github.com/discourse/discourse-solved/pull/342, some discrepancies in the old implementation resulted in solved topics linking to posts that do not exist (dangling custom field value). Causing us to see the following when there are no `answer_post`
```
NoMethodError (undefined method `user' for nil)
```
This PR prevents the error.
We are seeing some errors when migrating and adding indexes on `answer_post_id`.
```
#<StandardError:"An error has occurred, all later migrations canceled:\n\nPG::UniqueViolation: ERROR: could not create unique index \"index_discourse_solved_solved_topics_on_answer_post_id\"\nDETAIL: Key (answer_post_id)=(13006) is duplicated.\n">
```
This PR modifies the earlier migration, and also adds one before the addition of indexes to remove duplicates.
This commit autoloads plugin files, and also extracts features into their own modules.
- `plugin.rb` is smaller
- external plugins like discourse-automation and discourse-assign have their own entrypoints
- solved filters as well
* FIX: don't allow or count solutions in PMs
Pretty straightforward, this ensures we don't allow users to mark a post
as a solution in a PM.
This also ensures we don't count solutions in topics that were converted
to a PM.
Internal ref t/146766
A while ago the `accept_all_solutions_allowed_groups` setting was introduced to replace the `accept_all_solutions_trust_level` setting and to make the plugin more flexible by allowing admins to choose groups that are allowed to accept solutions instead of trust levels.
The new group-based setting includes the TL4 group by default. However, removing the TL4 group from the setting doesn't actually remove TL4 users permission to accept solution.
The reason for this bug is that the `can_accept_answer?` guardian method calls `can_perform_action_available_to_group_moderators?` which always allows TL4 users to perform category moderator actions:
56524f4bdf/lib/guardian/topic_guardian.rb (L342-L348)
This commit fixes the bug by checking if the user is a moderator on the topic's category (by calling the `is_category_group_moderator?` guardian method) instead of checking if the user can perform category moderator actions. In our case, `is_category_group_moderator?` is equivalent to `can_perform_action_available_to_group_moderators?` except for the TL4 check which is what we need.
Internal topic: t/134675.
it would raise an error because we delete the topic before and we need the topic record to update various meta data.
This ensures we load the "deleted" version in such cases.
Internal ref - t/130797
* FEATURE: change status on unsolve & fix assign changes
When a topic is unsolved, it should have an option,
defined in the settings, to change its status to that state.
Fix assign changes when a topic was solved, previously it was
changing the assignee.
* DEV: Change names in tests and remove comments
* DEV: Update change status on solve implementation
Update tests to verify that the change status on solve feature is working as expected.
Change the implementation to loop throught the topic assignments and update the status.
* DEV: address review feedback
* FEATURE: Prevents assign notification & change status on solved
Relates to this [topic](https://meta.discourse.org/t/assign-plugin-for-informatica/256974/94)
Add an event listener to `accepted_solution` event
Add `assigns_reminder_assigned_topics_query` modifier to not notify if
`prevent_assign_notification` setting is on.
Add settings to prevent assign notification and change status on solved
* DEV: Address review comments
Update SiteSettings names.
* DEV(WIP): Add tests for integration with discourse-assign
Add test for integration with discourse-assign plugin
checks if the assignment status is moved to `Done`
* DEV: lint solved_spec.rb
* DEV: Update test where it updates all assignments
Change `on(:accepted_solution)` is defined
Update test to use acting_user instead of admin
* DEV: lint & add tests for assigns_reminder_assigned_topics_query
Linted and added tests for `assigns_reminder_assigned_topics_query` modifier.
* DEV: Update tests based on review feedback
change plugin_initializer location
update spec with new tests to test integration with discourse-assign
* DEV: Add describe to spec for discourse-assign integration tests
* DEV: update describe name for discourse-assing spec integration
* DEV: Add more tests to spec for discourse-assign integration
* DEV: Lint solved_spec
* DEV: Lint and update spec to not have `p1` topic inside
* FEATURE: add new custom status filters
Those can be used in /filter route.
Depends on https://github.com/discourse/discourse/pull/26770
Internal ref. /t/127278
* DEV: pin plugin for Discourse 3.3.0.beta2-dev
When using the `status:unsolved` search filter, the plugin was only
returning results from topics in categories where solved was enabled.
This commit changes the search query to also include topics with tags
that have solved enabled via the `enable_solved_tags` site setting.
This fixes the `status:unsolved tags:tag1` search query.
This refactor makes for easier testing and makes things
more organised, the guardian extensions had no testing
whatsoever and I need some to make the TL -> group change.
We're updating core to change TL based access settings to be group based. This requires some updates of tests to work correctly. (The existing test setup gives false positives.)
In https://github.com/discourse/discourse/pull/24740, `min_trust_to_create_topic` site setting was replaced by `create_topic_allowed_groups`. This PR replaces the former, deprecated one, with the latter.
c.f. de983796e1b66aa2ab039a4fb6e32cec8a65a098
There will soon be additional login_required checks
for Guardian, and the intent of many checks by automated
systems is better fulfilled by using BasicUser, which
simulates a logged in TL0 forum user, rather than an
anon user.
Ensures we remove the solution when the post marked as the solution is deleted.
DEV: Added `IS_ACCEPTED_ANSWER_CUSTOM_FIELD` constant.
DEV: Refactored the `PostSerializer` for better readability.
PERF: Improved the `TopicViewSerializer`'s performance by looking up the `accepted_answer_post_info` from the stream first.
Internal ref. dev/112251
Many consumers of Discourse solved may want solved topics to show up more
prominently in search. New setting `prioritize_solved_topics_in_search` (default off) allows
bumping these topics to the top.
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
* FEATURE: solved topic auto close setting per category
This commit adds per category "solved topics auto close hours" setting. The plugin would use the existing "solved topics auto close hours" setting, except if there was a setting for the relevant category in which case that would take precedence.
* minor changes per feedback
See https://github.com/discourse/discourse/pull/18437,
we are removing any references to enable_personal_messages
in core and using only personal_message_enabled_groups,
which requires auto groups to be assigned in certain specs
for them to keep working.
This PR adds a site setting called `enable_solved_tags`. Solved will be enabled for topics containing these tags, just like we do for specific categories.
Sérgio Saquetim
Loïc Guitaut
Natalie Tay
Régis Hanol
Gabriel Grubba
Osama Sayegh
Penar Musaraj
Martin Brennan
Jarek Radosz
Ted Johansson
Krzysztof Kotlarek
Arpit Jalan
Juan David Martínez Cubillos
Sam
David Taylor
Joffrey JAFFEUX
Roman Rizzi
Bianca Nenciu
Arpit Jalan