I have another university professor interested in using Discourse as a tool to run online classes. I would like to have a means to create an initial Discourse database with a set of sample categories and topics. For example,
each course will have a set of categories/subcategories with appropriate permissions;
there need to be additional topics in the Staff category about how to organize things
Badges for submitting assignments and getting instructor approval
I want to tweak the language in some of the default staff posts for people who don’t know what system administration is
I think that perhaps the easiest/best way to do this is to set up a fresh install, set stuff up like I want it, and back that up. Those who want to use my system would do a fresh install and restore my database. Does that sound right? Is there some other way? Might I want to do this as a template instead and use db/fixtures/999_topics.rb as a model?
Indeed it might. For now I have created a Python script that creates sets of badges (bronze, silver, gold for people who post in a certain category with a given tag). My target audience probably won’t be likely to be popping into a shell and running rails commands, though.
In this way, you lose the time axis. Your default topic may looks out of date.
I guess your case is highly customized given different time. But the previous data doesn’t need to change since they will be archived just like Moodle.
I would suggest two ways:
If your data doesn’t evolved rapidly and it can be deduced from default site settings, you can go with a plugin. In this plugin, several seed_data can be registered (it’s the way to override admin start guide for plugin authors) as well as a lib task. Later on, you invoked this lib task.
While the previous may not be that customizable, you can however make use of a rake task. Visiting a HTTP url (securely), downloading and commit all changes. Basically everything you can do in the console can be done by rake task.
It’s been quite easy to invoke the rake task for Discourse Docker. Running rake in custom commands and you are good to go. In both case, you have to protect the rake task running twice which might fit your case. This can be achieved by a timestamp parameter. (Well, I don’t have an good idea now)
Besides, you have every rights to generate an admin API by rake apikey:get and use it whatever you want. Though you still need to use custom commands to trigger the rake task and collect it (securely).
Sorry, I checked the seed_data which is a plain hash and only used for overriding the admin starter guide. It’s not really useful in your case.
But a rake task is still worthing considered but you have to prevent it from running twice (maybe define a site setting for checking this). In this way, you would end up with a configurable ruby script as your need/create.