So for the pre-seeded Site Feedback category, when editing, under the security tab there is a warning.
Warning: This category is a pre-seeded category and the security settings cannot be edited. If you do not wish to use this category, delete it instead of repurposing it.
I can understand there there is probably some good reasoning behind locking the Staff category security rules. However, there is no locking of the pre-seeded ‘Lounge’ category security rules. I’m thinking that the ‘Site Feedback’ category should be treated the same as the Lounge, with editable security rules.
Not sure if I’ve overlooked some detrimental effects of being able to edit the security settings for the Site Feedback category. All the other category options for it don’t appear to be locked.
The Lounge is set so a user has to attain a TL3 in order to gain access. The Lounge is a “privilege” or “reward” in a way for those users who are actively participation in the community. If you would rather change the qualifications for accessing this type of category, why not simply create a new category with whatever security allowances you wish?
As for Site Feedback, do you think because a user is new and hasn’t attained a higher TL they wouldn’t a suggestion that would be of benefit to the community? That kind of sounds like “if you’re new, we don’t want to hear what you have to say.”
I’ve never tried, but it may be possible to create a new category with your preferred security settings, move all the posts to the new category, and then delete the original category. Just be sure to rename it differently from site-feedback.
This has been discussed before (trying to change the security settings for pre-seeded categories). So why not just create a new category to your requirements and delete the pre-seeded one?
Yeah valid points @JimPas and yes you’re right, deleting it and re-creating it is a solution. I don’t think this is a big problem, I just think that it’d be a more ideal default to allow editing the security settings for that category.
Allowing new users to post feedback, in many cases is probably ideal. I just think it might be a little bit overly opinionated to ship the security settings for that category being locked as default for all communities. I don’t see much benefit to the reduction of flexibility by locking them.
A few more specific reasons:
One of the reasons for the security lock, at least according to the message presented, is to prevent repurposing of the category. Admins can rename the category and slug however, perhaps in naivety, repurposing the category as they wish (minus being able to edit the security settings options).
Some admins may wish to hide the site feedback category from users who are not logged in and web crawlers, while still allowing all logged in users (including new) to see and post feedback.
In some cases an admin may wish to create Site Feedback subcategories that are more specific and disallow posting in the parent category so that users must choose a suitable subcategory for their feedback to improve topic organisation. I don’t believe that is possible without editing the security settings.
An admin can delete the category and create a new one as a work around. However it might not be ideal for a forum which has already been running for a while. The new category will have a different id and url, breaking any static existing links and external links to that category. That said, they could use the Permalinks options as a work around solution to redirect the old category.
Exactly this for me. Development on our Discourse has been very active for the last few months, but people are trying to now use it as intended (a mailing list replacement). We have a large number of resolved posts related to setup and maintenance of the forum, which the average user does not care about at all.
We have our primary category, which is uncategorized, and encourage all users to simply @staff when they wish to give feedback. We even include this in the description shown when a person is about to draft up a new topic. Also, we have topics dedicated to “Report any forum issues here” where we relay if we’ve updated and added features requested in the thread, plus encourage user input.
Absolutely. It isn’t a question of limiting access to this data. If you walk into my home I don’t leave all of my architecture plans and bills strewn all over the floor and tables. If people want that, they are happy to find such information in a different manner… perhaps through the staff group or something similar, where users can more automatically opt-in as much as opt-out.
It is a balance between daily use and those who expressly prefer to test experimental features.
It isn’t this on our forum, but more: at what point do we hide the scaffolding / limit heavy construction visibility for community users actually trying to get things done.
On our forum we have the category Site Feedback AND one called META. In the META category is where my users can create new topics about specific problems they experience. Once taken care of they are marked as Solved. The Site Feedback is as it was when first created. But I will note that we have a small forum of people who have “known” one another for 7+ years from another now defunct forum.
About category which used to be called Meta. We have a group calling themselves Meta, so we decided to give them that category name to reduce confusion. Not a huge deal, but would like to hide this About category for non-logged in people with no reason to see it. Also might make sense to limit to just a simple public group.
Staff category - random integration and technical posts we don’t want clogging up the forum. We haven’t tried staff notes feature, so this category is filling that role.
I’ve noticed most all discussion takes place in uncategorized, our default discussion place. People are enjoying tags a lot, but probably been too loose with allowing anyone to make them.
This is my main reasoning. People who aren’t even logged in probably don’t care about the forum’s setup. They just want to see general discussion, etc.
If the users who do not wish to receive posts from the site feedback category they can always mute that category in their preferences. That should prevent them from seeing the unwanted posts from that category or the entire category in Latest. Should they do decide to check it out from time to time, they can always scroll down the categories list and enter it from there.
But I think this is starting to drift slightly off-topic from @markersocial’s original inquiry - allow modifying security rules for the Site Feedback category.
(It would still be nice to continue this discussion about the different uses for your categories.)
Why couldn’t users just create a new Topic in the Site Feedback category that is specific to their particular feedback? We have several topics in our Site Feedback category created by users. It’s more of a suggest box and for asking questions. When users experience any problems, they’ll post in our troubleshooting category aptly titled “Meta”.
A quick solution for your suggested reason would simply
create a category titled “Feedback”,
create whatever sub-categories you want for your users to create topics in,
then set the main category so no one can post in that.
But… will that setting then prevent users from posting in the sub-categories?
I’ve never tried this. Sounds like an interesting experiment, but I’m off to bed very shortly. Maybe tomorrow I’ll give that a go - unless a team member jumps in here with an explanation as to whether this will work or not.
So the main question I’d say is, what are the benefits of locking the security settings for the pre-seeded site feedback category for all installs?
I can’t really think of any benefits to it, it seems like a bit of an unnecessary barrier with no downsides for removing. New installs could get the recommended security settings by default, but allow flexibility for any use cases outside of that. Essentially just like the Lounge pre-seeded category.
It’s not a big issue, considering that there are work arounds by deleting it and recreating it as you’ve suggested . However it’s a little bit less elegant if the forum is aged that wishes to modify these later on as their forum grows, as it changes the url for the category (can use admin > customize > permalinks to aid with this).
Yes correct, they can create a topic in the site feedback category specific to their feedback. It may be useful to force using subcategories for each topic for some use cases though, especially in cases when the forums are part of a diverse brand possibly having several user facing sites/apps and products.
Some feedback may be about the company’s main products and specific categorised aspects of them or it may be about the forum itself. This forum itself has a site-feedback subcategory for the blog, which also has a different tag group assigned to it.
Regarding this, I’ve used this before for some categories (disallow posting in the parent category, but allow posting in it’s subcategories). The subcategory security rules aren’t affected by the parent category security rules. So yes, this is indeed a solution.
Thanks. That saves me from checking this out. i lost almost 5 hours today due to an unexpected visit by a 3-yr old granddaughter who only wanted Grandpa to play with her.
Now to finally check out my own forum.
It’s there as a workaround for technical limitations - if we (Discourse) ever want to update the default settings, or change the translated name of the category, it would cause massive confusion if people repurposed the seeded category as a “normal” category and then one day it magically changed because we updated the defaults. (Yes, this has happened. That’s why the restrictions are there.)
Stopping you from modifying the security settings functions as a reminder that it’s special and subject to updates to the defaults.
Because the auto-update thing is the only thing making these categories special, the help text asks you to delete the category entirely and create a new one instead of repurposing it.
Ah fair enough. Thanks for the explanations @riking.
If it is very detrimental to repurpose the category, which isn’t something I’m encouraging, perhaps a warning on the rename category settings would make more sense? The security rules don’t seem that strongly directly related to those potential issues.
I’ll highlight a few points:
The Lounge category seems to be in the same auto-updatable boat, but security settings are modifiable.
The Site Feedback can be repurposed (rename title and slug) without really noticing the security rules lock. It has the same default security rules as a new “normal” category.
Locking prevents fairly simple changes such as only showing the category to logged in users or restricting it to certain trust levels.
@Stephen - I see the lounge category referenced in postgres in the ‘site_settings’ table. I’m not entirely sure how meaningful that is, but guessing it’s processed similarly. When I messed around with the ‘meta_category_id’ (site feedback category) on a test instance it affected the Site Feedback category on rebuild.
I just tested it now on a test instance and it worked fine, was only with a small amount of topics though.
So SSH into your server then use these commands (in this example, all topics in category 2 will be moved to category 1, so replace those numbers as needed):
cd /var/discourse
./launcher enter app
rails c
Topic.where(category_id: 2).update_all(category_id: 1)
You can get the category ids from the numbers at the end of your category urls.
Edit: Only issue is it will also move the ‘about this category’ post as well and it doesn’t seem possible to move it back or delete it from the admin UI. Can make it unlisted but not sure if that would cause issues. Give me a moment, will update shortly.
Edit 2: So to move the ‘about this category’ topic back to the correct category. Just use this command (where the topic id is 1 and the desired category to move it to is 2). Tested it now and it worked:
Topic.where(id: 1).update_all(category_id: 2)
You can get the topic id from the end of the topic url just like the category ids.
In the META category is where my users can create new topics about specific problems they experience. Once taken care of they are marked as Solved. The Site Feedback is as it was when first created. But I will note that we have a small forum of people who have “known” one another for 7+ years from another now defunct forum.
