Given the real-time nature of errors, it'd be nice to have some form of error persistence so that when we are looking to help users we simply search by error ID rather then needing to manually parse logs which are sometimes days worth to maybe find the error.

This would either be done via Garven, or a third party service such as sentry.

My preference is trending towards something in house as the primary use case requires being able to uniquely identify errors, rather then simply tracking if an error has occurred within the service.

When looking at guild aggregation for statistics purposes we base the count off of the latest len(self.bot.guilds), this might be a bug in the sense in theory self.bot.guilds is only ever actually populated on start up.

Relevant line: https://github.com/suggestionsbot/suggestions-bot/blob/master/suggestions/stats.py#L178

In the original implementation of suggestions with reactions, we were able to see a list of everyone who had reacted with a ✅ or a ❌ to a suggestion through the Discord feature of viewing who reacted to a emoji. However, with buttons, we are unable to view this list.

A possible solution would be to have a website to display this list of people who upvoted/downvoted the suggestion.

Ideally it would be nice to remove the dependency on the database for actions which should be IPC.

This will be implemented using Garven

Changes required:

• Shutdown requests
• Guild count aggregation

Summary

This pull request adds the ability to submit anonymous suggestions

Checklist

• [x] Has been manually tested
• [ ] Has unit-tests, if applicable
• [x] New features have attached cooldowns
• [x] Any new strings are localized correctly
• [x] These work on both new and old style suggestions
• [x] All interactions have been deferred

The current approach to statistics gathering takes up a lot of space and looks like

member_stats: MemberStats = await MemberStats.from_id(
            interaction.author.id, interaction.guild_id, self.state
        )
        member_stats.approve_by_message_command.completed_at.append(self.state.now)
        await self.state.member_stats_db.upsert(member_stats, member_stats)
        await self.stats.log_stats(
            interaction.author.id,
            interaction.guild_id,
            self.stats.type.APPROVE_BY_MESSAGE_COMMAND,
        )

I feel this could be shortened dramatically with a helper method

Partially resolves #15

This PR introduces the following 4 new responses: https://gyazo.com/00cfebf5330c462d4179392f8390b71e

• [X] Manual testing
• [X] Handle both types of suggestions
• [X] Ratelimit the commands
• [ ] Write unit-tests
• [x] Add strings to locales files
• [x] Finalize sign off from Anthony for command names + UI look

This also improves the error given when SuggestionNotFound is raised as a side affect to be dynamically shown based on the raisee itself instead of hard-coded.

In order to future proof this being none, rather then needing to guard anywhere it's used we should simply ensure that the lookup path always exists and simply have it default to none

Currently when a suggestion is closed (approved, rejected, clear to an extent) we then need to call many methods in any place it occurs. It'd be nice to abstract this to something like Suggestion.close(...) so that if future methods are added its really simple to modify

Summary

Updates our database interactions to use new syntax

Checklist

• [ ] Has been manually tested
• [ ] Has unit-tests, if applicable
• [ ] New features have attached cooldowns
• [ ] Any new strings are localized correctly
• [ ] These work on both new and old style suggestions
• [ ] All interactions have been deferred

Summary

Adds the ability to persist errors for help at later stages without the need to open the server logs to debug whats happened

Closes #27

Checklist

• [x] Has been manually tested
• [ ] Has unit-tests, if applicable
• [ ] New features have attached cooldowns
• [x] Any new strings are localized correctly
• [x] These work on both new and old style suggestions
• [ ] All interactions have been deferred

The only way to view voters on a suggestion is via message commands. However, restrictions apply based on the permissions of the suggestions channel (ex. our recommended setup). To use message commands, the SEND_MESSAGES permission is required.

In this instance, the slash command will work the same as its message command counterpart; however, it'll just be one voters command. I have some examples below:

Command: /voters [filter:all|upvoters|downvoters]

• /voters filter:all - display all voters
• /voters filter:downvoters - display all downvoters

It's happened a couple times in the past where we have duplicated methods names so we should add a check for it to make sure it doesn't happen again in the future

Currently we endeavor to make unique id's by checking for existence within an in memory set, however, given distribution across clusters this set only remains up to date for the given process and is not updated to match other clusters. Luckily this is validated at the database level as well however we should ideally do something to avoid this becoming a possible issue down the line.

Options: 1: Update the set periodically inline with the database. This however only minimizes the issue and does not remove it fully

2: Move ID generation to a separate service such as Garven which acts independently and doesn't need to worry about state issues as it handles ids for all clusters

Option 2 is likely the better solution in terms of future proofing