Jason Thistlethwaite
107 lines
4.5 KiB
Markdown
107 lines
4.5 KiB
Markdown
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/<contact_id>/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.
|