이것이 최신 형태로 다시 돌아온 건가요? 비활성화되어 있고 모든 것이 꺼져 있습니다:
하지만 여러 카테고리 드롭다운에 표시됩니다. 백엔드에서는 큰 문제가 아닐 수도 있지만, 검색에서도 제안되고 있습니다:
이것이 최신 형태로 다시 돌아온 건가요? 비활성화되어 있고 모든 것이 꺼져 있습니다:
하지만 여러 카테고리 드롭다운에 표시됩니다. 백엔드에서는 큰 문제가 아닐 수도 있지만, 검색에서도 제안되고 있습니다:
I have no repro of this on main.
@j.jaffeux I am able to reproduce it on try.discourse.org. I can tell that the “Allow uncategorized topics” setting is disabled on that forum because “Uncategorized” is not present in the “category…” menu of the topic composer.
“Uncategorized” is present in the “Categorized” menu of the advanced search on the search page.
An “Uncategorized” item is present in the menu.
#u in the “Search” field.
An “Uncategorized” item is present in the category filter autocomplete menu.
#u in the “Search” field.
An “uncategorized” item is present in the category filter autocomplete menu.
I am also able to reproduce the presence of the “Uncategorized” category in the “Reorder Categories” dialog. I reproduce that on a forum in which I am an admin, and where the “Allow uncategorized topics” setting is disabled (obviously I can’t test it on try.discourse.org). That forum is using Discourse version d8c855e55978d00fc63021b31ecd00a4bee9d922.
/categories).
An “Uncategorized” item is present in the dialog.
I agree with @manuel that the presence in this dialog is less serious than the presence in the user facing interfaces, but thought I should mention it as you are apparently not even able to reproduce that fault.
@hugh I am not even sure we want to carry this “uncategorized” snake pit long term.
Over the years I tried hard to get rid of as much of it as I could, but new edge cases keep popping up.
Imo we should get rid of the settings and just allow people to pick a default category. A theme component can hide a particular category badge for the rare cases where we people don’t want to show it on “General” or similar.
Were the maintainers able to reproduce the fault by following the procedures I described in my previous reply? I ask because I see that the topic still has the needs-repro tag.
If you are able to reproduce the fault, please remove that tag from the topic so that it is clear that the report is now actionable in its current state.
hold tight per, it dropped off our rader, prioritizing this for confirmation of repro and assigning to member xp
Per, I hate to answer this with “try something else”
But I wonder, what is holding you back just terminating usage “suppress uncategorized” on Arduino?
I find this whole feature a confusing curveball, in a parallel universe I would just delete the site setting, topics need a category so having this universe where topics have a category (but don’t really have a category) is confusing and really adds so little to end users given you can just chuck stuff in “general” if people can not categorize.
Would you like us to help with porting the “grab back of topics that are not categorized” into a “General” category?
By this, do you mean unchecking the “Allow uncategorized topics” site setting?
If so, then that is how Arduino Forum is (and always has been) configured.
Please note that, with the exception of “Reorder Categories” (which we have already specified is not very important), I have verified that the fault can be reproduced by the instructions I provided on try.discourse.org. So Arduino Forum is not directly relevant to this conversation. From what I can tell as a normal user, the “Allow uncategorized topics” site setting is disabled on try.discourse.org.
The problem reported here is that the Uncategorized category is exposed in the user interface on forums which have that category disabled via the “Allow uncategorized topics” site setting.
That is fine with me.
As someone who has struggled for years to get users to choose an appropriate category for their topics, I can understand why some forum operators would find it useful to have a feature that allows users the option of skipping picking a category. However, I don’t have any interest in using the “Allow uncategorized topics” feature on my forum so the removal of the feature would not affect me personally.
Since I don’t have any experience using the “Allow uncategorized topics” feature, I can’t comment on the relative merits of the feature vs. just using a normal category as you propose.
I think it is a good idea to talk to someone who uses the feature to understand whether it is truly needed; I just don’t happen to be that person.
I’m not sure I understand what you mean by this. I would like to understand though.
Are you offering some form of assistance with the categorization of Arduino Forum?
If you are looking at Arduino Forum, something that might cause confusion is that we do actually have a category named “Uncategorized”. However, this is a normal category that just happens to have that name, not the special category that is provided by the “Allow uncategorized topics” site setting. Our “Uncategorized” category actually has a completely opposite purpose from the “Allow uncategorized topics” feature. It isn’t in any way relevant to the subject of this bug report, but in case you are interested in why we did that, it is explained here.
Oh I see, just did a bit of local debugging, I confirm this is 100% reproducible on default discourse installs.
Let me recap here:
There are 2 settings when it comes to uncategorized:
allow_uncategorized_topics default off
suppress_uncategorized_badge default on
when allow allow_uncategorized_topics is disabled (default setup) we leak its presence into certain places.
If you try to work around by enabling uncategorized so you can delete it, you are presented with:
In Discourse this category is super weird in that:
We can fix the leakage by just adding more and more conditionals, we are probably up to at least 10 now both on client and server.
Or we can fix this at the core, just allow admins to delete the category, then it goes away and we never need to check for it anyway.
My recommendation here is
uncategorized_category_iddefault_composer_categoryThe current search bug can be fixed with something like
diff --git a/app/assets/javascripts/select-kit/addon/components/search-advanced-category-chooser.js b/app/assets/javascripts/select-kit/addon/components/search-advanced-category-chooser.js
index a678919d16..83a9ed27db 100644
--- a/app/assets/javascripts/select-kit/addon/components/search-advanced-category-chooser.js
+++ b/app/assets/javascripts/select-kit/addon/components/search-advanced-category-chooser.js
@@ -1,4 +1,5 @@
import { classNames } from "@ember-decorators/component";
+import { setting } from "discourse/lib/computed";
import CategoryChooserComponent from "select-kit/components/category-chooser";
import {
pluginApiIdentifiers,
@@ -7,11 +8,13 @@ import {
@classNames("search-advanced-category-chooser")
@selectKitOptions({
- allowUncategorized: true,
+ allowUncategorized: "allowUncategorized",
clearable: true,
none: "category.all",
displayCategoryDescription: false,
permissionType: null,
})
@pluginApiIdentifiers("search-advanced-category-chooser")
-export default class SearchAdvancedCategoryChooser extends CategoryChooserComponent {}
+export default class SearchAdvancedCategoryChooser extends CategoryChooserComponent {
+ @setting("allow_uncategorized_topics") allowUncategorized;
+}
import { render } from "@ember/test-helpers";
import { module, test } from "qunit";
import { setupRenderingTest } from "discourse/tests/helpers/component-test";
import selectKit from "discourse/tests/helpers/select-kit-helper";
import SearchAdvancedCategoryChooser from "select-kit/components/search-advanced-category-chooser";
module(
"Integration | Component | select-kit/search-advanced-category-chooser",
function (hooks) {
setupRenderingTest(hooks);
hooks.beforeEach(function () {
this.set("subject", selectKit());
});
test("respects allow_uncategorized_topics setting when false", async function (assert) {
this.siteSettings.allow_uncategorized_topics = false;
await render(<template><SearchAdvancedCategoryChooser /></template>);
await this.subject.expand();
// Uncategorized category (ID 17 in test data) should not be present when setting is false
assert.false(
this.subject.rowByValue(17).exists(),
"uncategorized category is not available when allow_uncategorized_topics is false"
);
});
test("shows uncategorized category when allow_uncategorized_topics is true", async function (assert) {
this.siteSettings.allow_uncategorized_topics = true;
await render(<template><SearchAdvancedCategoryChooser /></template>);
await this.subject.expand();
// Uncategorized category (ID 17 in test data) should be present when setting is true
assert.true(
this.subject.rowByValue(17).exists(),
"uncategorized category is available when allow_uncategorized_topics is true"
);
});
test("has correct default options", async function (assert) {
await render(<template><SearchAdvancedCategoryChooser /></template>);
assert.strictEqual(
this.subject.header().label(),
"All categories",
"has correct default none label"
);
});
}
);
But that is just the advanced search bug, we are playing wack-a-mole here…
DEV: remove and replace Uncategorized - Pull Request #41169 - discourse/discourse - GitHub (Removing Uncategorized and migrating to a standard category)를 통해 이 문제가 해결되었음을 확인했습니다.
@sam 님께 감사드립니다. 여기서 설명된 구체적인 결함뿐만 아니라, 표준 카테고리만으로도 충분히 처리될 수 있는 특수 유형의 카테고리를 두는 것이 불필요한 복잡성을 초래한다는 더 큰 그림을 보고 문제를 짚어주셨기 때문입니다.
혼동할 수 있는 점은 이 제거 작업이 기능 플래그(feature flag)로 제어되며, 이 플래그는旧的 특수 ‘Uncategorized’(분류되지 않음) 카테고리가 활성화된 경우에만 접근 가능하다는 것입니다:
따라서 allow uncategorized topics 설정이 비활성화되어 있다면, DEV: remove and replace Uncategorized - Pull Request #41169 - discourse/discourse - GitHub 변경 집합이 포함된 버전으로 Discourse를 업데이트한 후에도 현재 이 게시물에서 보고된 버그의 영향을 받을 수 있습니다.
저는 다음과 같은 절차를 통해 제 포럼에서 보고된 버그를 해결할 수 있었습니다:
allow uncategorized topics 설정을 활성화합니다.