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.
