Unfortunately yes. It might be a nice enhancement to add a ārepeat in x hoursā parameter (PR welcome or hire me to implement), but as Iāve mentioned before in this Topic, it would be better if someone produced a new plugin using their API and created some scheduled sidekiq jobs to do that. A bot is a fun solution but not the best architecture for scheduled syncing.
Oh, thanks anyway. Yeah, we have already thought about a possible alternativeā¦
We wanted to sync Discourse groups with Discord roles, but it looks like there is no perfect solution that suits.
We are now going to make some kind of bot using webhooks: Discourse will trigger a webhook when an userās groups is updated (or username change as well) to a custom solution, which will then assign roles in Discord. We will keep using the Discord OAuth choice in order to get guilds, and by creating a custom Data Explorer query, we can get through the API those guilds.
It would be something like this:
- User changes groups or username
- Webhook to custom solution is triggered
- This custom solution will call back to Data Explorer API to a custom query that returns the guilds from the user
- With that guild, we call Discord back to update roles
A proper batch job would be better so you donāt lose data integrity due to one-off event glitches. Both would be perfect.
Well, I didnāt go through that wayā¦
Iāve forked your repo, and made a new plugin that suited our needs:
https://github.com/barreeeiroo/discourse-discord-sync
It basically syncs all groups with Discord roles, but automatically. When a user is added or removed from a group, it will run a sync job and update their roles according to the public groups. In addition, Iāve added a setting to mark a āverified roleā, that will be added to all users who have a Discourse account. And also it supports adding a list of safe roles, which the bot will ignore when syncing users (useful, for example, if wanting to set different admins and mods in the server than in the forum).
Iāve also added a username-nickname syncer. It can enforce users to have the same server nickname as the forum username.
Iāll open a #plugin topic after cleaning up a couple of things, as maybe someone can find it useful.
@barreeeiroo what was really interesting about your fork was your leveraging of DiscourseEvents
hooks.
I had assumed that wasnāt possible because the bot is running in a separate thread. But as youāve discovered, it seems we can act on events and influence the bot. So thanks for that, thatās a really important insight we can develop going forward.
So Iāve started adopting that technique in the main repo, starting with the ability to set some watches on new posts or Topics that willl be announced in the admin channel of Discord.
https://github.com/merefield/discourse-discord-bot/commit/9f8498c6a56baebb4d21009dff57932b35a46b86
The functionality may be of little use as it currently stands but it demostrates the concept for others to leverage.
OK Iāve developed the plugin a little further now and have POC for two way communication working:
Here are the new settings
-
You can designate an Announcements Channel on Discord in the plugin settings.
-
You can now type into the assigned Discord Announcements Channel and this will post your message to your assigned Discourse Topic in the plugin settings
-
You can set up a list of Categories in Discourse to post to the Announcements channel on your Discord if someone Posts there or adds a new Topic (either or both).
https://github.com/merefield/discourse-discord-bot/commit/a19aa35f6aab2504aa220a1ab3856475f27c795a
In addition Iāve added a new file to manage Discord events supported by the discordrb
API, with Announcements logic being the first example (feel free to develop new ones and PR if of general use to the community).
Iāve also removed the changes required to app.yml to install libsodium-dev
as this is now optional having updated the dependencies and not required for the plugin at present (no need to handle voice). This will make installation much simpler.
I followed the installation instructions and everything went smoothly up to the restart. The bot did not join the room, so I checked /logs:
Is this referring to the discord_bot_token
? Itās filled in, and I verified the value. Any clues?
Mark, apologies, I somehow missed this.
Did you discover the issue?
Can you please update and try the new version and weāll take it from there
A significant update funded by the Discourse team
-
A new command
!disccopy <number-of-messages> <optional-target-category-name> <optional-target-topic-name>
which allows you to copy Discord message history (in that channel) to your Discourse instance from within Discord chat. This can safely cope with 1,000ās of messages in one go (but for that volume will take time). -
Automated per message chat copy, by channel to any identically named Category on Discourse: if the channel name matches the Category name, it will copy the message into Discourse if this is set:
-
For any message copied into Discourse from Discord, the User will now show correctly if that user has logged into Discourse using the Discord login (So Discord Bot is able to match the user accounts).
-
Localisation support added for a lot of features.
Thanks to @erlend_sh & Discourse team for speccing & sponsoring this work!!
More bot stuff coming
If they login with Discourse auth or any auth other than Discord OAuth, would this plugin simply ignore them?
Doesnāt ignore them, itās just unable to match the user with the person on the other system. As a result copied messages will appear to be from āsystemā
Are threads supported?
Not yet, Klaus, but itās potentially in the pipeline. Waiting for the Ruby API to be updated (blocker) then a backer to add that feature.
Allright. Thatās a bit of a bummer since I just enforced threads in the support chans of our Discord to get a better overview of support cases. And I am not sure it actually gives that - but luckily thereās other advantages.
Do you have an ETA on the API and an idea of what it would cost to back the feature?
Thanks!
/k
I did chase recently and itās been in development for some time. Iāll chase again and revert, but be warned, the last time they told me āitāll be done when itās doneā ⦠the problem with open source is often a lack of a good way of directing appropriate levels of community funding (or lack thereof) to assist with focus and prioritisation ⦠weāll see ā¦
From my end Iād have to see the final implementation to estimate the effort.
The challenge might be that whilst itās straightforward to copy across messages, keeping Threads in sync with Topics may require some kind of mapping maintained in Discourse, e.g. a custom field or table that maps Discord Threads to Discourse Topics, so when a new message gets added to a Thread you know where to put it in Discourse.
Can you elaborate on exactly the functionality/behaviour you are seeking?
Yeah that sucks to be depending on something you canāt influence.
My idea is very inspired on the article and the discoussion on the Discourse blog on how well Discord and Discourse supplement each other. When we started our Discord server almost two months ago we didnāt really know how it would evolve and how it would affect our existing (but barely configured) Discourse forum but it looks like people still use it as well as our Discord for asking technical support questions (I am with the FOSS project CrowdSec). So basically I completely buy in on the idea to use Discourse as a more long term memory and sync Discord threads to Discourse under topics matching Discord channels (and vice versa). The way I see it, it can be done much more effectively (e.g. automated) by using threads.
As I said I recently enforced threads on Discord which means that itās not always very easy to get an overview of threads for those of our developers that are assigned to user support. So I want to use the sync to Discourse also as a good way for them to keep updated on questions to answer whilst not being sucked too much into the Discord chitter-chatter.
Does that makes sense? And is there some other way to achieve this on a shorter time frame maybe?
Hi @merefield !
Iām reaching out to you here because I donāt think my github Issue was seen, and Iām thinking this is the next best place.
Weāve been getting an error that weāve tracked down to the discord bot plugin. The above image shows the inspect element error, but any user who sends a PM also gets a ā500 Errorā visual when their PM is sent. The PM is still sent successfully, but this error makes it seem otherwise. After disabling the plugin, the issue no longer exists.
Iām pretty sure the issue is coming from /lib/discourse_event_handlers.rb. Iām assuming that a PM is triggering the post_created DiscourseEvent which makes it try to access the postās category via posted_category = post.topic.category.id, which causes the error.
I hope this helps and I hope this can be resolved soon. Thanks
Thanks for the report. Sounds about right. Might get chance to look at it this week ā¦
Fantastic, thank you! Weāll keep an eye out for the update.
Heads up that Iām drowning in client work atm so this may not get looked at for a little while.
In the meantime PR accepted.
In general I would welcome more community contribution to the free plugins.