hhamana/slack-r

Slack client for jokers

slack-r's Issues

Tests

I've been developing functionality with some external server mocking endpoints I use with some fixed responses, but manual checking is starting to take its toll as functionalities and complexity increases.
Integration tests should be developed to settle what works and detect future breaking changes.
However, Rust's strong typing makes it extremely hard to mock things, and this bot makes extensive use of third-party calls (Slack).
Instead of mocking then, some sort of server mimicking Slack should be re-implemented to respond when running tests.

Show member names

While ID obfuscate the random choice effectively, it makes it much harder to adapt to sudden changes (member will be off on a certain day, for instance, which the bot cannot know, even with #7.)
Might require saving member names along with IDs when adding from add channel or add member, and adapt config.json members from a Vec to a Hashmap ( {"id": "name"}.

Customizable text and tasks

The joke command could be given a more generic name, like task, and the text to send should be customizable.
One could register different kind of tasks, referring to the message, and use the bot to schedule different kind of messages.

This would change the flow to something like this

$ slack-r task joke -d "yyyy-mm-dd"
<user> was assigned to a joke on <day>
$ slack-r task huddle -d "yyyy-mm-dd"
The huddle on <day> will be chaired by <user>
$ slack-r task flower -d "yyyy-mm-dd"
The flower should be watered by <user> on <day>

The duplicate check logic would have to check for the specific looked pattern so many flows can be scheduled on the same day in parallel.

Schedule several days in a single run

This would allow less commands to type instead of one by one, but also remove the need to check for pending scheduled message in-between, while running on the same connection, therefore much more resource efficient.

Could be either

• range defintion: "schedule everything from this day (defaulting today) until that day".
• define list of days to schedule
  Weekend in-between should still be shifted.
  It could be implemented by either running the joke method several time from a parent function, or fundamentally refactoring it so it works on a Vec.
  For the efficiency goals mentionned above, it appears it might require a fundamental refactor.

Duplicate prevention bypass

The current duplicate prevention logic needs to consider the scheduled time, and compare to already scheduled messages, in Local/UTC time. This must take into account shifted times for the weekend cases.

It should also offer a bypass by a flag, such as --force, and offer to use it when blocking a message.

Prevent self-reference

On a add channel <channel> command, if the bot is already present, its own ID will be included in the list of channel members.
The bot should make sure to not in include itself in the list of members in config.

Prevent successively picking the same member

Hold an internal count of which members have been used already, and filter them out of the random pick (check blacklist, or pick from whitelist). Reset after all members have been picked once, so the cycle can be repeated.
Considerations:

• Need to be stored statically so as to not "forget" between runs. Every run will then be forced to read config at first and write config at the end to update.
• Should check if there's an issue if it panics in-between pick and update
• Logic must be shared between reroll and joke.

Delete scheduled messages

Allow a flow to delete mistakes/reroll, in combination with the scheduled command.

Scheduled Display should show the ID information in a clear way to reuse and work with it, also using Local times.
then add a delete <id> command to delete the targeted ID, with confirmation showing the scheduled message to be deleted.