Integrate with Contact module

a) this is a grand idea, as already proposed by killes on the old infra (now webmasters) list.

b) project_issue already has mailhandler support (though i've never actually used it -- but will be soon) so it's already possible to create issues via email (assuming it's configured appropriately).

c) however, it seems exceedingly silly for a user to fill out a form, which generates an email, which then gets re-parsed into various fields, and finally created as an issue. ;) why not just give the option to setup a simplified issue creation form on the contact page itself? then, the flow is: user fills out form, form generates an issue, the issue gets emailed out (already including the nid of the issue, the link to follow-up, etc, just like all issue-generated emails).

so, in spite of (b) i still think (c) is worth doing. i'd even consider helping. ;)

-derek

p.s. bug? huh? this is a feature request IMHO...

here's a (fairly complete) start. ;) see the @todo comments at the top of pi_comment.module for what remains.

the main area of work is what to do about anon contact form users:

a) should we always let them create issues, even if they don't have 'create project issues' permissions normally? should we add yet another permission for "create project issues via contact tab" to allow sites flexibility? or, should we assume (like the code does now) if you enable this module and grant anonymous users the ability to use the site-wide contact tab, that you're expecting those issues to be created, even if you don't normally let anonymous users create issues?

b) how should we store their identity and associate it with the issue? should should we have a new {pi_contact_anonymous} table to store issue nid, name, and email for all issues created by anon users, and the hook_nodeapi() to make the name visible when viewing the issue (and make the email visible to site admins)?

c) existing project_issue subscription stuff requires a uid -- anonymous users can't yet subscribe to a single issue. however, perhaps we could just use the {pi_contact_anonymous} table, and reuse a ton of code (ideally, just calling functions directly) out of project_issue/mail.inc to special-case issues created by anonymous users via the contact tab, and always email them any followups to their own issues. of course, http://drupal.org/node/34496 would be the holy grail in this regard.

the other thing that kind of sucks is that core's contact.module makes the admin UI for this much more ugly and difficult than i'd like for 2 reasons:

1) core uses an auto_increment cid for the {contact} table, which makes it very difficult to add the right records to the {pi_contact} table when we're first adding a new category for the contact tab. :( currently, i just punt on this problem, and only allow you to define the issue settings once the category already exists, so we have the cid in the form already. this is lame. the admin UI could also use the new jQuery stuff to change the options for component (and version) once you select the project (right now, that just requires re-visiting the form).

2) core assumes you must have email recipients, so if you alter the form to try to make recipient optional if you define an issue queue for a given category, you'd also have to not call the default core validation and submit handlers at all. that's crappy since a) it means we'd have to duplicate the non-email code in there and b) we'd have to keep a close eye on contact.module to make sure nothing important happens in the submit/validation handlers that we should "port" into pi_contact.module. :(

bright suggestions on any/all of the above are most welcome.

cheers,
-derek

p.s. btw, the idea would be to put all these files into a contact subdirectory of the project_issue dir, but it was easier to make the patch like this at first.

forgot to mention... currently, the idea is the site admin would select the appropriate component and version when configuring the issue queue a given contact tab "Category" would submit into. there are a few reasons:

a) simplifies the UI for the end user, and doesn't ask them to fill in a bunch of fields they don't necessarily know how to set. if you really want them to select different components, you can just create different contact categories and have each of them point to the appropriate components you care about.

b) avoids the problem of different projects (e.g. infra vs. webmasters) have different components, and other contact tab categories wouldn't submit issues at all. i'd rather not *depend* on jQuery for the UI to look reasonable or function in this situation where depending on the category you select, an issue component selector appears/disappears with the right values.

"should we assume (like the code does now) if you enable this module and grant anonymous users the ability to use the site-wide contact tab, that you're expecting those issues to be created, even if you don't normally let anonymous users create issues?"

IMO yes.

"b) how should we store their identity and associate it with the issue? should should we have a new {pi_contact_anonymous} table to store issue nid, name, and email for all issues created by anon users, and the hook_nodeapi() to make the name visible when viewing the issue (and make the email visible to site admins)?"

Sounds like a good idea.

"c) existing project_issue subscription stuff requires a uid -- anonymous users can't yet subscribe to a single issue. however, perhaps we could just use the {pi_contact_anonymous} table, and reuse a ton of code (ideally, just calling functions directly) out of project_issue/mail.inc to special-case issues created by anonymous users via the contact tab, and always email them any followups to their own issues. of course, http://drupal.org/node/34496 would be the holy grail in this regard."

Emailng anon people could be tricky since it can be abused. I guess we could try it, though.

Even without anonymous capabilities, this would be highly useful, especially to the security team. What needs to happen to push it forward?