the-programmers-hangout / hangoutbot Goto Github PK

If anyone wants new features they're welcome to submit PRs. To encourage this, we should add contribution guidelines

Hey there people,

we sometimes get suggestions to introduce roles to reduce the number of channels, and we did try that once and it was annoying because new comers would get redirected to non existent channels without a certain role. Couldn't we make productive mute a bit more expansive to handle that? Default mutes every off-topic channel as it stands and you can provide categories or further channels to ignore in the args. It then applies a role with that exact name (one role per person) but mutes different channels depending on how it was invoked and if we really wanted could make it of indefinite duration (with some way to revert)?

Just some throwing some thoughts around, what do you think?

Literally sends the join message twice.

As it is, once a role with a particular colour has been created there is no way to use that role name for a different colour, even if the old role is not used A few ideas for how this can be resolved:

1. When clearcolor is used, check if no user has the role and delete the role in that case.
2. Allow setcolor to update role colours when the role already exists.
3. Add an changecolor command to modify the colour associated with a name.
4. Add an deletecolor command that removes a colour role.

I'm not sure option 1 is feasible, since I don't know if Discord has a way of easily checking if a role is unused. Options 2-4 all seem like they would be reasonable solutions. I'd be happy to give implementing one of the four a shot; does anyone have a preference on which one? (Assuming this is a desirable feature in the first place.)

• Add uptime
• Add ping
• Use markdown to shorten the repo URL

Need to investigate why

On startup the bot tries to check if anyone should be unmuted - if they've left the server this throws an error

Problem: Manually removing the color role from someone does not remove that user from the list of users with the color. The color is then not deleted, if that was the only user making use of it.

We should listen for GuildMemberRoleRemoveEvent and update the color roles accordingly.

There's a typo in the Oh, User, don't let's ask for the moon. We have the stars.
It is Oh, User, don't let's ask for the moon. We have the stars.
It should be Oh, User, don't ask for the moon. We have the stars.

Expected behaviour:
tph!grant userid [NameOfRole]
Role added to user
tph!revoke userid [NameOfRole]
Role removed from user

Actual behaviour:
tph!grant userid [NameOfRole]
Roles must be from this guild.
tph!revoke userid [NameOfRole]
Roles must be from this guild.

Role is listed in listgrantableroles and listroles.

Is this just not implemented yet? @markhc

The separator for choices currently is everything between A and B:
tph!flip A Choice 1 | Choice 2 | ... B

instead of:
tph!flip A | B

Sudonym made the suggestion in the hangout channel yesterday, so here I am making an issue for it: https://discord.com/channels/244230771232079873/244230771232079873/772764519277395968

This is a feature I am working on, that is ready to be implemented here. The feature involves anti-raid policy and a few more environment variables.

How this will work:
Example limit is 10 users per 5 minutes

Members enter. The bot logs them in a python List.
If threshold exceeds and more than 10 users accumulate within a 5 minute period, all users in the list get kicked.
A notifier sends a message in general about the raid, and optionally dmes the kicked users that they were part of a raid.