python-discord / bot Goto Github PK
View Code? Open in Web Editor NEWThe community bot for the Python Discord community
Home Page: https://pythondiscord.com
License: MIT License
The community bot for the Python Discord community
Home Page: https://pythondiscord.com
License: MIT License
Originally posted by Leon Sandøy:
The superstarify only has 75-ish artists, and some of them are still groups. Please change the data to be as follows:
Originally posted by Johannes Christ:
Add support for using the Information cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Originally posted by Johannes Christ:
Add support for using the Events cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Originally posted by Scragly:
In the cogs
extension module, there's a try: except ClientException
. The reason for the error is hardcoded, assuming that it raises only when a setup function does not exist.
Click here to view the relevant code.
Unfortunately, the same exception will also raise down the stack in bot.add_cog
when a command within the cog has a name that's already existing in commands, conflicting and raising the exception.
To avoid incorrect errors being reported/logged, and to prevent confusion during debugging, it might be best to simply remove the except ClientException
block and let it fall down into the catchall except Exception as e
block which prints the exception details as given.
Feel free to comment better suggestions, of course.
This will be something for after the migration over to GitHub, hence why it's an Issue, rather than a quick MR.
If a user enters code without formatting, the bot will reply with the message on how to format python code in discord.
I feel like it would be nice if there's a way to close this message either by helpers/admins/moderators or by the person who typed the wrongly formatted message him/herself by reacting with some emoji (like how you can do paging)
It would keep the discord chat flowing nicely instead of scrolling back over bot interruptions.
We would then also need to find a way to keep the mod-log clean though.
Originally posted by Mark:
There are several issues with our dependencies:
==2.2.5
) and websockets (==4.0.1
) versions do not satisfy the current requirements of discord.py.Originally posted by Leon Sandøy:
You shouldn't be able to unwatch an unwatched user, or mute a muted user. The bot should simply say "oops, that user is already muted / banned / is not on the server (if you try to kick) / isn't currently being watched / ..."
Go through the bot, find cases like these, and fix'em.
Originally posted by Scragly:
The custom cooldowns in the wolfram cogs have been implemented as a command check instead of a command cooldown. Due to this, anytime command.can_run
is called the cooldowns end up triggering it's usage, even if it wasn't from a command invocation, but just a check for displaying in the help command or similar situations.
This will need to be changed to a proper cooldown implementation to avoid having any non-invoke check count towards the usage limit unnecessarily.
Originally posted by Thomas Petersson:
Would probably be helpful to see which are available and change them without having to change sourcecode.
(will look into soon tm)
This issue is intended as a primary discussion thread for the debate raised in #53, in which several ideas about quotation were raised, including:
"
primarily, and '
when double quotes are in the string.'
for short words and "
for sentencesThis issue will be closed as soon as we have found something to use consistently in the project, and a PR has been made to close this issue by fixing all existing strings.
Originally posted by Kingsley McDonald:
the automagic #reddit
post relays appear to have frozen entirely, and reloading the cog doesn't seem to be a temporary solution to that. this has happened only once thus far, and the only notable thing that stands out as being potentially related is the fact that the relays stopped working after the top weekly posts had been sent and pinned. it isn't the first time the bot has sent and pinned weekly posts, but it certainly is the first time any problems have been observed with the relays. no related errors were found in the logs.
Originally posted by Thomas Petersson:
Might be handy to be able to have them separate if we ever need to review moderation based events like a kick / ban.
Thoughts?
Originally posted by Johannes Christ:
Add support for using the Tags cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67/diffs and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Originally posted by Kingsley McDonald:
the bot.utils.time.humanize
function strips the resulting time of trailing 0 times. for example, "0 days 5 hours"
would become "5 hours"
. this means that when the result is something like "0 days"
, it just returns an empty string. perhaps it should return the "0 days"
as it is, to avoid situations like this:
(thanks for the screenshot, gdude. :D)
Originally posted by Leon Sandøy:
The ’
is allowed in channel names. We should insert it into all existing channel names that have contractions (dont-do-this, dont-do-that), and change the otnames add feature so that it accepts ’
, and also so that it converts '
into ’
so we don't have to type some weird unicode character every time we make a name.
The standard library has a module pydoc
which can be used for generating and viewing documentation. I suggest a command such as [prefix] pydoc <NAME>
which calls pydoc.doc
with the given name to show instant documentation. I feel like this could be useful when referring to a certain method when helping someone - here's an example with str.find
:
>>> import io
>>> import pydoc
>>> out = io.StringIO()
>>> pydoc.doc('str.find', output=out)
>>> print(out.getvalue())
Python Library Documentation: method_descriptor in str
str.find = find(...)
S.find(sub[, start[, end]]) -> int
Return the lowest index in S where substring sub is found,
such that sub is contained within S[start:end]. Optional
arguments start and end are interpreted as in slice notation.
Return -1 on failure.
for "bigger" documentation such as help(dict)
, this generates quite the long output. It might be a good idea to truncate this or put it into a "pageable embed" (with reactions to move around). Also, I've yet to figure out if it's somehow possible to include a link to the official docs..
Originally posted by Leon Sandøy:
Currently, innocent Discord errors such as "this command does not exist" or "could not find that user" are not being handled by the command error handler. As a result, the bot logs a lot of stacktraces for relatively innocent things.
See the following paste for examples: https://paste.pythondiscord.com/uwopupoyun.py
Investigate the problem, create logic to handle these types of errors, and merge request it to the bot.
Originally posted by sco1:
With the impending merge of the notes cog, it would be nice if !bb watch
took advantage of the cog and allowed us to store a note when someone is watched so others can track it in the future.
Right now it seems like the optional "log to channel" input is being used, so it seems like it makes sense to replace this input with a notes entry, similar to how warn/kick/ban/etc. are set up.
Originally posted by Scragly:
There are 12 cogs that use the event on_ready
to perform some form of preparation for that cog.
While that's fine if the extension is loaded before the bot is started, any cases where loading occurs after this stage will result in the preparatory tasks not being done at all, resulting in missing data the cogs rely on to function. This includes cases where a cog may be reloaded during runtime, which often happens during development to refresh to code.
Instead of running when the bot dispatches the ready event, it would be best to instead have it prepare every time a cog is loaded, but have it wait for the bot's ready flag:
class Cog:
def __init__(self, bot):
self.bot = bot
...
bot.loop.create_task(self.prepare_method())
async def prepare_method(self):
await self.bot.wait_until_ready()
# do prep stuff
...
This is a job for after the Github migration.
Originally posted by Leon Sandøy:
Let's make a simple leaderboard for mod-alert triggerers. It should only be usable in staff channels like #admins and #staff, and only by mods or higher. We'll track mod-alert triggers in the database, so it'll need a site MR as well.
Originally posted by Johannes Christ:
Add support for using the Doc cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Originally posted by Leon Sandøy:
We want to create a new channel, #recruitment, where people will be able to do recruitment. For this, we want the following system:
!approve
command that takes a message_id just in case the reactions fuck up.!deny
command that takes a message_id just in case the reactions fuck up.Originally posted by Leon Sandøy:
There are still improvements that need to be made in infraction search. I'll leave this issue a bit open ended as to what the best way to implement these things is, but here's what I'd like to be able to do:
Originally posted by Johannes Christ:
Add support for using the OffTopicNames cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
I believe the last opinion on this was faking contexts and messages in order to test every function/cog for itself. Something new on this?
As a user I want to be able to set reminders for posts I made or others made.
The reminder should include a due-time (hours/days/specific date) and be able to link to the post in question.
Originally posted by Leon Sandøy:
Currently Superstarify events have a terrible 🖕 thing in the modlog. They should obviously have a nice embed instead like other moderator actions do.
Originally posted by Leon Sandøy:
In #73, we created a util to handle waiting for reaction and then deleting a message in bot.utils.messages
. This should be used for codeblock messages as well.
Originally posted by Leon Sandøy:
We should remove the RMQ integration, and replace it instead with Tasks, as described in https://gitlab.com/python-discord/projects/site/issues/45. The RMQ code is an unholy mess that nobody likes working with, and a simple one-way-communication system is far simpler for contribs and core devs alike to wrap their heads around. It also wouldn't really perform very differently anyway, so for our use case it should be perfect.
The Task interface should be abstracted away so that our contribs never have to worry about doing the actual polling. The bot should just do this and then trigger a sort of task event, that our contribs can write handlers for. This should be as simple as possible, and it would be ideal if it mimics how events work in discord.py already. perhaps an on_task_received
event handler that can optionally be defined for each cog, and some sort of constant to define relationships between task types and cog? Something like that.
Originally posted by Thomas Petersson:
More of a personal memo, but add aliases for
!tags get f-strings
!tags get codeblock
Any other additions are welcome.
Originally posted by Thomas Petersson:
Since the bot straight out bans, kicks, etc. after posting an infraction, won't it be possible for moderators to ban admins. Given the bots role is above admins. This makes it more of a trust based implementation over restricted.
In my opinion admins should not be able to moderate other admins, and moderators should definitely not be able to moderate admins (owners are above the bot in the hierarchy and can't be effected)
If it was not for the fact that joseph is an owner (and super duper owner) and the bot is under owner role in the hierarchy that may have very well gone through. (We were curious, didn't intend to try to ban Joseph)
Originally posted by Johannes Christ:
Add support for using the Modlog cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Originally posted by Johannes Christ:
Add support for using the Defcon cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Originally posted by Johannes Christ:
We need to generalize the current way of working with the site. Simply speaking, the Django rewrite of the site has abstracted away most of the API endpoint setup and they are more or less the same with some minor differences.
Therefore, I propose we use a single API client class instead of writing extra methods in order to fetch tags, watched users etc. in each of the cogs. Some initial work was done here: https://gitlab.com/python-discord/projects/bot/merge_requests/67
Since the Django site rewrite is not live, all branches related to this issue must be based off the Django branch, and the merge requests must be opened with the django branch as the source branch.
For testing locally, you can either set the site up yourself (which I'd recommend, since you get to see what's going on) or ask me for a token on my "staging" instance of the website.
Please refer to the linked merge request for how to use the new API calls in your code.
Originally posted by Johannes Christ:
Add support for using the Moderation cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Originally posted by Johannes Christ:
The current responses returned when something goes wrong from the Django API are very crude. We should display embeds and random error messages instead. The relevant code can be found here: https://gitlab.com/python-discord/projects/bot/blob/django/bot/cogs/events.py#L138-143
To set up the bot to work with the new site, you can either ask me for an API key on my instance or set up your own. See the Django branch on the site project for more information.
This is labelled as a good first issue - if you have any questions about this, don't hesitate to ask!
Originally posted by ByteCommander:
It could be useful to know when an account has last been active in the server (e.g. events like sending messages, reactions, deleting messages, maybe changing nick) or even been visibly online in general. This could be integrated into the general user info command, or queried with a new bot command.
To avoid stalking/abuse potential, the reported time should probably be rounded to at least whole days, or for longer time spans even weeks for posting in public channels.
The data would have to be gathered by logging the time stamps (again, rounding this to e.g. full hours or maybe even full UTC days could be desirable) of user actions and status/visibility changes. Only the last value for both activity and visibility should be saved each, no history.
Additional things to do with this data include showing accumulated stats about how many people have been inactive/invisible for how long periods of time. Possibly it could even be used to notify and in a second step prune members that were inactive and never online for extended periods, like 6 months or a year (dead accounts).
Originally posted by ByteCommander:
The #checkpoint channel is where new members have to go to type !accept
in order to verify they have read the rules and to get access to all other public channels.
Currently, the bot removes all user messages from #checkpoint immediately, to keep it clean. If the user types anything other than !accept
, they additionally get a warning which self-destructs after short time.
However, other bot commands are still working, and while the user's original command message will be removed, any command responses will still get posted and do not seem to ever get deleted automatically.
This seems to be a bug that allows people spamming the checkpoint channel to annoy yet to be verified users.
As a solution, all commands except for !accept
should be entirely disabled in #checkpoint.
Originally posted by Johannes Christ:
Add support for using the Snakes cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Some errors use plain messages (e.g. general error handlers and moderation cogs) while others use embeds, sometimes even including humorous replies (e.g. reminders and clean cogs). Errors don't necessarily refer to CommandError
here - it could be any error that is being handled, even ones that aren't exceptions.
Embeds have more formatting options, allow room for those humorous replies, and are more prominent in the sense that 1. bigger = more noticeable and 2. can't be confused for a regular user's message. On the other hand, plain messages have less clutter around them and are simpler to create in code (may be a moot point if a generic utility function is added to create the embeds).
All the areas where errors are being handled should be identified so that it is clear what changes need to be made and where.
Originally posted by Kingsley McDonald:
many error responses in the Moderation
cog aren't sent as an embed. instead, the messages are sent with a very simple (and ugly) ❌. all occurrences of this should be changed to be consistent with the rest of the bot's responses.
Originally posted by Mark:
Add a way to delete eval results similar to how it was done for the code block tag. Sometimes I make a mistake and have no choice but to live with it cluttering up the chat. Sound easy enough; I'll gladly submit an MR for this myself.
Originally posted by Johannes Christ:
Add support for using the Hiphopify cog with the new Django API. The branch should be branched off https://gitlab.com/python-discord/projects/bot/merge_requests/67 and the merge request should head back into the linked branch.
This is a good first issue - if you have any questions about this or want more information, don't hesitate to ask!
Originally posted by Leon Sandøy:
Why not just discord.ext.commands.Bot
Originally posted by Gareth Coles:
Originally posted by Thomas Petersson:
async def channel_is_whitelisted_or_author_can_bypass(ctx: Context):
"""
Checks that the author is either helper or above
or the channel is a whitelisted channel.
"""
if ctx.channel.id not in WHITELISTED_CHANNELS and ctx.author.top_role.id not in BYPASS_ROLES:
raise MissingPermissions("You are not allowed to do that here.")
return True
This custom check in snekbox.py is checking toproles for whitelists, which means a helper with the event handler role for instance wont be able to use eval because their top role is not whitelisted.
Originally posted by Johannes Christ:
In order to generalize our current error handling, the new API client raises HTTP errors straight to the commands. For simple cases that don't require specialized handling, we should use the command error handler in bot/cogs/events.py
in order to provide a useful response.
I took an initial stab at it in https://gitlab.com/python-discord/projects/bot/merge_requests/67, which you can look at for reference, but I did not yet fully figure it out.
You will either have to fire requests against my API instance or set up your own instance of the website: see the setup documentation on the Django branch for details.
For documentation on the command handler, see https://discordpy.readthedocs.io/en/rewrite/ext/commands/api.html#discord.on_command_error.
If you have any questions, please ask.
Please leave a comment if you start to work on this issue.
Part of #67.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.