Abstract back-end for integration with 3rd party issue trackers

Yes, I already thought about this, too. However, the goal must be to abstract the current logic in a way that any issue tracking system can be used as back-end.

The one who will work on this issue should assign it to herself in front of doing so.

I think I will be doing a part of this this week. I intend to create a patch for this module allowing administrators to extend/edit the feedback fields which, in turn, will go some way towards allowing integration with other systems. Here's the plan:

• Create a simple database storage mechanism for keeping multiple Feedback text fields
• Extend the feedback table to capture responses to additional fields (if provided)
• Create an admin mechanism for creating/updating/deleting/changing the order of Feedback fields (and corresponding data)
• Allow administrators to select which Feedback field is the one shown under "Message" in the admin section (variable)
• Move the current set-up (single Feedback field and text) to the "default" pre-installed setting
• Update hook_install and hook_update_N accordingly

I was going to create a new table called feedback_fields, containing the following columns:

• field_id (would use fid, but this could be confused with fid in the feedback table, which is "feedback ID" AFAIK)
• title
• type (only intend to add textarea for now, but will allow other types moving forward, e.g. hidden, text, date, etc.)

And also extend the feedback table with an additional field_id column storing which "message" belongs to which "field".

So, for example, if someone creates three feedback fields and a user enters data in all three fields, there will be three rows in the feedback table - one for each field. Each of these three rows will have the same values *except* message and field_id, which will be different for each row.

In Drupal 6 I doubt there's a huge amount of point in going much further than this, as when we hit Drupal 7 with this all the data will be able to be stored in the FieldAPI and the feedback_fields table will probably be immediately obsolete. So I'm doing this now to start the ball rolling and satisfy a client need, but it will be all change as soon as I start to play with the Drupal 7 version. =)

Thanks for working on this!

A couple of notes:

1. Work on this and related issues should target D7 (HEAD), as it would be a über-major waste of time to introduce something like configurable fields for native/default Feedback entries/entities in D6.
2. I agree that native feedback messages/entries (i.e. those the module provides now) should be using the entity API + made fieldable.
3. This issue, however, is rather about abstracting Feedback's message storage, so as to allow to NOT store messages in Feedback's native "entity" but for example in a node instead, whereas "node" can mean integration with project_issue module, casetracker module, any configured node type, or whatever. Thus, it's not about configuring fields, but rather about configuring the target "entity" to use for feedback messages, which could even be a private message using privatemsg module. Therefore, it's about configuring the target entity, and along that way, about configuring something along the lines of a "field mappping" to specify how e.g. a project_issue node should be populated.
4. Thinking ahead, this issue effectively means to
   
   1. either implement a mapping from Feedback's form to the actual target entity's data structure
   2. or to entirely replace Feedback's form with the form of the target entity, but (more or less) retaining Feedback's UI (which wants to be pluggable too; see other issue in the queue)

I hope I make sense, as I didn't think too long about this and related issues (yet). So feel free to argue for or against. ;)

I see your situation and know that very well. I'm not entirely sure what exactly you need for your site, but it sounds like you need Feedback to store its data in a configurable and extensible entity, so as to allow to add further fields to its form/UI. If that is the case, the common denominator for this project and your site's use-case, already for D6, would be to

1. Implement the pluggable storage (+ possibly mapping?). Configure the storage to use on a new settings page.
2. Add a feedback_node module, which uses a(ny) configurable content type as storage. Status handling for each message can be deferred to another issue or perhaps dismissed at all and left to the site builder (to add field_permissions module + a checkbox/select to choose the status).
3. Which allows you to use a certain node type for feedback messages, add arbitrary fields to it, and do anything else you want to do.

I'm still not sure whether we need the additional abstraction + field mapping. One one hand, it sounds convoluted and unnecessary, as Feedback could merely expose a UI for entering/sending feedback, regardless of entity. OTOH, I'm not sure whether we will loose possibilities if the entity form + storage is completely detached and unknown/uncertain for Feedback (e.g. what about BrowsCap integration; what title to store for nodes; etc).

Just looking at the Unfuddle Feedback module NikLP posted above:
http://drupal.org/project/unfuddle_feedback

It just adds a submit function to feedback_form() - that seems like a good approach - just set the submit function according to the selected/available storage option(s).

Edit: Looking deeper, feedback_add_entry() is a far better place to do this. We could make a hook here.

Ok, this patch really does need review. This is an "alpha" version of the storage mechanism totally detached from the module. Changes from the last patch:

• No unnecessary module_invoke_all() calls - switched to storing the module to be used for storage in a variable and using module_invoke() instead, since it silly to make the modules being invoked check to see if they should be!
• Made feedback *viewing* happen by hook too, both on feedback forms and in admin
• This now seems to work for the 'basic storage' option (see the new feedback_feedback_storage() function in feedback.module)

Look forward to getting your feedback on this.

Edit: Next task is to work on the feedback_node module, which will have its own implementation of hook_feedback_storage() and will also form_alter the feedback entry form to show any CCK fields on the feedback form. Also need to work out where we'll store the additional information - may continue to use the 'basic storage' mechanism from the main feedback module for user agent, page, etc. and store *additional* fields in a node.

(Btw, just realised, I've made a mistake and made this against 6.x-2.1. I don't know how much difference there is between that version and 6.x-2.x-dev at the moment, but I'll re-roll a patch against dev once this is all reviewed, if that's ok with you?)

Oh please do not roll patches against downloaded packages. We need a patch based on the CVS DRUPAL-6--2 branch.

Initial review:

1. That $op argument pattern for hooks is a thing of the past. We want to use separate hooks like in D7, i.e.

   hook_feedback_info() (ex. type)
   hook_feedback_form()
   hook_feedback_load()
   hook_feedback_save()
   hook_feedback_view()
   hook_feedback_delete() (later)

2. I'm not sure why actions are mixed into this patch. Can we remove those, please?
3. Minor: Plenty of trailing white-space in this patch. ;)

As luck would have it it seems there's no difference right now between 6.x-2.1 and the CVS DRUPAL-6--2 branch, so I was able to just re-apply my code there as a patch. Here's a re-rolled patch again CVS.

1. Hooks have been split out - they are currently:

   hook_feedback_storage() <- returns name and module for admin
   hook_feedback_storage_fields() <- add fields in to feedback_form()
   hook_feedback_storage_view() <- get feedback to display on the admin report
   hook_feedback_storage_load() <- get feedback to display in context in feedback_form()
   hook_feedback_storage_insert() <- save a piece of feedback

   Didn't bother with a delete hook yet. Current UI doesn't need it, as you can't delete feedback.

   Are the hook names you propose in #13 suggestions or instructions? If they're instructions, I'll use exactly your hook names. ;-)

2. Removed!
3. Tried to catch as much of this as I could - if I missed any, let me know.

Edit: Aside from potential hook renaming to apply conventions from elsewhere in core/contrib, this is probably nearly ready for commit. I think I will move over to #351698: Use entities for Feedback messages to post a patch adding the feedback_node module to the package. Otherwise this patch will become too big.

This patch should apply cleanly to DRUPAL-6--2.

1. Ok, will rename (tomorrow), no problem.
2. I prefer a) mainly because it's easier! feedback_node can just ship with a view. ;-)
3. Ok, so we're saying rather than build half the form in the hook and half the form in feedback.module, ask the storage module to provide the entire form? That probably does need to be dynamically loaded in hook_menu, but I think that makes sense if I'm understanding you correctly.

Any further thoughts on this? Is the patch good to go, or is there a little more to do?

I'm running out of the window of time I'm able to work on this for, so it would be good to finish my work if someone has time to review. I'd like to write the feedback_node module next week, but want to make sure the API is accepted first! =)

Dang. I really need to get back to this issue and patch.

Actually looks pretty solid from a quick peek. Didn't test it and didn't totally think through the entire design though, and that's what takes a serious amount of time and/or confidence :)

Sorry, greg!

Unassigning, I can't see me getting time to work on this any time soon.