이것이 최신 형태로 다시 돌아온 건가요? 비활성화되어 있고 모든 것이 꺼져 있습니다:
하지만 여러 카테고리 드롭다운에 표시됩니다. 백엔드에서는 큰 문제가 아닐 수도 있지만, 검색에서도 제안되고 있습니다:
이것이 최신 형태로 다시 돌아온 건가요? 비활성화되어 있고 모든 것이 꺼져 있습니다:
하지만 여러 카테고리 드롭다운에 표시됩니다. 백엔드에서는 큰 문제가 아닐 수도 있지만, 검색에서도 제안되고 있습니다:
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.
유지보수 담당자가 이전 답변에서 제가 설명한 절차를 따라 결함을 재현할 수 있었나요? 해당 토픽에 여전히 needs-repro 태그가 붙어 있는 것을 확인했기 때문에 이렇게 질문합니다.
결함을 재현할 수 있다면, 현재 상태로는 보고가 처리 가능하다는 것을 명확히 하기 위해 해당 태그를 토픽에서 제거해 주세요.
퍼, 잠시만 기다려 주세요. 이 이슈가 우리 레이더에서 빠졌었네요. 재현 확인을 우선 처리하고, 멤버 XP에게 할당할 예정입니다.
Per, "다른 걸 시도해 보세요"라고 답하는 건 솔직히 좀 그렇습니다.
하지만 Arduino에서 “분류되지 않은 항목 숨기기” 기능을 그냥 종료하는 걸 가로막는 것이 무엇인지 궁금합니다.
저는 이 기능이 전체적으로 매우 혼란스러운 돌발 변수라고 생각합니다. 병렬 우주라면 사이트 설정 자체를 삭제할 텐데, 주제가 카테고리를 가져야 하는 상황에서 주제가 카테고리를 가지고 있으면서(실제로는 카테고리가 없는 셈인데) 동시에 없는 이 우주는 혼란스럽고, 사용자가 “일반” 카테고리에 그냥 넣을 수 있는데도 불구하고 이 기능이 최종 사용자에게 제공하는 가치는 정말로 미미합니다.
"분류되지 않은 주제"를 “일반” 카테고리로 가져오는 작업에 저희가 도움을 드릴까요?
이것은 “분류 없는 토픽 허용” 사이트 설정의 체크를 해제하는 것을 의미하나요?
그렇다면, 아두이노 포럼은 (과거에도 그랬듯이) 그렇게 설정되어 있습니다.
참고로, “카테고리 재배치”(이미 중요하지 않다고 명시한 항목)를 제외하고, 제가 try.discourse.org에서 제공한 지침을 통해 오류를 재현할 수 있음을 확인했습니다. 따라서 아두이노 포럼은 이 대화와 직접적인 관련이 없습니다. 일반 사용자의 입장에서 볼 때, try.discourse.org에서는 “분류 없는 토픽 허용” 사이트 설정이 비활성화되어 있습니다.
여기 보고된 문제는, “분류 없는 토픽 허용” 사이트 설정을 통해 해당 카테고리가 비활성화된 포럼에서 Uncategorized 카테고리가 사용자 인터페이스에 노출된다는 것입니다.
저는 그걸 괜찮습니다.
수년간 사용자가 자신의 토픽에 적절한 카테고리를 선택하도록 설득하는 데 애써 온 사람으로서, 사용자가 카테고리를 선택하는 과정을 건너뛸 수 있도록 허용하는 기능이 유용하다고 생각하는 포럼 운영자가 있을 수 있다는 점은 이해할 수 있습니다. 하지만 저는 제 포럼에서 “분류 없는 토픽 허용” 기능을 사용할 의향이 없으므로, 해당 기능의 제거는 저에게 개인적으로 영향을 미치지 않습니다.
저는 “분류 없는 토픽 허용” 기능을 사용해 본 경험이 없으므로, 제안하신 대로 일반 카테고리를 사용하는 것과 기능의 상대적 장단점에 대해 언급할 수 없습니다.
해당 기능이 정말로 필요한지 이해하기 위해 그 기능을 사용하는 사람과 이야기하는 것이 좋은 아이디어라고 생각합니다. 다만 저는 그 사람이 아닙니다.
이 말의 의미를 정확히 이해하지 못하겠습니다. 하지만 이해하고 싶습니다.
아두이노 포럼의 카테고리화에 대한某种 형태의 도움을 제안하시는 건가요?
아두이노 포럼을 보고 계신다면, 혼동을 줄 수 있는 점은 실제로 "Uncategorized"라는 이름의 카테고리가 있다는 것입니다. 하지만 이것은 단순히 그런 이름을 가진 일반 카테고리일 뿐, “분류 없는 토픽 허용” 사이트 설정에서 제공하는 특수 카테고리가 아닙니다. 우리의 “Uncategorized” 카테고리는 “분류 없는 토픽 허용” 기능과 정반대의 목적을 가지고 있습니다. 이 버그 리포트의 주제와는 전혀 관련이 없지만, 왜 그렇게 했는지 궁금하시다면 여기에서 설명하고 있습니다.
아, 그렇군요. 로컬 디버깅을 조금 해보았는데, 기본 Discourse 설치 환경에서 100% 재현 가능하다는 것을 확인했습니다.
여기서 내용을 정리해 보겠습니다:
‘미분류(uncategorized)’ 관련 설정이 2가지 있습니다:
allow_uncategorized_topics 기본값 꺼짐(off)
suppress_uncategorized_badge 기본값 켜짐(on)
allow_uncategorized_topics가 비활성화된 경우(기본 설정)에도 이 카테고리의 존재가 특정 장소에서 노출(leak)되고 있습니다.
이를 우회하려고 미분류를 활성화하여 삭제하려 하면 다음과 같은 화면이 표시됩니다:
Discourse에서 이 카테고리는 매우 특이한 성격을 가지고 있습니다:
조건문(conditional)을 계속 추가함으로써 누출을 수정할 수는 있지만, 클라이언트와 서버 양쪽 모두에서 이미 적어도 10개나 쌓여 있을 것입니다.
아니면 근본적으로 이 문제를 해결할 수 있습니다. 관리자가 카테고리를 삭제할 수 있도록 허용하면, 해당 카테고리가 사라지므로 더 이상 이를 검사할 필요가 없게 됩니다.
제 제안은 다음과 같습니다.
uncategorized_category_id를 모두 삭제합니다.default_composer_category가 있습니다.현재 검색 버그는 다음과 같은 방식으로 수정할 수 있습니다.
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"
);
});
}
);
하지만 이는 고급 검색 버그만 해결하는 것이며, 우리는 여전히 구슬치기(wack-a-mole) 게임을 하고 있는 셈입니다…
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 설정을 활성화합니다.