This is like a Feature - Dev topic, not sure which one it should be in.
Is there a way to modify site settings in a plugin? I’m 99% sure there isn’t, but I’d just like to confirm that.
If there isn’t, can I put forward a suggestion to not make it immutable? Or perhaps, having some API or a way to ‘unlock’ the immutable property of SiteSettings, perhaps?
A possible use case I’m looking at is to the include a list of protected categories to a setting such that it’s easier for the admin to include/exclude them.
Can you first describe the use case from the point of view of the community? What are they trying to accomplish and what makes that hard to do right now? What feature do you imagine solving their need more effectively (regardless of how it’s implemented)?
Then, we can work from there to determine if this is best done in a plugin or as a core feature.
Then, we can work from there to discuss suggestions for how to implement it.
I wrongly assumed that since settings are ummutable in TCs, they are also as such in plugins in Ruby. I’ll give that a shot.
It would be nice to make them editable in TCs. My use case (which I am using a plugin for now) is that I take all topics and posts in all categories by default and do some stuff with them, but would not like to include protected categories (like a excluded_categories setting).
However, if it were possible to add protected categories to the setting, and then access it thereafter, it would be easier. This way, admins can include some protected categories if they want to by removing them from the setting.
With @pfaffman’s idea, it can probably be done, but not in TCs.
The problem with this is that I don’t know the protected categories beforehand.
If you’re logged in as an admin then a theme component could change siteSettings via the API.
Then just make a theme component setting and add those categories? You’re not referring to some protected_categories site setting that I’m not thinking of, are you? So something like this?
Are you willing to share more about your community itself?
Are you the primary user of this feature or are there others on your team who need it? Do you have user facing documentation for the workflow that depends on this feature? If so, what does that look like? If not, can you describe briefly what it might look like?
I think answers to these kinds of questions would help me put this request in better context.
@mcwumbly@pfaffman Okay, let me try to explain this as much as possible.
I am developing a plugin that takes topics and posts and publishes them to GitHub as Markdown files (like an archive).
However, I would not like to include private categories (I think now that’s the correct term?) in this, since they are ‘private’.
Therefore, I am looking for a way to pre-fill a setting with the list of private categories, which can’t be defined within the default parameter, since I wouldn’t know what the private categories are beforehand.
In the event that this can be done by directly changing SiteSetting in Ruby, can the same be done with a Theme Component’s settings? I’m quite certain the latter is immutable. Is there any way to change it in a Theme Component?
It’s not really about the community. I’m taking a shot at this (with a backfill job as well) in my own way. This saves each topic and post as a Markdown file in a repo.
I still don’t know what private means to you. Does it mean that you want only categories that are visible to everyone, or to anonymous users? Or do you have some other definition.
If you want those, then your plugin can get just those, perhaps by a search that you pass a user to (or maybe by calling a guardian), or just checking the permissions.
Or if private is something that is an opinion, then you can add a setting.
And you probably want to do this in a job that runs daily or whatever?
If you’re pushing stuff to github, I’d think you’d want discourse to just do it rather than muck with having your browser push data to discourse? I don’t see how or why you’d do it with a theme component.
I mean categories like #staff, and others that are limited by groups. I think it’s possible with a plugin, but I guess TC settings can’t be mutable then? I mean, that’s probably irrelevant to my original query now I guess.
Am I correct in understanding that you are referring to the method of Category.where(...) to get these “private” categories? But what if the admin wants to include (some of) those - do I need to have a include categories setting which counteracts the “private” categories defined in the code? Would that would be counter-productive?
I still don’t understand this. Yes, you can add those settings in a SiteSetting and yes the plugin could read that setting, and even change it. But why would it need to change the setting given the above scenario?
Supposing if I have 5 categories: A, B, C, D and E. Now let’s say B and C are only available to some groups. To prevent private topics here from being shared when uploaded to the repository, B and C are added to the excluded_categories setting, along with others like say #staff.
Now supposing the site admin is fine with B’s topics to be shared, he can go ahead and remove B from the setting, while still leaving C there.
So the excluded_categories would have to be changed at the start to add the “private” categories B and C. I’m not sure if that makes sense?
Although that is perfectly possible from a technical point of view, I think the approach would be over complicated, especially since “at the start” is hard to define/detect, and you want to avoid that the plugin keeps adding B back after the site admin removed it. Also, when a new private category is added, the plugin would need to add it to the setting, but it would need to be able to see the difference between a new category (add) and a category that was previously removed by the admin (don’t re-add).
I would opt for a include_private_categories setting which starts out empty, and the plugin would simply process all public categories, AND the categories in include_private_categories. That will give you a lot less headaches.
Also, from a functional point of view, that makes it more easy to spot which private categories are being shared (in your approach one would have to have a list of categories in their mind and then determine which ones are missing by comparing them to the ones in the setting).