Discource-C
/
discourse-solved
mirror of https://github.com/discourse/discourse-solved.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
discourse-solved/config/settings.yml

60 lines
1.4 KiB
YAML
Raw Normal View History

DEV: Change settings root from plugins: to discourse_solved (#267) This is so the plugins settings are better categorized in the site settings UI.
2023-11-12 19:24:04 -05:00
discourse_solved:
FEATURE: add solved enabled key
2017-02-02 12:20:01 -05:00
solved_enabled:
default: true
client: true
FEATURE: site setting to enable solved globally
2015-06-19 02:08:43 -04:00
allow_solved_on_all_topics:
default: false
client: true
Allow TL4 users to accept answers (configurable via site setting)
2016-03-30 21:06:03 -04:00
accept_all_solutions_trust_level:
default: 4
client: true
DEV: Change accept_all_solutions_trust_level to group setting (#276) 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.
2024-01-22 20:45:32 -05:00
enum: "TrustLevelSetting"
hidden: true
accept_all_solutions_allowed_groups:
FIX: Don't allow TL4 users to unconditionally accept solutions (#305) 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.
2024-08-09 07:59:28 -04:00
default: "1|2|14" # auto group admin, moderators and trust_level_4
UX: Add admins and moderators to mandatory_values for accept_all_solutions_allowed_groups (#290)
2024-05-12 14:25:57 -04:00
mandatory_values: "1|2" # auto group admins, moderators
DEV: Change accept_all_solutions_trust_level to group setting (#276) 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.
2024-01-22 20:45:32 -05:00
type: group_list
client: false
allow_any: false
refresh: true
validator: "AtLeastOneGroupValidator"
Added empty box icon to unsolved topics
2017-02-27 10:00:04 -05:00
empty_box_on_unsolved:
default: false
client: true
UX: Show configurable length excerpt when quoting the solution
2017-03-08 10:21:41 -05:00
solved_quote_length:
100 is way too short
2017-03-08 15:02:40 -05:00
default: 300
UX: Show configurable length excerpt when quoting the solution
2017-03-08 10:21:41 -05:00
client: false
FEATURE: Add `solved_topics_auto_close_hours` site setting. https://meta.discourse.org/t/automatically-close-solved-topics-after-n-hours/58383
2017-05-22 05:09:40 -04:00
solved_topics_auto_close_hours:
default: 0
FIX: Add min/max values for auto close hours (#121) * Also add migration to cap current site settings for solved_topics_auto_close_hours to the max of 175000 if they are too high
2021-02-17 22:49:39 -05:00
min: 0
max: 175200 # 20 years
FEATURE: Show dropdown to filter topic lists by solved status
2019-03-13 15:11:07 -04:00
show_filter_by_solved_status:
default: false
client: true
FEATURE: send notification to OP when staff marked a post as solution. (#97) Previously, we won't send any notification to the original poster when a staff user marked a post as the solution on behalf of OP.
2020-10-30 12:31:27 -04:00
notify_on_staff_accept_solved:
default: false
FEATURE: Prevents assign notification & change status on solved (#285) * 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
2024-04-26 12:21:09 -04:00
ignore_solved_topics_in_assigned_reminder:
default: false
assignment_status_on_solve:
type: string
default: ""
FEATURE: change status on unsolve & fix assign changes (#289) * 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
2024-05-08 14:17:45 -04:00
assignment_status_on_unsolve:
type: string
default: ""
FEATURE: show education message in composer when replying on solved topic (#135)
2021-06-14 06:36:55 -04:00
disable_solved_education_message:
default: false
Two extra options (#138) * Make it possible to disallow topic starters to accept a solution * Make adding QAPage schema markup optional * Address @eviltrout's comments Co-authored-by: Richard <richard@communiteq.com>
2021-06-17 16:12:33 -04:00
accept_solutions_topic_author:
default: true
solved_add_schema_markup:
type: enum
default: "always"
choices:
- "never"
- "always"
- "answered only"
FEATURE: prioritize_solved_topics_in_search to prioritize solved topics (#236) 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>
2023-05-02 21:56:10 -04:00
prioritize_solved_topics_in_search: false
FEATURE: Enable solved for topics with specific tags. (#164) 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.
2021-09-17 10:12:47 -04:00
enable_solved_tags:
type: tag_list
default: ""
Two extra options (#138) * Make it possible to disallow topic starters to accept a solution * Make adding QAPage schema markup optional * Address @eviltrout's comments Co-authored-by: Richard <richard@communiteq.com>
2021-06-17 16:12:33 -04:00