It would be useful if the q!approve and q!deny commands would be logged in the queuebot-log channel when they're used.

• Include suggestion info in the confirmation dialog, too.
• Custom context
  • ctx.confirm

ex: https://this-is-a.stale-me.me/i/qlou.png

Steps to Reproduce

1. Follow the Debian 10 instructions as provided in the README.md file.
2. Run the bot using Python 3.6.
3. Create a submission in the channel of choice.

Expected Behavior

I should just be able to carry on and deny/approve submissions either using reactions or commands.

Actual Behavior

The bot stops accepting commands and reactions no longer work.

Error Message

1|queuebot  | 2020-07-28 21:50:44,158:INFO:queuebot.cogs.queue: Created new emoji by name tipsfedora in guild 737756609324908624.
1|queuebot  | 2020-07-28 21:50:44,169:INFO:queuebot.cogs.queue: Producing a test image...
1|queuebot  | 2020-07-28 21:50:44,589:ERROR:queuebot.cogs.errors: Error in on_on_message:
1|queuebot  | Traceback (most recent call last):
1|queuebot  |   File "/usr/local/lib/python3.7/dist-packages/discord/client.py", line 312, in _run_event
1|queuebot  |     await coro(*args, **kwargs)
1|queuebot  |   File "/queuebot/queuebot/cogs/queue/__init__.py", line 224, in on_message
1|queuebot  |     await self.handle_suggestion_message(message)
1|queuebot  |   File "/queuebot/queuebot/cogs/queue/__init__.py", line 192, in handle_suggestion_message
1|queuebot  |     await msg.add_reaction(self.config.approve_emoji)
1|queuebot  |   File "/usr/local/lib/python3.7/dist-packages/discord/message.py", line 953, in add_reaction
1|queuebot  |     await self._state.http.add_reaction(self.channel.id, self.id, emoji)
1|queuebot  |   File "/usr/local/lib/python3.7/dist-packages/discord/http.py", line 245, in request
1|queuebot  |     raise HTTPException(r, data)
1|queuebot  | discord.errors.HTTPException: 400 Bad Request (error code: 10014): Unknown Emoji

No error message is provided when using a command, the commands simply do not work.

Config.YAML Settings

approve_emoji_id: 737764731087093760
deny_emoji_id: 735300726573498428

approve_emoji: 'upvote:737764731087093760'
deny_emoji: 'downvote:735300726573498428'

System Configuration

Operating System

Debian 10.3, on a 64-bit version.

Kernel Release

4.19.0-8-cloud-amd64

System Specifications

CPU

Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz

RAM

16 GB DDR4 RAM at 3200 Mhz

PostGresSQL Port

5432 with a timeout of 60.

Impact

This is a high severity bug no matter how you slice it.

So, this bot has an avatar that's based on the :blobcouncil: emoji, but the problem is that the bot still has the same avatar from the reopening, now :blobcouncil: has been remade and colorfixed.
Instead of having a bot owner to fix the avatar everytime :blobcouncil: has been changed, the blob police could have a q!avatar command, that it would grab the emoji or image that has been attached and the bot would change the avatar to the image.

At the moment, the confirmation dialogs for deny/approve and VS dialogs (#5) are not consistent with each other:

It would be nice for VS confirmation dialogs to be updated to use the new confirm context added with fd53686

Perhaps allowing the submitter to add "comments" or "notes" to an emote in queue would allow people who optimize blobs to note what they've changed and allow this to follow into the council queue and approval queue.

Inspiration:

A few recent emoji submissions have had issues with the AMOLED theme available on Discord for Android or were attempting to fix them.

Adding the AMOLED theme to the preview of q!test for static and animated emoji would allow blob makers to test out their creations on the AMOLED theme without necessarily having an Android device to test the AMOLED theme with.

Relevant colours:
Background: #000000
Timestamp: #8d8d8e
Message: #dcddde

Here are some preview images using blobninja.

Currently:

Proposed:

Note that this AMOLED theme preview was made by duplicating the Dark theme's half of the current preview image, then subtracting the Dark theme background using GIMP's Subtract layer mode. It may or may not be suitable for production; if needed, it should be remade.

This would require modifying the schema.

• Modify schema
• Add parameter to q!deny
  • Add subcommand for setting the reason
• Add proper information to status property

This will also require a logic change in how the bot discovers cogs.

We need to track this!

• Show in q!status
• (Maybe) show in q!suggestions?
• Add rejection timestamp
• Add suggestion timestamp
• Add "moved to approval queue" timestamp

This could help find specific suggestions.

Something that might be useful to reduce the burden on finding if someone is inactive or not is to track the last time someone added a reaction in the council-queue. By doing this, we can partially automate the council-queue in that, if a council members stops adding reactions, we can determine if they are inactive (eg if the last time someone added a reaction was a month ago, remove the role automatically).

This could potentially lead the way for automating the addition of the role when a suggestion is fully approved in a similar way, making it easier on police overall.

Current VS vote system:

The main downside to this vote system is that because of the strange way Discord sorts reactions, an emote creator could have their emote resubmission denied not because of the quality of the resubmission itself, but because people erroneously thought the reactions were in order (left one then right one), when in reality they were the other way around.

Proposed VS vote system:

This proposal fixes the aforementioned problem by having the emotes being voted on represented as 1 and 2, so that even if the reactions get sorted incorrectly, it's impossible to get them confused.

Would be a nice QOL feature to add example images that are used in the council queue to also be posted the the public queue. This would allow the public to additionally compare how emojis looks in chat.

Currently, you have to submit it thought the Blob Mail, i think it would be better if you could directly do that thought #submissions by posting something like.

":bloboldname: to :blobnewname: - Note"

What did you do?

q!tested a gif with frame replace;

What happened?

The output image was

What did you expect to happen?

The tears not to get stuck in the output

Currently, if an emoji is too big to fit Discord's limits, the VS never happens.

What did you do?

...

What happened?

...

What did you expect to happen?

...

this is a QOL change that will allow anyone in the server to see what has been submited, like tihngs were before, with b1nb0t, and with manual processing.

• Suggestion metadata
• Emoji name
• User who submitted it
• Suggestion emoji itself (thumbnail)
• (Maybe) Filesize? If so, make it human readable (e.g. 10 MB)
• Show upvotes and downvotes in a compact way, just like in q!sg
• Timestamps
  • Submission time (ideally with relative timestamp, e.g. 10 minutes ago)
  • Validation time (ideally with relative timestamp)
• Forced denial/approval
  • Who did it?
  • Reason

Probably going to use an Embed for this.

Discussion: Should this replace q!status? Or should we just improve q!status as it is outlined here? Or maybe even have both?

Currently this command is not sanitized and will mention the users, so easiest would be to move the info into a rich embed, that way the mentions are still clickable.

Currently all the messages are hard-coded in the /queuebot/utils/messages.py file, however, what if I'd want to change the channel for SUGGESTION_APPROVED to my own channel? I'd have to edit that file, which would make it annoying to update due to git.
Maybe there should be like an optional constants.py in the root dir, if the user makes it, they can override any of the messages, so if you'd have BAD_SUGGESTION_MSG in the constants.py, it would use that one instead of the messages.py's one, but it would still use the messages.py for others ones seeing as they wouldn't be in the constants.py

So for the emoji name for suggestion :bloblol: would be e.g. :bloblol_55: or something like that. Easier to know what the suggestion ID is, instead of running the q!sg command.

The custom help formatter is quite noisy. It also doesn't allow users to view help for individual commands, and I'd rather just rip it out instead of implementing that.

Thoughts? @SnowyLuma @Gorialis

It's not open source free software till you add a license. I recommend AGPLv3 because it requires you to publish the source code whenever you update the bot server.

At this time, the current workflow for blob suggestions goes like this:

• User uploads a suggested blob into the suggestions channel, this is then posted to council-queue
• The council decide whether it's a good blob or not. If council says it's good, they vote yes and then it's moved to public queue.
• When moved to public queue, the public vote on the suggestion. After a few days, if the public majority agrees to add the blob, Wolfiri (or another police) makes sure and then uploads to a server.

While this is ok, this can slow down the addition of new blob suggestions, especially as they have to be uploaded to another server that users need to be a member of. This also means police then have to find the user who had their suggestion approved and then add the Blob Maker role.

An ideal solution would be to automate the whole queue, so that police aren't involved so heavily on uploading the emoji, but still retaining oversight. In this idea, the ideal workflow is this:

• User uploads a suggested blob into the suggestions channel, this is then posted to council-queue
• The council decide whether it's a good blob or not. If council says it's good, they vote yes and then it's moved to public queue.
• When moved to public queue, the public vote on the suggestion.
• The bot will then track all reactions added: if more than X total reactions have been added, and there are Y more approvals than denials, the bot tells police they need to vote to add the bot. EG 750 total reactions, with 200 more approvals than denials
• Once blob police have been notified, they then do reaction votes: 4 approvals and the emoji is uploaded to a server and the submitter gets the role. 4 denials and the emoji is rejected and the user informed. (I do not generally expect that an emoji that reaches this point would ever be denied, but that option should be there, in the case of shitpost/meme-based blobs)

The numbers would be changeable of course, this is just to give an idea of what the ideal flow would be. Automating the workflow gives us more choice to make a bunch of stats from each stage and, in addition, would tie in nicely with ticket #8.

this will allow us to rename a confusing name ( eg, :blobglare:) for a new name ( :blobglarereverse:)