#dev-log

1 messages · Page 38 of 1

regal archBOT
#

It's just a common style we have to refer to a user in embeds, since it leads to a clickable mention that does not actually ping the user. I'm not sure if you can infer the intention from it that you do. I'm not saying that it wouldn't be an option to include it, but I don't think this is an actual bug; it could just be an enhancement.

I think it was left out because the most common way of doing this is !free <mention> instead of !free <id>.

regal archBOT
regal archBOT
#

I don't think we're in a hurry, but I was reminded of it from people having some issues with their IDE not recognizing some of the attributes we set dynamically (e.g, api_client). Having a custom Bot class would solve that.

I can work on it, but if you like to work on it, that's fine as well.

regal archBOT
regal archBOT
#
         for colour, hex_value in test_values:
             with self.subTest(actual_hex=deletedmessage_filters.hex_colour(colour),
                                             expected_hex=hex_value):
                self.assertEqual(actual_hex, expected_hex)

This has no functional difference, but it would make it easier to tell at a glance what the issue was if/when the tests fail. I find that making use of the var names also helps to self-document the exact purpose of...

regal archBOT
ebon magnetBOT
#

Build 20191107.1 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
regal archBOT
#

As the original author of this command, I suppose I should speak on this. @SebastiaanZ is correct, I specifically intended that the bot response not ping the user. Not only does this prevent a double ping with very little effort, but I did not want the bot to ping the user from the invocation of a different user. It is rare for non-staff to ever provide the ID of a user as the argument to a command. While the parsing of the user argument is flexible enough to accept an ID, I intended for ...

#

In fact, ever since the output of the command was redesigned, I think even the Hey <user> part is completely unnecessary and should've been removed as well.

Now that we have a good idea of how this command is used, I think the !free command should no longer take any arguments. The seek argument is never used, and if the command no longer takes arguments, nothing is stopping users from providing a user mention after the !free invocation.

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191107.1 failed

Requested by

GitHub

Duration

00:01:38

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191107.2 succeeded

Requested by

GitHub

Duration

00:02:18

Build pipeline

Site

regal archBOT
native joltBOT
regal archBOT
#
[python-discord/bot] New branch created: talent\-pooling
ebon magnetBOT
#

Build 20191108.1 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191108.2 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: talent\-pooling
north knotBOT
ebon magnetBOT
#

Build 20191108.3 succeeded

Requested by

GitHub

Duration

00:03:26

Build pipeline

Bot

oak estuaryBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
#

In the past couple of months, a number of enhancements have been suggested for the commands in the information cog. I decided to make a list of those suggestions (from memory, so please comment the things I've inevitably forgotten) and want to take a stab at implementing those enhancements. In addition, there's also a small bug in the !roles command that needs to be fixed, since it's unusable right now.

Enhancements

  1. If the !user command targets a non-moderator in a moderat...
regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191108.4 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

ebon magnetBOT
#

Build 20191108.5 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191108.6 succeeded

Requested by

GitHub

Duration

00:01:42

Build pipeline

Bot

regal archBOT
#

38d9e70 Add unit test for links antispam rule - kwzrd
a216704 Add two more test cases for links rule unit test - kwzrd
9e16b0c Annotate unclear test cases with inline comments - kwzrd
f6ed29c Adjust case to only test a single aspect - kwzrd
9000d92 Add whitespace for readability, consistency & a... - kwzrd

north knotBOT
ebon magnetBOT
#

Build 20191108.7 succeeded

Requested by

GitHub

Duration

00:05:07

Build pipeline

Bot

oak estuaryBOT
regal archBOT
regal archBOT
#

@lemonsaurus

Can I ask where you picked up that convention @aeros, or what the reasoning behind it is?

We follow that convention in the CPython docs and docstrings. I don't know the specific reason behind it, but we use backticks for functions or methods, and asterisks for arg names. For example:

`loop.run_in_executor()`
*executor*

Backticks for argument names as well though is probably fine, as long as you're consistent with it.

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191109.1 succeeded

Requested by

GitHub

Duration

00:01:42

Build pipeline

Bot

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191109.2 succeeded

Requested by

GitHub

Duration

00:01:42

Build pipeline

Bot

regal archBOT
#

I'm a bit torn on the complexity argument here.

One of the reasons we use our custom mock objects is because they follow the specifications of an actual instance of the discord.py they are mocking. This means that if a version upgrade in discord.py changes the API of the class/object in a way that's relevant to the code you're testing, the tests will now fail because the code it's testing is trying to use attributes that no longer exist on the actual object.

By creating a static obj...

regal archBOT
ebon magnetBOT
#

Build 20191109.4 succeeded

Requested by

GitHub

Duration

00:01:33

Build pipeline

Bot

regal archBOT
#

In https://github.com/python-discord/bot/pull/655/commits/16e6c36c6b370300ef7507d2e01421ad0d83f407, tests.helpers.MockMessage is used as suggested. Passing an id (message id, that is) manually actually ends up being unnecessary, as the __eq__ falls back on identity comparison. The test cases just needed to be adjusted so that multiple instances aren't used to represent one message.

Let me know what you think. If this looks good, I will adjust the other rule unit tests to use this met...

regal archBOT
#
[python-discord/bot] New branch created: checkpoint\-changes
regal archBOT
#

Abstract

This PR rewords the period ping to #checkpoint so it is no longer "ambiguous" to new users.
It also forwards all messages sent in #checkpoint that contained a user or role mention to #mod-alerts.

Motivation

Rewording of periodic ping

Consensus from staff is that the previous wording of the message might be the cause for so many users both running !accept and pinging the admins. Full context in issue: [#160](https://github.com/python-discord/organisation/issu...

ebon magnetBOT
#

Build 20191110.1 succeeded

Requested by

GitHub

Duration

00:01:49

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191110.2 succeeded

Requested by

GitHub

Duration

00:01:50

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
ebon magnetBOT
#

Build 20191110.3 succeeded

Requested by

GitHub

Duration

00:01:46

Build pipeline

Bot

regal archBOT
#

Thanks, @lemonsaurus for assigning this to me. I am more comfortable with the site part of this task So it will not be a problem for me. On the command part, can you give me some more details like:

  • What all items can be added to this whitelist?
  • Should it also give option to list, edit or delete the whitelist?
  • any restrictions on who can call this command or in which channels?

This is my first task on creating a command, So need some more clarity. Thanks!

regal archBOT
#

A number of symbols have reduced usefulness after the changes. For example, list and multiprocess.Process both show the following:

This appears to be a generic page not tied to a specific symbol.

I feel like this still needs some work in order to improve consistency expected behaviour.

Another thing is I'd like to see a command added that will call refresh_inventory. If we add a new entry to the site, this ensures we can reload it without doing an internal eval.

ebon magnetBOT
#

Build 20191110.4 succeeded

Requested by

GitHub

Duration

00:01:52

Build pipeline

Bot

ebon magnetBOT
#

Build 20191110.6 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

regal archBOT
#

4dccaca Reword periodic #checkpoint message - fiskenslakt
01ab4ad Forward user/role pings in checkpoint to mod-al... - fiskenslakt
0425e6c [kaizen] Remove now duplicate channel check - fiskenslakt
f3dbe47 Merge branch 'master' into checkpoint-changes - MarkKoz
51852a1 Merge pull request #656 from python-discord/che... - MarkKoz

ebon magnetBOT
#

Build 20191110.7 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: checkpoint\-changes
north knotBOT
ebon magnetBOT
#

Build 20191110.8 succeeded

Requested by

GitHub

Duration

00:03:31

Build pipeline

Bot

oak estuaryBOT
ebon magnetBOT
#

Build 20191111.1 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
ebon magnetBOT
#

Build 20191111.2 failed

Requested by

GitHub

Duration

00:01:30

Build pipeline

Bot

regal archBOT
regal archBOT
#

09f923b Initial navbar change to add settings button ne... - gdude2002
7bdd610 Bring navbar styling in line on mobile as well - gdude2002
a82e15f Allauth: Re-add GitHub provider, prevent GH sig... - gdude2002
3512a71 GH signup prevention, views and templates for s... - gdude2002
ea149e7 Signals: Move group changes outside of the loop - gdude2002

#
[python-discord/site] branch deleted: allauth\-user\-settings
ebon magnetBOT
#

Build 20191111.1 succeeded

Requested by

Sebastiaan Zeeff

Duration

00:02:47

Build pipeline

Site

north knotBOT
native joltBOT
ebon magnetBOT
#

Build 20191111.2 succeeded

Requested by

GitHub

Duration

00:09:19

Build pipeline

Site

regal archBOT
#

A few additional things have come up that could be worked on RE the account system.

  • [ ] Expose linked accounts via the API, so the bot can get at them (eg, GH accounts)
  • [ ] Close button on the account settings modal
  • [ ] Match up role colours on the account settings modal labels
  • [ ] Close mobile navigation when modal is opened (this currently soft-locks the page!)
regal archBOT
ebon magnetBOT
#

Build 20191111.3 failed

Requested by

GitHub

Duration

00:01:16

Build pipeline

Bot

regal archBOT
#
  • any restrictions on who can call this command or in which channels?

It should definitely be restricted. I think this falls under the umbrella of server administration, so it would make sense to restrict this to those with the admins or owners role. There are constants defined in config-default.yml/bot.constants with the relevant role IDs. It's not really sensitive information, so I don't think a channel lock-down is necessary to prevent accidental data leaks.

  • Should it also ...
regal archBOT
ebon magnetBOT
#

Build 20191111.3 succeeded

Requested by

GitHub

Duration

00:02:12

Build pipeline

Site

native joltBOT
regal archBOT
#
[python-discord/site] New branch created: \#298\-exemption\-model
regal archBOT
#
[python-discord/site] New branch created: pipenv\-run\-start
ebon magnetBOT
#

Build 20191111.4 succeeded

Requested by

GitHub

Duration

00:02:17

Build pipeline

Site

regal archBOT
regal archBOT
#

Currently tags are used randomly, however randomness is pretty far from evenness. It would be nice to make use of tags more evenly, to avoid recently used tags being used multiple times.

One method would be to have a column tracking usage in the current iteration, a bool of True/False. used=False would be the default for new tags. The pool of available tags to pick from will be all tags with used=False. When a tag it picked, it'll be given used=True. Once no tags are returned for `us...

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191112.1 succeeded

Requested by

GitHub

Duration

00:02:14

Build pipeline

Site

regal archBOT
#
[python-discord/site] branch deleted: pipenv\-run\-start
north knotBOT
ebon magnetBOT
#

Build 20191112.2 succeeded

Requested by

GitHub

Duration

00:04:05

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191112.3 succeeded

Requested by

GitHub

Duration

00:02:27

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191112.1 succeeded

Requested by

GitHub

Duration

00:01:53

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191112.2 failed

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191113.1 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
#

We'd like to be able to link otnames together, so that they always appear at the same time. This issue needs to be handled at the same time as the problem is solved on the bot side, because both will rely on each other for proper testing.

For example, we may want the following names to always appear together:
#ot0-what-is-your-name?
#ot1-what-is-your-quest?
#ot2-what-is-your-favorite-color?

  • [ ] Create a new field in the off topic channel name model called linked_names. This...
#

We'd like to be able to link otnames together, so that they always appear at the same time. This issue needs to be handled at the same time as the problem is solved on the site side, because both will rely on each other for proper testing. The site issue can be found at https://github.com/python-discord/site/issues/310.

For example, we may want the following names to always appear together:
#ot0-what-is-your-name?
#ot1-what-is-your-quest?
#ot2-what-is-your-favorite-color?

  • [ ]...
regal archBOT
#

Il wouldn’t be smarter to use 2 ForeignKeys inside the linked_name field? I think it would be easier to just create 3 OffTopicName and link them together, so when one the name is chosen, we can just resolve the 2 other name. It would probably be easier for future OT name editing or deletion too.

regal archBOT
#

Yeah, it might be better to use foreignkeys. If we edit one of these off-topic names, we would want the new name to be carried into all the linked_name fields. We should probably think about what happens if we delete one of them too. Will having foreignkeys in the array ensure that they disappear from the array?

regal archBOT
regal archBOT
#

This issue is to better aid giving context to infractions.

When the bot deletes spam, offending messages are stored in the database and linked to a grouped context ID which has very readable logs viewable on the staff subdomain. The proposal is to allow staff to manually store chosen offended messages for the bot to return a context ID which we can then store within infraction reasons.

A new top-level command group will be created called context and will have the following signature:
...

regal archBOT
#
[python-discord/bot] New branch created: unittest\-helpers\-improvements
regal archBOT
#

This pull request introduces several enhancements to our testing suite to make running tests easier and reduce the number of developer surprises. It does come with a couple of breaking changes that may influence currently open PRs (I haven't checked yet, but they should be easy to resolve).

Enhancements

Stricter custom mock types

One of the reasons for using custom mock types is because they follow the specifications of the actual objects they're mocking. However, as @kwz...

ebon magnetBOT
#

Build 20191113.2 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191113.3 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

regal archBOT
#

dceafb8 Prevent unwanted logging while running tests - SebastiaanZ
bf7720f Allow name attribute to be set during Mock init - SebastiaanZ
36e9de4 Prevent setting unknown attributes on d.py mocks - SebastiaanZ
7f4829e Prevent await warnings for MockBot's create_task - SebastiaanZ
d5b6ef4 Merge branch 'master' into unittest-helpers-imp... - scragly

#
[python-discord/bot] branch deleted: unittest\-helpers\-improvements
north knotBOT
ebon magnetBOT
#

Build 20191113.4 succeeded

Requested by

GitHub

Duration

00:03:49

Build pipeline

Bot

oak estuaryBOT
ebon magnetBOT
#

Build 20191113.5 succeeded

Requested by

GitHub

Duration

00:01:45

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191113.6 succeeded

Requested by

GitHub

Duration

00:01:49

Build pipeline

Bot

#

Build 20191113.7 failed

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

#

Build 20191113.8 succeeded

Requested by

GitHub

Duration

00:01:50

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191114.1 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
#

I would mention the additional memory overhead associated with initializing and appending to the internal list; it's not just noisy boilerplate, there's also a significant cost associated with doing so.

It's also worth mentioning somewhere underneath this section when to use a list instead of a generator. Otherwise, a beginner might walk away from this assuming they should always use a generator, which is definitely not the case. If it needs to: be iterated over multiple times, accessed ...

regal archBOT
#

That's some good point, here's a quick benchmark, in my machine,

import timeit
import os
import psutil

process = psutil.Process(os.getpid())
prev = 0

def current_memory(message: str):
    global prev
    current = process.memory_info().rss / 1024 / 1024
    print(message, f"| {current:,.2f} Mb ( +{current - prev:,.2f} )")
    prev = current

def get_gen():
    return (i for i in range(1_000_000))

def get_list():
    return [i for i in range(1_000_000)]

current...
ebon magnetBOT
#

Build 20191114.2 succeeded

Requested by

GitHub

Duration

00:01:48

Build pipeline

Bot

regal archBOT
#

Occasionally, two users will be too busy fighting each other to notice a moderator trying to step in and clean up the situation. In these cases, we want to be able to silence the channel for a few minutes while we sort out what's going on and what we're going to do about it.

Enter: !hush. This command will remove the ability for anyone except staff to post messages in that channel for a short duration, 10 minutes by default.

This will not need any work on the site, so it should be q...

regal archBOT
regal archBOT
regal archBOT
#

@ikuyarihS

def get_gen():
    return (i for i in range(1_000_000))

def get_list():
    return [i for i in range(1_000_000)]

Between these two tests, I think there's some degree of bias towards the generator. Upon initialization, it doesn't have to compute any of the results (unlike the list, which it will do all at once). It might paint a more accurate picture if you compared the time to both initialize the comprehensions and iterate over the results. For example:

`...

regal archBOT
#

ccda39c Add bot=False default value to MockMember - SebastiaanZ
61051f9 Add MockAttachment type and attachments default... - SebastiaanZ
8c64fc6 Check only for bot's green checkmark in DuckPond - SebastiaanZ
f56f6ce Refactor DuckPond msg relay to separate method - SebastiaanZ
89890d6 Move payload checks to start of DuckPond.on_raw... - SebastiaanZ

#

While I love the idea of the dynamic amount of h's idea, I really don't see the point in having a duration for this. Are we assuming that the invoker will forget to unmute the channel? This should absolutely just be a toggle in my opinion. Mute and unmute, that is all.

My rationale for this is two-fold:

  1. Duration often causes command misfires due to typing it incorrectly. And given this command is often one that would need to be invoked quickly, pausing to think about a duration is ju...
ebon magnetBOT
#

Build 20191115.1 succeeded

Requested by

GitHub

Duration

00:01:52

Build pipeline

Bot

regal archBOT
regal archBOT
#

I think defaulting to 15m if not passing in duration is a fine idea as well, but having duration will let mods be more flexible in more cases.

I would certainly don't want to see a channel being locked up longer than necessary when there are a lot of people asking.

An example would be like this - After I muted the channel for 5m as a clear sign that the conversation is to be dropped off, if I still see wrong behaviors then I'll issue mute directly and for much longer duration. In that ...

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191115.2 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Bot

regal archBOT
#

@fiskenslakt

Duration often causes command misfires due to typing it incorrectly.
...
Having a duration also makes the command more complicated, and will likely cause some staff to forget how it works
The duration is optional and I think the default of 10 minutes is reasonable enough that it would be very rare to need to specify a duration at all. And when you do need to, the syntax is so simple (!hush 5 for 5 minutes) that I'm not sure I buy that people would forget it if they ...

ebon magnetBOT
#

Build 20191115.2 failed

Requested by

GitHub

Duration

00:01:39

Build pipeline

Site

regal archBOT
#

071bc9d Add logging for moderation functions - MarkKoz
818e48b Moderation: use trailing _ instead of leading f... - MarkKoz
ad79540 Use trailing _ instead of leading for some vari... - MarkKoz
b7aba6b Merge branch 'master' into moderation-logging - lemonsaurus
bef90dd Merge pull request #619 from python-discord/mod... - lemonsaurus

#
[python-discord/bot] branch deleted: moderation\-logging
north knotBOT
regal archBOT
ebon magnetBOT
#

Build 20191115.3 succeeded

Requested by

Leon Sandøy

Duration

00:03:41

Build pipeline

Bot

oak estuaryBOT
ebon magnetBOT
#

Build 20191115.3 failed

Requested by

GitHub

Duration

00:01:45

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191115.4 succeeded

Requested by

GitHub

Duration

00:02:27

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191115.4 succeeded

Requested by

GitHub

Duration

00:01:52

Build pipeline

Bot

regal archBOT
#

Comment from @SebastiaanZ in #dev-contrib:

It should not wait 10 seconds to delete the messages after triggering, but it should take action as soon as possible
However, since you are going to relay the attachments, that's something that could happen earlier
The DeletionContext tracks the messages that should be deleted
The add method of that class seems like a good place to relay the attachments and save the links to those
That happens before the messages are deleted

I’m g...

ebon magnetBOT
#

Build 20191115.5 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Bot

regal archBOT
#

Slowmode has been implemented and while formatting isn't perfectly consistent, people have indeed been going much better in the past with adding in all required info into a single message.

I'd like to ask, is it worth the effort of enforcing the above proposed format?

If it is, how would the format be enforced? Filter checking messages posted or maybe having the bot post it on their behalf through a command that asks for info for each part?

regal archBOT
#

Superstarify could do with a bit of an upgrade.

It has a severe lack of images. Which is a little saddening. But if we add them, it'll be awesome.

It would also be great to add it into the db, add an admin view for it and create bot commands that will add, remove, edit, list stars similar to our off-topic name setup, which would require some work with site as well.

@lemonsaurus also demands an alias be added of !superstar.

ebon magnetBOT
#

Build 20191115.6 succeeded

Requested by

GitHub

Duration

00:01:43

Build pipeline

Bot

regal archBOT
#

Related: https://github.com/python-discord/bot/issues/662

In order to allow the superstarify pool of stars to be added into the database, we'll need to define a table schema, the endpoints we'll interact with and the admin view to define for interacting with it on the website admin interface.

The table will require at least:

  • star_name
  • image_url

We need to be able to do the following via the api:

  • fetch data of a random star
  • add a new star
  • edit a star
  • delete a star
#

Why not simply delete the code and repost it correctly encoded
A few reasons:

  • They'll be lazy and never correctly do it in the first place
  • There may be a purposeful reason for someone to not use the expected formatting even if the filter triggers.
  • The code may be only part of the original message and the rest of the content would be weird to be posted by the bot, and shouldn't be left out.

I don't see an issue with adding the "you can edit your message" section in with emphasi...

ebon magnetBOT
#

Build 20191115.7 succeeded

Requested by

GitHub

Duration

00:01:45

Build pipeline

Bot

regal archBOT
#

4efb97c add handling for duplicate symbols in docs inve... - Numerlor
f1dbb63 show renamed duplicates in embed footer - Numerlor
a05f28c Auto delete messages when docs are not found - Numerlor
eda6cd7 remove "function" from NO_OVERRIDE_GROUPS - Numerlor
d5dea25 Don't include a signature and only get first pa... - Numerlor

north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191115.8 succeeded

Requested by

GitHub

Duration

00:03:51

Build pipeline

Bot

regal archBOT
#

Tags are now part of the site API, and are editible by mods+ in the admin panel.

For now, we've added a tag directory with tag contents in individual markdown files within the meta repository:
https://github.com/python-discord/meta/tree/master/tags

For now, it's a manual process of adding or editing tags via bot or site admin whenever we get a PR merged in, however in the future this could possibly be more automated.

Due to the change in situation, I'll close this ticket.

regal archBOT
regal archBOT
regal archBOT
#

The standards we hold ourselves has greatly increased since the creation of this ticket in regards to handling user data and privacy.

While the concept of having a feature like this is still something that pops up occasionally, the limitations and expectations have shifted a bit.

Statistics on member activity would likely be directly limited to only staff members to avoid potential issues with stats gathering on general members.

The only statistics data point that has been generall...

#

I closed #388 and the meta repo contains markdown files of any of our tags for now for the public to read through and be able to submit PRs for adding or editing tags.

At the moment the process of adding or editing the tags is done via bot command in-server or by using the site's admin page (mods+ now have full access to the tag admin page).

There's improvements that can be done to make things easier and to automate/integrate the process, but I'm of the opinion that tags will continue...

#

Merging #126 into the scope of this ticket as they're close enough related.

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) :x:. all occurrences of this should be changed to be consistent with the rest of the bot's responses.

Mark: It seems we are moving away from embeds in favour of plain messages because they have less clutter. The downside is that they are no longer as pr...

#

One can just post the image in the mod channel, copy the url and use an inline link within the reason:
check [this image](https://cdn.discordapp.com/attachments/464905259261755392/644886455243636736/d2ap7cyb1xj31.png) to see the terrible thing

Doing this renders perfectly fine in infr history and it won't involve uploading images anywhere other than the discord channel (which we usually do anyway when getting context for things such as dms).

Due to the above, and the fact that this h...

regal archBOT
#

@MarkKoz and I recently defined groups for the current bot functionality in order to define easy enough to understand area labels in Github.

We settled with the following:

Filters

  • antimalware
  • antispam
  • filtering
  • token_remover

Information

  • doc
  • free
  • help
  • information
  • reddit
  • site
  • tags
  • wolfram

Moderation

  • moderation
  • defcon
  • verification

Utility

  • bot
  • clean
  • eval
  • extensions
  • jams
  • reminders
  • snekbox
  • utils...
regal archBOT
#

I'm moving spirit of the suggestion from #176 to over here for consideration as it falls under the scope of this issue:

Having some form of indication in !user output to indicate how recently an infraction was given if they have one.

The original suggestion calls for a :x: emoji to be placed next to the name, however I personally think it would be better to just have a line stating how long ago the last infraction was above the outputted groups.

#

I think the default of 10 minutes is reasonable enough that it would be very rare to need to specify a duration at all

Agree

!hush forever

I like this option, as it sticks to the idea of having a duration as the argument still, so it doesn't introduce just another thing to remember (unlike !permahush)

ping us in #mod-alerts every 15min or so reminding us

Agree

regal archBOT
regal archBOT
#

This list isn't final even though I'm pretty happy with it personally. Feel
free to comment if you have any suggestion improvements or changes to it.
Furthermore, I think we should take the opportunity to rename the cogs
subpackage to extensions or probably the shorter, and likely better,
exts.

Den fre 15 nov. 2019 08:24scragly notifications@github.com skrev:

@MarkKoz https://github.com/MarkKoz and I recently defined groups for
the current bot functionality in order to define ...

#

I played around and wrote a possible method to split things up into "interpretations" of text messed up with spoilers:

SPOILER_RE = re.compile(r"\|\|", re.DOTALL)

def process_spoilers(text):
    split_text = SPOILER_RE.split(text)
    public_text = "".join(split_text[0:][::2])
    spoiler_text = "".join(split_text[1:][::2])
    cleaned_text =  "".join(split_text)
    return public_text, spoiler_text, cleaned_text
#

It was decided in a meeting that we want to go with this approach.
Therefore, I think that if this is going to be closed, there should be a
consensus to reverse the decision to do this. And, to be clear, when this
was decided, the tags view already existed on the API.

Den fre 15 nov. 2019 06:28scragly notifications@github.com skrev:

Closed #388 https://github.com/python-discord/bot/issues/388.


You are receiving this because you authored the thread.
Reply to this email direct...

regal archBOT
ebon magnetBOT
#

Build 20191115.9 succeeded

Requested by

GitHub

Duration

00:03:27

Build pipeline

Bot

regal archBOT
regal archBOT
regal archBOT
#

It appears ' is treated as punctuation.

!t set ' ' succeeds with:

tag_name: '
tag_content: '''

This works with any character besides ". We could ignore punctuation entirely but that would cause issues with current tags that use - as a separator.

Explicitly allowing separators like -, _, and while ignoring everything else could be an option.

ebon magnetBOT
#

Build 20191116.1 succeeded

Requested by

GitHub

Duration

00:01:45

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191116.2 succeeded

Requested by

GitHub

Duration

00:01:40

Build pipeline

Bot

#

Build 20191116.3 succeeded

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191116.4 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

#

Build 20191116.5 succeeded

Requested by

GitHub

Duration

00:01:49

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191116.1 succeeded

Requested by

GitHub

Duration

00:02:06

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191116.2 succeeded

Requested by

GitHub

Duration

00:02:08

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191116.6 succeeded

Requested by

GitHub

Duration

00:01:40

Build pipeline

Bot

regal archBOT
regal archBOT
#

Let's say the function would return True if it saw the bot reacted, even if the reaction wasn't a green check mark. This is not desirable of course, so we'd want to test that doesn't happen. If the author of the reactions in this test case is made to be the bot, then this test case can also be used to test for the situation described above.

#

The log is captured from a specific logger and the level is asserted. You don't think that is adequate? It seems that the contents of the message don't actually matter but checking them is merely the way to be sure the correct message is sent. In practice, it's unlikely to be a nuisance but it does seem silly to have to change a test case when one wants to edit a log message.

If you'd like, we can leave this and save the discussion for another place since it affects all tests.

regal archBOT
#

Could be something like this:

    @staticmethod
    def _payload_has_duckpond_emoji(payload: RawReactionActionEvent) -> bool:
        """Test if the RawReactionActionEvent payload contains a duckpond emoji."""
        if payload.emoji.is_custom_emoji():
            if payload.emoji.id in constants.DuckPond.custom_emojis:
                return True
        elif payload.emoji.name == "🦆":
            return True

        return False

    @Cog.listener()
    async def on_...
ebon magnetBOT
#

Build 20191116.7 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

#

Build 20191116.8 succeeded

Requested by

GitHub

Duration

00:01:43

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191117.1 failed

Requested by

GitHub

Duration

00:01:58

Build pipeline

Site

#

Build 20191117.2 failed

Requested by

GitHub

Duration

00:01:54

Build pipeline

Site

#

Build 20191117.3 failed

Requested by

GitHub

Duration

00:02:06

Build pipeline

Site

regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
#

Users posting the same question in all the help channels at once is a problem that can easily be solved by the bot. Thus, let's add a filter to catch and notify those users.

Implementation details:

  • [ ] Cache one message-user pair per help channel (the latest sent message)
  • [ ] Add a filter that checks if the message and user matches any in the cache
  • [ ] Remove all but one message, then automute the user for a short duration
  • [ ] Notify the user about posting the same question...
regal archBOT
ebon magnetBOT
#

Build 20191118.1 succeeded

Requested by

GitHub

Duration

00:02:16

Build pipeline

Site

oak estuaryBOT
regal archBOT
north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191119.1 succeeded

Requested by

GitHub

Duration

00:03:37

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
ebon magnetBOT
#

Build 20191119.2 succeeded

Requested by

GitHub

Duration

00:01:42

Build pipeline

Bot

regal archBOT
#

Despite the parameter is type-annotated, I feel catching AttributeErrors or using hasattr is better than checking the type. Generally I prefer to not set restrictions on entire types unless I have to. All that is needed here is one attribute - we don't actually care what the type is as long as it can give us a name or nick. Maybe it doesn't matter since the type annotation already "restricts" it. What do you think?

#

Both the user and actor in infraction_to_string need to be modified to be consistent with other outputs (for the actor, it should be plain username + discrim instead of a mention).

Both the search and edit commands could use the expanded endpoint to retrieve usernames (but unfortunately not nicknames). You could fall back to displaying the username in parenthesis if get_member() fails as it'd still be useful if the mention ends up failing due to cache. This applies to the actor too, wh...

regal archBOT
regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
#
[python-discord/site] New branch created: fix\-discord\-tos
ebon magnetBOT
#

Build 20191120.1 succeeded

Requested by

GitHub

Duration

00:02:20

Build pipeline

Site

north knotBOT
regal archBOT
ebon magnetBOT
#

Build 20191120.2 succeeded

Requested by

GitHub

Duration

00:04:22

Build pipeline

Site

regal archBOT
regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191120.3 succeeded

Requested by

GitHub

Duration

00:02:05

Build pipeline

Site

native joltBOT
native joltBOT
north knotBOT
#

Postgres backup completed!

native joltBOT
#
[python-discord/flake8-annotations] New branch created: refactor\-testing
regal archBOT
native joltBOT
native joltBOT
north knotBOT
#

Postgres backup completed!

native joltBOT
native joltBOT
#
[python-discord/flake8-annotations] branch deleted: refactor\-testing
plucky glen
#

What on earth

regal archBOT
regal archBOT
regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
#

I can work on it if I'm assigned to do so.
I say assigned because I'm slow with these things now, so it would take me a little longer than it would take an experienced guy to code it up and then I'd hate to code it up just to see someone else having done it before me.
So if I can be given the job with some time to do it, and that no-one else is to do it meanwhile, then sure, I'd love to work on it.

regal archBOT
#

That would not be my preference.

It creates more visual distance between the helper method and the place where it's being used (which is the test right below the helper method) and this helper method is specifically written for the test that comes just after it. Moving it up would mean having to scroll up and down to understand the test.

regal archBOT
regal archBOT
regal archBOT
#

Abstract

Currently we're only able to read messages that were sent as a DM to our bot that trip our filters. We should relay all messages that are sent to the bot, and who sent it.

Depends on #174 being actioned.

Specification

This should probably be discussed, but I propose we make it work the same as #big-brother does. I'm not certain on the specifics, so if you are, please edit this issue. Essentially I beli...

regal archBOT
#

Abstract

In addition to showing the expiration datetime, display the time delta between the expiration and creation of the infraction.

This is optional, but it would also be useful knowing how much time is left until the infraction expires. I may create a separate issue for this, and if so, link it here.

Specification

Current implementation:

Created: 2019-11-23 20:09
Expires: 2019-11-30 20:15

Suggested implementation:

Created: 2019-11-23 20:09
Expires: 2019...
regal archBOT
#

Abstract

In addition to the creation and expiration datetimes displayed in an infraction search, display how much time is currently left until the infraction expires at the time of invocation.

Specification

Proposal:

Created: 2019-11-23 20:09
Expires: 2019-11-30 20:15
Remaining: 5 days, 1 hour

In regards to granularity, my proposal is to only show the 2 largest units. So if it expires in more than a year, show only years and months. If over a month, show only mont...

regal archBOT
#

I reproduced this by sending 3 duplicate messages, all containing (the same) attachment. Messages do get deleted if they are sent without the attachments.

Ignoring exception in on_message
Traceback (most recent call last):
  File "/home/mark/repos/python/bot-pydis/.venv/lib/python3.7/site-packages/discord/client.py", line 270, in _run_event
    await coro(*args, **kwargs)
  File "/home/mark/repos/python/bot-pydis/bot/cogs/antispam.py", line 203, in on_message
    await self.maybe...
north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
regal archBOT
#

Looks nice! Can you add a 5 second pause to the end of this animation, following the conventions established by the other animated logos? For example, it can blink 6 or 8 times, and then take a 5 second break. During this break it should display the default logo. It's also important that the first frame of the gif is our regular logo (not sure if that's the case here), so that it will display correctly when not hovering.

Otherwise this is good work!

regal archBOT
#

Looks nice! Can you add a 5 second pause to the end of this animation, following the conventions established by the other animated logos? For example, it can blink 6 or 8 times, and then take a 4 second break. During this break it should display the default logo. It's also important that the first frame of the gif is our regular logo (not sure if that's the case here), so that it will display correctly when not hovering.

Otherwise this is good work!

Hey Lemon! Thank you very much ...

regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
regal archBOT
#

Would it be better to utilise the 1-hour expiry of the tokens to not refresh them every time a command is run, instead only if a command is run and the access token is older than an hour? For me, if I were to check the top command, I would probably check the weekly and daily at the same time - even if I was just testing/seeing what the command does. This may reduce some unnecessary token regeneration, keeping the command a little faster.

Something like

# setting:
self.access_tok...
regal archBOT
regal archBOT
#

Hey! I looked at the antimalware.py and felt like I could improve a bit, and I hope I've accomplished that. I look forward to your review of this pull request! :grin:

Here's a list of differences that has been made:

  • Messages are now only checked if they contain 1 or more attachments.
  • Warning message is now in an embed, but the mention is still text so the user still gets pinged. This is more consistent with other reminders (such as this one: https://prnt.sc/q1t6g7)
  • Less if state...
ebon magnetBOT
#

Build 20191125.1 failed

Requested by

GitHub

Duration

00:01:17

Build pipeline

Bot

ebon magnetBOT
#

Build 20191125.2 succeeded

Requested by

GitHub

Duration

00:01:45

Build pipeline

Bot

regal archBOT
#

Don't worry about that, reviews automatically get dismissed when new changes are made. This is because the old review is then considered stale, as in, it's no longer good.

This looks better, but the pause seems to be around 3 seconds. can you make it 4 seconds? I'd be happy to approve it at that point. It looks like I wrote both 5 and 4 seconds in the previous request, sorry about that. 4 is what we want.

regal archBOT
#

Don't worry about that, reviews automatically get dismissed when new changes are made. This is because the old review is then considered stale, as in, it's no longer good.

Ahh, thank you for the explanation. That makes sense 😁

This looks better, but the pause seems to be around 3 seconds. can you make it 4 seconds? I'd be happy to approve it at that point. It looks like I wrote both 5 and 4 seconds in the previous request, sorry about that. 4 is what we want.

Phew, looks like ...

ebon magnetBOT
#

Build 20191125.3 succeeded

Requested by

GitHub

Duration

00:01:42

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191125.4 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
#

@Akarys42 Another channel just for the occasional image attachment relay seems a bit like overkill to me. That means we'd have a mostly empty channel and there are already a lot of channels in that log category for moderators.

Since we're deleting messages, maybe we should make an exception and have the attachments relayed to message-change-log. We normally suppress bulk deletions (like the antispam deletions), but having those attachments relayed there wouldn't be too bad. I think (I ho...

north knotBOT
#

Postgres backup completed!

regal archBOT
#

If the question spans across multiple messages ( For example, message 1 2 and 3 ), would this means we would only cache the 3rd message? What if the user goes to another channel and paste only the 1st and 2nd messages and/or copy paste everything into a new message ( 4th ) and post that 4th in another channel?

In this case would checking for contents and check for similarities across most recent messages ( most recent 3 ) be a better case? For example above 70% from difflib?

regal archBOT
#

Here's a quick example of what I thought of:

TIME_MARKS = (
    (60, 'second'),  # 1 minute
    (60, 'minute'),  # 1 hour
    (24, 'hour'),  # 1 day
    (7, 'day'),  # 1 week
    (4, 'week'),  # 1 month
    (12, 'month'),  # 1 year
    (1, 'year')  # dumb the rest as year
)

def get_duration(date_from: datetime, date_to: datetime) -> str:
    div = abs(date_from - date_to).total_seconds()
    results = []
    for unit, name in TIME_MARKS:
        div, amount = divmod(div...
regal archBOT
#

image

Web console has:

Refused to display 'https://pythondiscord.com/pages/guides/_preview/' in a frame because it set multiple 'X-Frame-Options' headers with conflicting values ('SAMEORIGIN, DENY'). Falling back to 'deny'.

Will need to look into seeing what's up with this one. Might be related to nginx settings yet and have nothing to do with the code.

north knotBOT
#

Postgres backup completed!

regal archBOT
#
[python-discord/bot] New branch created: enhance\-timedelta\-for\-infraction\-expiration
regal archBOT
#

@fiskenslakt I have a question, where would you want to apply this to? Currently I will add it to the embed showing the Expiration ( Expires: date ( duration ) ) like in your example, but I found that there are more than one place with this information - The embed sent to user for example.

In that case, should I also show the user how long ( in human readable format ) their mute / ban will be for, not just when it will expire?

regal archBOT
regal archBOT
#

Closes #668

Introducing 2 helper functions that will get the absolute duration between two datetime:

  • bot.utils.time.get_duration() is the base of the two, which accepts two datetime objects, and return the duration from the two biggest units possible, for example:
    • 11 hours, 59 minutes
    • 1 week, 6 minutes
    • 7 months, 2 weeks
    • 3 years, 3 months
    • 5 minutes
  • bot.utils.time.get_duration_from_expiry() which accepts an expiry in the form of a string isoformat...
ebon magnetBOT
#

Build 20191127.1 succeeded

Requested by

GitHub

Duration

00:01:49

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191127.2 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191127.3 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191127.4 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191127.5 failed

Requested by

GitHub

Duration

00:01:27

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191127.6 succeeded

Requested by

GitHub

Duration

00:01:49

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191127.7 succeeded

Requested by

GitHub

Duration

00:01:56

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191127.8 succeeded

Requested by

GitHub

Duration

00:01:40

Build pipeline

Bot

regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191127.9 failed

Requested by

GitHub

Duration

00:01:22

Build pipeline

Bot

ebon magnetBOT
#

Build 20191127.11 failed

Requested by

GitHub

Duration

00:01:23

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191127.12 failed

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191127.13 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Bot

regal archBOT
regal archBOT
north knotBOT
#

Postgres backup completed!

ebon magnetBOT
#

Build 20191128.1 succeeded

Requested by

GitHub

Duration

00:01:49

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191128.2 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191128.3 succeeded

Requested by

GitHub

Duration

00:01:52

Build pipeline

Bot

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191128.5 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

regal archBOT
#
[python-discord/branding] New branch created: runner
regal archBOT
regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
ebon magnetBOT
#

Build 20191129.1 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

regal archBOT
regal archBOT
regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
#
[python-discord/bot] branch deleted: duck\_pond
north knotBOT
ebon magnetBOT
#

Build 20191130.1 succeeded

Requested by

Leon Sandøy

Duration

00:03:40

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191130.2 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191130.3 succeeded

Requested by

GitHub

Duration

00:01:43

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: message\-edit\-hyperlink
ebon magnetBOT
#

Build 20191130.6 succeeded

Requested by

GitHub

Duration

00:01:40

Build pipeline

Bot

regal archBOT
north knotBOT
ebon magnetBOT
#

Build 20191130.5 succeeded

Requested by

GitHub

Duration

00:03:30

Build pipeline

Bot

oak estuaryBOT
north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191130.7 succeeded

Requested by

Leon Sandøy

Duration

00:03:32

Build pipeline

Bot

regal archBOT
regal archBOT
#

After merging the duck pond, a few minor bugs and potential for improvements have been uncovered. Please make a PR implementing the following changes:

  • [ ] A blacklist for channels that duck pond should ignore. This blacklist must contain #duck-pond itself, #announcements, #staff-announcements and #user-event-announcements.
  • [ ] A command for forcing a message into the duck pond. something like !duckpond, alias !pondify, !duckpondify and !duckify
  • [ ] New test for making sure ...
#

A command for forcing a message into the duck pond. something like !duckpond, alias !pondify, !duckpondify and !duckify

What's the use of this? We discussed such a command before, but the argument was that it was only going to be used for historical messages which can easily be relayed using internal eval on the existing relay_message method of the class.

regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191130.8 failed

Requested by

GitHub

Duration

00:01:13

Build pipeline

Bot

regal archBOT
#

Sort of relevant issue is #131. We never explicitly decided whether we want embeds or not. However, as I wrote in that issue, we did move towards plain messages when writing new code. Still, some old code using embeds remains. So the question is, do we want embeds? If not, then I don't think a simple ctx.send() would warrant a utility function.

Regarding your implementation:

  • random.choice(ERROR_REPLIES) is a frequent pattern. How could the utility function take care of that instea...
native joltBOT
#

After doing some more trawling around the internet I'm still against providing this as the default behavior due to its ambiguity and lack of a deterministic way to statically identify whether the function does or does not explicitly return something.

However, since we already make similar anti-PEP484 concessions for style by providing the capability to suppress missing return annotations by function type, it's worth exploring the level of effort required to add a configuration option that ...

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
#
[python-discord/bot] New branch created: snekbox\-esoteric
ebon magnetBOT
#

Build 20191201.1 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: snekbox\-esoteric
north knotBOT
ebon magnetBOT
#

Build 20191201.2 succeeded

Requested by

GitHub

Duration

00:03:27

Build pipeline

Bot

oak estuaryBOT
regal archBOT
#

This PR contains two updates to the 2019 festive branding pack.

In 6ad5419, the banner receives an overhaul. In particular, we

  • remove excessive glow from the snakes, which was causing perceived blur when viewed in the Discord client,
  • move all elements slightly downward, introducing some unused space at the top, which gets filled with the server settings overlay in Discord,
  • remove the Python Discord text,
  • put the Advent of Code text on a cute festive banner,
  • and make the bac...
#
[python-discord/snekbox] New branch created: python\-3\.8
ebon magnetBOT
#

Build 20191201.1 failed

Requested by

GitHub

Duration

00:01:59

Build pipeline

Snekbox

north knotBOT
#

Postgres backup completed!

regal archBOT
#
[python-discord/snekbox] branch deleted: update\-flake8\-annotations
regal archBOT
#

Abstract

It would be nice to be able to re-evaluate the same snippet if it has been edited, using the same message via an emoji interaction.

Specification

An emoji like this one 🔄 should be added to every evaluated user message, and if the user react with the same emoji on his message (along with the bot), a new eval task should trigger with the updated message content. If the message content wasn’t updated since last eval, the new eval task should silently cancel. Either way, the ...

regal archBOT
ebon magnetBOT
#

Build 20191202.1 failed

Requested by

GitHub

Duration

00:01:20

Build pipeline

Bot

#

Build 20191202.2 failed

Requested by

GitHub

Duration

00:01:20

Build pipeline

Bot

regal archBOT
#

The implementation uses an unnecessary imagining for commands processing with this Literal converter that's handling something entirely capable of being handled by commands groups, which are already well used elsewhere in the project.

This PR has also not been linted before being created. This is not the first time you've created a PR that has lacked the basic care that's expected when contributing.

Due to the above considerations, I'm closing the PR until you can correctly setup your...

regal archBOT
ebon magnetBOT
#

Build 20191202.3 succeeded

Requested by

GitHub

Duration

00:01:50

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
#

It's neither clear that this function returns a timestamp nor that it uses format_infraction specifically to format it. This functions seems to have been designed with only returning the duration in mind and then the timestamp was tacked on towards the end. It could only return the duration, but that would mean two function calls in the mod cogs. It may be fine to just rename this function to format_infraction_with_duration (preferably something shorter if you can think of it) and, of c...

regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191204.1 succeeded

Requested by

GitHub

Duration

00:01:30

Build pipeline

Django Crispy Bulma

regal archBOT
#
[python-discord/bot] New branch created: antimalware\-paste\-url
ebon magnetBOT
#

Build 20191204.1 succeeded

Requested by

GitHub

Duration

00:01:42

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191204.2 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

regal archBOT
#

6869366 Implemented get_duration() for bot.utils.time - ikuyarihS
66ffef0 Added pytest for get_duration() - ikuyarihS
dadb915 Implemented get_duration_from_expiry() which ... - ikuyarihS
4ee0164 Fixed TypeError raised by substracting offset-n... - ikuyarihS
1c84213 Added test for get_duration_from_expiry() - ikuyarihS

#
[python-discord/bot] branch deleted: enhance\-timedelta\-for\-infraction\-expiration
north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191204.3 succeeded

Requested by

GitHub

Duration

00:03:45

Build pipeline

Bot

ebon magnetBOT
#

Build 20191204.4 succeeded

Requested by

GitHub

Duration

00:01:51

Build pipeline

Bot

regal archBOT
regal archBOT
#
[python-discord/bot] branch deleted: antimalware\-paste\-url
north knotBOT
ebon magnetBOT
#

Build 20191204.5 succeeded

Requested by

GitHub

Duration

00:03:27

Build pipeline

Bot

oak estuaryBOT
regal archBOT
ebon magnetBOT
#

Build 20191204.6 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Bot

regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
#
[python-discord/bot] New branch created: Display\-time\-left\-until\-expiration\-of\-infraction
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191204.7 succeeded

Requested by

GitHub

Duration

00:01:52

Build pipeline

Bot

regal archBOT
#

I think this is a good idea, specially for people who can make mistakes in the eval when typing directly like me - it will be very useful to just delete bot's messages, press up arrow, edit a few typo and react 🔄 to re-evaluate the code.

One security concern comes to mind - if use keeps adding and removing 🔄 how will you stop the bot from evaluate the code over and over? ( I assume 🔄 is reacted by bot, so user can easily spam click on it )

regal archBOT
#
[python-discord/bot] New branch created: Write\-unit\-tests\-for\-\`bot/utils/time\.py\`
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191204.8 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191204.10 succeeded

Requested by

GitHub

Duration

00:01:58

Build pipeline

Bot

ebon magnetBOT
#

Build 20191204.11 succeeded

Requested by

GitHub

Duration

00:01:50

Build pipeline

Bot

ebon magnetBOT
#

Build 20191204.12 succeeded

Requested by

GitHub

Duration

00:01:46

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191204.13 succeeded

Requested by

GitHub

Duration

00:01:49

Build pipeline

Bot

ebon magnetBOT
#

Build 20191204.14 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
#
[python-discord/site] New branch created: dependabot/pip/django\-2\.2\.8
ebon magnetBOT
#

Build 20191205.1 succeeded

Requested by

GitHub

Duration

00:02:22

Build pipeline

Site

north knotBOT
#

Postgres backup completed!

north knotBOT
ebon magnetBOT
#

Build 20191205.3 succeeded

Requested by

GitHub

Duration

00:01:48

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

north knotBOT
#

Postgres backup completed!

north knotBOT
#

Postgres backup completed!

regal archBOT
#
[python-discord/bot] New branch created: subclass\-bot
#

Resolves #468

  • [ ] Determine if the custom connector for the session is needed, and if it should be used for the API client and/or discord.py's sessions too.
  • [ ] Write tests? Testing the closing/re-opening may prove to be complicated, but not sure.

Probably don't want to prepends bot.cogs when adding extensions since that would mess up the Extensions extension and require the unload and reload methods to also exhibit this behaviour for consistency while making it impossible to ...

ebon magnetBOT
#

Build 20191208.1 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191208.2 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Bot

native joltBOT
native joltBOT
#
[python-discord/flake8-annotations] New tag created: v1\.1\.1
#
[python-discord/flake8-annotations] tag deleted: v2019\.0
regal archBOT