[feature request] Extend webhooks for notifications in Discord #activitybot

[davehakkens]

Current setup

We have a few webhooks installed to make a notification in Discord to the #activitybot channel.

Current Problems

1. They are only installed for the map and how-tomodule. (not research or questions)
2. They are triggered on edit (should only be triggered on create/approved)

Describe the solution you'd like

1. We need webhooks for questions and research module.
2. Stop to trigger webhooks when content (map-pins + howtos) are edited

Trigger Overview

Research:
Trigger: New Update posted inside a Research module
Text: 📝 New update from [username] in their research: [insert research title]
Learn about it here: [url to research update]

How-to:
Trigger: New How-to approved by admin
Text: "🎁 Yeah! New solution made by [username]: [insert how-to title]
Check it out here: [url to how-to]"

Member-map-pin:
Trigger: Member Map-pin approved by admin
Text:"👋 New pin on the map from [username] that want's to get started
See if they are local to you here: [url to map]"

Space-map-pin:
Trigger: Space Map-pin approved by admin
Text:"🌏 New space on the map from [username] that grows the global movement!
Find them here: [url to map]"

Question:
Trigger: Question posted in Question module
Text:"❓ [username] has a new question: [insert question title]
Help them out and answer here: [url to question]"

Things to keep in mind

• Use these<> to wrap the so it doesnt show a preview-card in Discord
• It might be more effective to solve the "edit" problem on a higher level. Since currently any edit to a map-pin and how-to needs approval by an admin. This could be removed to only ask for approval when create, not edit. (Bonus: this would also make admins happy)
• It needs to be done for all our 3 live instances

Note: 🔥 #activitybot is our 4th most watched channel in our Discord

[pizzaisdavid]

I have addressed the Howto editing triggering a notification and need re-approval from admins (I think technically the notification happens only after the admin has re-approved.) #3613 the pull request is currently still open, but just so anyone else avoids doing that work.

[davehakkens]

Thanks for the first part on this @pizzaisdavid !
Are you also up for doing the other bit of this?

[pizzaisdavid]

I might try but no promises.

Stop to trigger webhooks when content (map-pins + howtos) are edited

Moving the location of a pin does not trigger the need for re-approval but changing the "focus" of a profile does. And we want to disable that, correct?

In case anyone else wants to try, here is the related code: https://github.com/ONEARMY/community-platform/blob/master/src/stores/Maps/maps.store.ts#L187

[pizzaisdavid]

current state:

• Pins of type member do not need moderation.
• Switching type in any way (except to member) requires moderation.

What I can adjust it to:

• NEW: Switching between different non-member types do not affect moderation status (already accepted entries stay as accepted.)
• SLIGHT CHANGE: Switching from member to a non-member type requires moderation, already happening indirectly.
• Pins of type member do not need moderation (same as before.)

Example: if someone switches from member to collection point, they would need moderation. If they switch back to member, they don't need moderation. But if they switch back again to collection point (or any other non-member type) they need approval again.

Summary: any time switching from member to non-member, it would require moderation.

If the wish is they really only need to be approved once ever, then a new property could be introduced (or a different approach.) But I can't estimate the complexity of that.

Also to reiterate for those reading, whenever the moderation status of a pin is changed to accepted it triggers the webhook.

Also, I could be wrong about any of this, anyone feel free to correct me.

[davehakkens]

Thanks for the indepth look, very useful!
Your porposal sounds more complete then the original plan of no moderation at all.
To me this seems like a good path to take

EDIT: We might need a bit more thinking on this moderation flow so we can make it ready for the future.
Because at the moment "workspace" profiles (non members) dont have any moderation since this was not needed when introduced. So anyone can create one. Since the only way you could find them was on the map. Hence the Map moderation.

That said, features are added like comments and the Q&A etc that make it possible to discover a workspace account. In order to keep them legit we might need to bring moderation to the profile level, not map.

Will discuss with the team first to see whats the best way

[pizzaisdavid]

I see we want to push the questions module for precious plastic.. therefore, it would be good if we setup the webhook for that.

[davehakkens]

I see we want to push the questions module for precious plastic.. therefore, it would be good if we setup the webhook for that.

Agree that would be a very nice/useful one

[pizzaisdavid]

Kay, here's a pull request that publishes webhooks for new questions: #3619

It depends on some refactoring I did to make development easier, so first that stuff needs to be merged 😈

Also, some technical things could be clarified but I've listed that in the pull request.

[mariojsnunes]

Kay, here's a pull request that publishes webhooks for new questions: #3619

This has been deployed 🚀

[pizzaisdavid]

Research Updates have a collaborators property, which is a list of usernames. I've only ever seen an Update written by one person, so a list of just one username.

But is it planned to support or possible to have multiple collaborators on a single Research Update?

I could build some more complicated logic in that case:

1 author:
📝 New update from [username1] in their research: ...

2 authors:
📝 New update from [username1] and [username2] in their research: ...

3 authors:
📝 New update from [username1], [username2], and [username3] in their research: ...

And so on..

Thoughts?

[davehakkens]

What does this deployment mean @pizzaisdavid?
Should notifications come in somewhere now, from dev or live?

But is it planned to support or possible to have multiple collaborators on a single Research Update?

Not planned. For now only multiple contributors on an entire research topic (like here). Not on one specific update.

[pizzaisdavid]

What does this deployment mean @pizzaisdavid?
Should notifications come in somewhere now, from dev or live?

It is possible I don't understand you correctly, but the next time a Question is asked on https://community.preciousplastic.com/questions there should be a corresponding bot post in the activitybot Discord channel.

Precious plastic is the only one with questions enabled, but in the future, if others projects have it enabled too, there would be notifications from them as well.

I thought about posting a test question on Precious Plastic, but I think it isn't possible to delete your own question, so I felt like it would be not nice.

Can I post a test question on production, to verify it works correctly? (or someone else can do it if they like.)

[davehakkens]

yeh lets give it a try @pizzaisdavid! (I will delete for you)

[pizzaisdavid]

https://discord.com/channels/586676777334865928/599259846767935519/1251985417973006376

[davehakkens]

Nice one! 💪
@goratt12 So what is the function of the new Discord Bot we recently setup up? -Since this seems to run on the original one.

For the archive:

[goratt12]

The function stayed in firebase-discord.ts

community-platform/functions/src/Integrations/firebase-discord.ts

Lines 18 to 25 in 7b84b82

	export const sendDiscordNotification = async (
	payload: DiscordWebhookPayload,
	) => {
	await axios
	.post(DISCORD_WEBHOOK_URL, payload)
	.then(handleResponse, handleErr)
	.catch(handleErr)
	}

The testing function is also in that file

community-platform/functions/src/Integrations/firebase-discord.ts

Lines 34 to 48 in 7b84b82

	export const getDiscordMessages = async (limit = 50) => {
	const res = await axios
	.get(
	`https://discord.com/api/channels/${DISCORD_CHANNEL_ID}/messages?limit=${limit}`,
	{
	headers: {
	Authorization: `Bot ${DISCORD_BOT_TOKEN}`,
	},
	},
	)
	.then(handleResponse, handleErr)
	.catch(handleErr)
	const messages = res.data ?? []
	return messages
	}

We are having issues with the testing in the CircleCI environment, currently moving the PR to Draft until we will figure out a solution