Handoff notes for next agent/workflow

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/<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.