* Update DB when unthreaded messages are deleted
* Add required library libatomic1 to Dockerfile (#71)
* Handle quick message deletions
This is a quick and dirty way to handle the bug, but it works.
I also realised that handle_question_deletion() doesn't delete it in #tickets
* Create a system for tracking bot messages attached to tickets
* Ensure resolved message is added to userFacingMsgs
TODO I''ll need to make a function that all the macros can use to send a user-facing message
* Add a reply_to_ticket() helper for updating the DB
while replying to a ticket
* Fix type errors in reply_to_ticket()
* Use reply_to_ticket when resolving tickets
* Fix type errors in message.py
* Create delete_replies_to_ticket()
* Remove unused parameter in delete_replies_to_ticket
* Rename BotMessage.msgTs to BotMessage.ts
* Write a stub delete_and_clean_up_ticket function
* Partially implement delete_and_clean_up_ticket
* Delete "ticket" message in delete_and_clean_up_ticket()
* Use the new ticket methods where appropriate
* Make function name clearer ("delete_bot_replies")
* Log if a question is deleted but not present in DB
* Fix error when normal messages are deleted
* Actually include userFacingMsgs in the query when deleting bot replies
* Add success heartbeat to delete queue
* Document the deletion queue needing workspace admin
* Don't use delete queue in ticket_methods.py
This is because the delete queue requires an admin token, ew
* Fix deleting the backend message on ticket deletion
* Always preserve support threads with >3 bot messages
This is so that if someone runs ?faq, the ticket still counts as being resolved in the DB.
* Debug-log message event data instead of printing
* Use the reply_to_ticket util in macros
---------
Co-authored-by: RandomSearch <101704343+RandomSearch18@users.noreply.github.com>
* Differentiate between message creation and deletion
* Add a comment to explain thread_broadcast
* If top-level message gets deleted, then delete bot messages
* Ensure top-level messages being deleted don't cause errors
It would previously freak out when the tombstone message gets deleted :P
* Remove deleted tickets from DB
* Actually delete the correct ticket
* Ensure unexpected SlackApiErrors are re-raised
* refactor: Move deleted message handling into its own file
* Add some logging for time spent generating the Dashboard
* Start adding perf logging to get_ticket_status_pie_chart
* Add more detailed logs to ticket_status_pie
* Use db.ticket.count() instead of fetching all tickets for pie chart
Querying the database used to take 0.25s avg, now the query takes 0.028s avg (tested with 20k records)
Generating pie chart used to take 1.3s, now it's 0.74s. That's a 43% speedup I think! Although the pie chart isn't the only thing that takes time to load on the dashboard.
* Remove status_counts dict
I think the code reads nicer without the extra dict. Now we just have each variable listed inline in a list, which matches how the labels and colours are defined.
* Downgrade profiling logs to DEBUG level
* Add a script for creating dummy DB records
* Note that add_dummy_data takes a while to run
* Change the dummy data range to 2 weeks
* Ensure the dummy data script sets all the timestamps
Previously it wouldn't set assignedAt, closedAt, etc, despite the ticket being marked as closed
