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.
https://github.com/discourse/discourse-solved/pull/342 was deployed and observed to only have 5000 (batch size) migrated. This is an error in migration where the ids had a gap between the batch.
This PR changes the migration to just loop through all topic custom fields with each loop increasing by batch size.
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
…in the new topic-status implementation (using the next `@context` from https://github.com/discourse/discourse/pull/30940)
This roughly matches the old implementation (but there it was displayed in some places but not in others mostly because of implementation details/bugs)
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:
https://github.com/discourse/discourse/blob/56524f4bdf9d45eddf7967ccead169ec6dd6cbb8/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
Natalie Tay
chapoi
Discourse Translator Bot
Jarek Radosz
dependabot[bot]
Régis Hanol
David Taylor
Roman Rizzi
KelvandJarek Radosz
Sérgio Saquetim
Gabriel Grubba
Osama Sayegh
Natalie Tay
David McClure
Kris