Is this back in it’s latest form? It’s disabled and all:
But shows in various category dropdowns. Probably not such an issue on the backend, but it’s also suggested in search:
Is this back in it’s latest form? It’s disabled and all:
But shows in various category dropdowns. Probably not such an issue on the backend, but it’s also suggested in search:
Ik heb hier geen repro van op 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 Ik weet niet eens zeker of we dit “ongecategoriseerde” slangenkuil op de lange termijn willen behouden.
Door de jaren heen heb ik hard geprobeerd er zoveel mogelijk van af te komen, maar er duiken steeds nieuwe uitzonderingen op.
Naar mijn mening moeten we de instellingen afschaffen en mensen gewoon een standaardcategorie laten kiezen. Een themacomponent kan een bepaalde categoriebadge verbergen voor de zeldzame gevallen waarin mensen deze niet willen tonen op “Algemeen” of iets dergelijks.
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.
houd vol per, het is van onze radar verdwenen, dit prioriteren voor bevestiging van repro en toewijzen aan lid xp
Per, ik haat het om dit te beantwoorden met “probeer iets anders”
Maar ik vraag me af, wat weerhoudt je ervan om het gebruik van “suppress uncategorized” op Arduino gewoon te beëindigen?
Ik vind deze hele functie een verwarrende curveball, in een parallel universum zou ik gewoon de site-instelling verwijderen, onderwerpen hebben een categorie nodig, dus deze universum hebben waar onderwerpen een categorie hebben (maar eigenlijk geen categorie hebben) is verwarrend en voegt echt zo weinig toe aan eindgebruikers, gezien je dingen gewoon in “algemeen” kunt gooien als mensen niet kunnen categoriseren.
Zou je willen dat we helpen bij het overzetten van de “grab back of topics that are not categorized” naar een “General” categorie?
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…