I was wondering if it were possible to add a hook that gets invoked when a new feedback entry is added. In my case, I want to use the hook to fire off an email when a new entry is added. I know the issue of email notifications has come up on the queue in the past and that the recommendation is to integrate with other modules that handle email/messaging, but such a hook could be used for more than just forwarding. Also, for people that are just looking for a one-off feature addition to the feedback entry addition could just use this hook to quickly achieve whatever they want for their purposes without adding too much overhead to the default implementation itself.
I can include a 6.x path if requested.
Also, a hook that fires when the status of a feedback entry is updated might also be useful, but I personally don't need it for my current project.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | feedback-HEAD.crud-cleanup.17.patch | 8.96 KB | sun |
| #15 | feedback-402438-15.patch | 11.65 KB | jody lynn |
| #13 | feedback-402438-13.patch | 11.42 KB | jody lynn |
| #11 | feedback-402438-11.patch | 11.71 KB | jody lynn |
| #10 | feedback-402438-10.patch | 7.54 KB | jody lynn |
Comments
Comment #1
sunWe can do this. However:
a) I do not want to see a contrib module called feedback_forward module, ever. The idea is wrong (reasoning in the other issue).
b) The hooks must use the new style of system object hooks in Drupal 7, which means: hook_feedback_load, hook_feedback_insert, hook_feedback_update, hook_feedback_delete
Comment #2
jody lynnDuplicate of #293512: Abstract back-end for integration with 3rd party issue trackers
Comment #3
sunWe should tackle this issue first and introduce D7-style API hooks for _load, _insert, _update, and _delete.
#353548: Add trigger/action for e-mail notification will have to be revised on that.
Comment #4
jody lynnComment #5
jody lynnWork in progress, have just the feedback_load invoke and started a corresponding feedback.api.php to document the new hooks.
Comment #6
sunThanks! Looks like a clean and good start!
Note that this overall issue likely requires us to change and/or introduce proper API functions for feedback messages. If I'm not mistaken, then the CRUD API operations are incomplete currently.
Either way, the goal is to mimic the usual design of
node_load() ( -> node_load_multiple())
node_load_multiple()
node_save()
node_delete()
node_delete_multiple()
Comment #7
jody lynnUpdated the _load function to use _load_multiple and to use similar parameters as the node/user functions. I think that's what you're going for, without going all the way into entities yet.
Yeah, I'm planning to do the rest of the functions including delete even though there is not yet a UI for deletion.
Comment #8
sunThose should use feedback_load_multiple().
We can drop the additional phpDoc description, but let's update the summary to be in the third-person form; i.e., "Loads" instead of "Load".
Wraps too early (before 80 chars).
Trailing white-space.
feedback_load_multiple() returns an array, so this needs to be updated to correspond to similar loader functions in core; essentially:
Powered by Dreditor.
Comment #9
jody lynnI made those changes and added feedback_save and hook_feedback_insert/hook_feedback_update.
Still need to do the delete functions.
Comment #10
jody lynnJust fixed one comment length.
Comment #11
jody lynnThis patch has the load, load_multiple, save, delete and delete_multiple functions with hooks insert, update, load and delete. Also has all the db queries using these functions.
Comment #12
sunThis looks really awesome!
When updating feedback entries through the admin UI, then various properties are unintentionally reset/updated.
For now, we may want to wrap all of the property updates/overrides into separate !isset() conditions.
In the long run, we're going to need a feedback_new() resp. feedback_create() [Entity API module call it _create; elsewhere I called it _new] function that takes an array of key/value pairs and initiates a new feedback entry object with those property/value pairs + defaults for all others. We can already do this now, if you want.
Those minimally exceed 80 chars. (see Dreditor)
Save functions normally do not return the entity -- objects are references in PHP5.
Normally, the module hook is invoked after the fact; i.e. after deletion. Let's make this consistent.
These changes look great, but I don't think all of them are necessary.
For the reassign method, we can leave the direct database update, I think.
The delete method is outdated and no longer invoked for hook_user_cancel(). Instead, modules need to implement hook_user_delete().
Powered by Dreditor.
Comment #13
jody lynnThanks for the great reviews.
Changed everything above except:
The comment line lengths. They look right to me in dreditor, but I think I'm missing something since you're the dreditor expert. They're supposed to be just left of the vertical line, right?
Placement of the delete hook. I put it above the actual deletion to be consistent with user_delete_multiple and node_delete_multiple. node_delete_multiple has a comment explaining that rationale: // Delete after calling hooks so that they can query node tables as needed.
Comment #14
sunThank you! This looks great!
The only two remarks that remain from my side are:
All comments should wrap at 80 chars; so for example, this line wraps exactly at 81 chars (+1). In Dreditor, the line is supposed to end right before the vertical bar (whereas this line ends "on" the vertical bar).
After adjusting this one we can move forward. :) [You probably know that I take Drupal coding standards überseriously. ;)]
This still feels a bit sloppy for me, since modules cannot preset any of these properties without getting overwritten. But unless you want to shift every single of those assignments into a corresponding !isset($entry->property) conditional now, we can also leave that for later (and potentially go with the _new()/_create() function instead then).
Powered by Dreditor.
Comment #15
jody lynnOk, finally got the comment length figured out in my text editor, and I wrapped all those pre-insert values in issets.
Comment #16
sun;)
Slightly changed the order of functions (to have _load() come before _load_multiple()). Also changed the conditional defaults in feedback_save() into cleaner
!isset()control structures.Also added very basic initial tests in a separate commit, in order to verify that the basic Feedback functionality still works.
Thanks for reporting, reviewing, and testing! Committed to HEAD.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #17
sunSome minor follow-up clean-ups. Should technically be a separate issue, but I'm too lazy right now.
Comment #18
sunAlso committed the follow-up in #17.
@Jody Lynn: Please make sure to have a look at those changes, thanks :)