diff --git a/TODO.md b/TODO.md new file mode 100644 index 0000000..9db3997 --- /dev/null +++ b/TODO.md @@ -0,0 +1,106 @@ +This file contains mostly longer-horizon ideas for this project. + +## redMCP + +[ ] Basic search backed by Redmine's existing API, full text searching: + [ ] Issues + [ ] Contacts + +[ ] Paged getting/fetching of issues matching simple criteria such as: + [ ] Project + [ ] Last updated or created + [ ] Status + +## Other / uncertain + +[ ] Contact disambiguation with Gmail/Google + [ ] Cross-reference contacts for a given project in Redmine with Google Contacts, then + intelligently update them so they match the same information. + + [ ] Contacts present in Redmine but missing from Gmail should be added to Gmail + +## Redmine (plugins) + +- [ ] /contacts//tabs/helpdesk helpdesk tickets list improvements: + - [ ] Show dates created and last updated + - [ ] Simple search function + - [ ] Paging / don't shit the bed for contacts who have hundreds of closed tickets + - [ ] LLM summary showing the key things the person has mentioned recently + +- [ ] Issue tagging - free-form (?) tagging for issues, where IDs are shared across projects + +[ ] Watchers notification settings + If there are mechanisms available, other than email, to notify people who are watches on + a ticket, they should be able to configure some settings about that. + + Examples might include: + + - Webhook + - Text message + +[ ] Better send/initiate email support + As it stands, the two ways to initiate email using the Helpdesk plugin are clunky. + + Method 1: Find the contact under contacts, click to send them an email, and it makes the + user fill out the from/reply-to address -- which defaults to the one they used + to sign up with redmine. That's typically an issue for two different reasons. + + a. It means that if the contact responds to it, the ticket probably won't show up + in redmine. It will just go to the employee's inbox. + + b. Doing this doesn't create a ticket/issue unless the contact responds, which can + be a problem if we need records of who has been emailed and about what. + + Method 2: The user can click "New Issue" inside of a project, select that it's a support + ticket, and then they get an option asking about what kind of ticket. They have a + confusing drop-down that defaults to not sending an email. It's just extra headache + to teach and manage employees to deal with this. + + Another issue with this is that when it does send an email, it doesn't put the header/footer + from Helpdesk on it, and the user isn't exactly told that's the case. + + A very simple "New Ticket -> Email" option would be very useful that just acts like people + who use Gmail would expect it to act. + +[ ] Helpdesk: better footers/signatures + As it stands, email footers/signatures are project based and can't easily be customized on + a per-user basis (not quite). It would be nice if they had support for macros that will add + the employee's job title, contact info, etc. I think it already has this feature to some + extent, but it's not very good. + +[ ] Helpdesk: more direct spam / blocklist / filtering ability + Helpdesk might not be the best place to implement this, but it seems like it's worth + thinking about. + + Here are common issues we run into (over 10 years of using this): + + - We _do_ want some emails from @amazon.com, but not everything. Existing features do not + really cover anything about this. Amazon.com is just an example. + + +[ ] Rules engine for email -> ticket imports + The rules provided by the existing plugin are not very useful. It would be much more useful + if we were able to do things like this: + + [ ] Based on some criteria, send a different auto response template to certain contacts + + [ ] Import a ticket as normal, but don't send an auto-reply. Instead, pass the imported data + to some other program which then decides whether or not to send an autoresponse, what it + should include, etc. If a response is sent, the ticket should be updated to include it. + + +[ ] Draft + A very simple way to save a draft response to a ticket, so it does not get emailed to + anybody. However, any legit/authorized user who can see/edit the ticket can see the + draft and choose to edit or send it. + + [ ] We should be able to search by whether or not tickets have drafts. + This is for these reasons: + [ ] We may want to present the user with a list of ticket drafts they need to + approve/deny/edit before they will be sent. + + [ ] We may have an agent write drafts, and in doing so, it should be able to focus + on tickets that need a draft and don't have one already. + + [ ] It's completely fine if this is implemented using something more like a custom + field, but I suspect a plugin will be what we want.