Adding comments to a flag (flag history)

It's possible, any is ;) But I doubt you'll get the maintainers to add it to the module directly.

Instead, I would suggest taking a look at how Flag Friend (http://drupal.org/project/flag_friend) works with Flag's API in order to do something similar. Flag Friend allows the sending of a message when you flag a person. You could use a similar technique to accomplish what you're looking to do I believe.

I would love to see this functionality as well. We're using this module as an inappropriate content flagging system. It would be great to allow users to write a message as to why they're flagging rather than have a generic "inappropriate" thing, and without resorting to multiple flagging categories.

Andrey.

I've also used Flag as a means to flag inappropriate content. I've also added some extra functionality for administrators to unflag things and have a few other things I'd like to add here: http://drupal.org/project/flag_abuse

This might be more of a feature request for that module.

I think adding a comment to a flag can be used in other instances besides abuse flagging.

I'll start looking into implementation in a bit.

Any ideas?

Best,
Andrey.

As I said in #1, flag_friend has a way to do this, so take a look at that code and you can probably rip out the relevant parts.

We've discussed creating a "flag_history" module in the past that would make this a generic piece of functionality.

http://drupal.org/project/issues/flag?text=flag_history&status=All

+subscribe. Flag content have this feature and they are going to port it to D6

I don't see why you would want flag to store a comment as well. This data would make a lot more sense to put into the node tables. I'm not sure what the exact workflow would be, but I doubt it would be too difficult to put a node entry form where you need it and relate it to the two users.

Or, you could do what sirkitree suggested and make flag_friend's message system into a separate module.

Marking as postponed.

Marked #400900: associate a text / message with a flag as a duplicate of this issue.

two examples:

1. flag friend with comment (ok flag_friend has it but this could be done in a more generic way)
2. flag a node for abuse with a message

generally: add a memo with a flag
(p.s. the issue markes as duplicate was the oldest one actually)

@gunzip: What about when a user uses a certain flag, popup a flag-memo node form and prepopulate it with a nodereference to the node you just flagged?

i think it's a bigger overhead than adding a text field in the flag table. anyway thanks for the hint =)

To help with the overhead, you could clean up the nodes that are no longer useful.

Guys, this is must-have feature. With comments Flag can be used to make document workflows with audit history.
Flag + Rules = complete workflow, no need for buggy and unmaintained Workflow module.

+1 suscribing

+1 subscribe

I'm also interested in this for the ability to document reasons for adding a flag.

flag friend uses its own table to store messages

is someone already working on a module or something?

This issue shouldn't be postponed, since it's not waiting on anything.

back silence is correct that a separate table would be necessary for this feature (and probably a separate module). There is nothing preventing this behavior in any way, it's just a matter of someone taking the time to write it. We need a separate table because the same piece of content may be flagged or unflagged multiple times, and each time a message should be left on why the content is being flagged or unflagged. We can't just use the existing "flag_content" table because it only stores a single row, so if a piece of content were flagged, then unflagged, the message on why the content was flagged would be completely deleted.

So that's why I've suggested a few times in the past calling the module "Flag History", so that you can see the flagging history on why a piece of content was flagged or unflagged.

No one is writing this module as far as I know.

with the way it works in flag_friend, you will not be able to keep a history.

flag messages reference entries in the flag_content table, thus when content is unflagged, all comments will be lost. you could only workaround that by duplicating the flag_content table and not deleting anything from that new table - a full history of all flags

this is probly more than my customer wants so i guess i will not write this kind of module. but i'll ask him, maybe he wanna pay that :)

you may modify the attached module to suit your needs, it will NOT run in a normal drupal install.

license: GPL v2

description:
adds a comment text field when flagging a node, and a menu callback to view the messages

this is quick and dirty, please don't complain

i did a rewrite of @black silence module that runs on a normal drupal installation and integrates with views and popup.

it's a merge between @black silence flag_comment and flag_friend code.
i think that the name "flag_comment" is somewhat ambiguos, so i renamed it to "flag_message".

this doesn't build any flag history. it just ties a message (the last one) with a flag.
messages are displayed through views (default views not provided).

if everybody agrees i can make a project page for this.

if there's the need to keep old flags and messages (flag history) i can work on it.
the problem imho is not to save this information, but to implement a decent view integration for that
(a relationship with flag_content table or with node/user ?)

p.s. does anybody know this: when you already have drupal cvs account (because you are a project mantainer) do you have to ask CVS mantainers for every project/module you create ?

@gunzip I guess great minds think alike - well almost. I've actually also just built a module Flag Note that does essentially the same thing as flag_message (comment 21). I see advantages to some aspects of both modules and am wondering if you'd like to join efforts and put together the best of both. The main differences are

Things I like better about flag_message

• has views integration
• uses pop-ups which are cool for this purpose

Things I like better about flag_note

• uses flag hooks, such as hook_flag_link_types which adds a new link type as opposed to using an admin form & variables
• has it's own form instead of form_altering the confirmation form
• tabs for the admin to view notes for each flag separately

So .. if you have a CVS account and would like to pull these two modules into one better one, I'll happily make you co-maintainer :-)

It seems that there's plenty of need for this functionality, and I'm glad that we're close to having an easy to use way to do it.

Please let me know what you think..

sure :]

i like the hook_flag_link_types idea and the better handling of flag/node deletion. these are my first notes about flag_note:

• there should be an index on fcid too (see below for other considerations about the primary key)
• fcid which is an "int small" should be just "int" to behave like the fcid in flag module
• once you have views integration, flagged_notes_listing pages would become redundant (you can just provide some default views in case)
• i see that the note is a varchar 255, why not just a text field ?
• DELETE FROM {flag_note} WHERE content_id = %d (there's no content_id in the table)
• DELETE FROM {flag_note} WHERE fid=%d (there's no fid in the table)

EDIT:

above all, if you want to mantain multiple flags for a content_id then you have to save the whole information about the flag
(not just the flag_content id) because when the content gets unflagged you still want to keep the older flag notes. so you have to save
the type of operation (flag/unflag), flag name, timestamp, content_id, etc.

in the other case, if you only want to keep the latest note then the primary key "fccid" is not needed because you have a one to one relation with flag_content.

i see you want to delete notes based on content type in nodeapi but you cannot do this without checking for the content type too (user or node ?). you risk to delete users instead of nodes and viceversa.

I'm doing a quick rewrite integrating views/popup, then I'll send to you the result. I'll be glad to be a co-mantainer but we have to clarify if we want a flag history or just a flag note =)

Excellent !!! Wow, I sure left a bunch of holes ... do'h ... good eyes @gunzip.

I think all your ideas are great .

1. ids should be unsigned INT (11) - dunno why I made then (5) ..
2. note column is varchar(255) out of habit... no real reason why it shouldn't be TEXT
3. In views, can we expose the flag as well as the notes, i.e. so user can sort/segregate by flag? I suppose that this would make flagged_notes_listing redundant, but it might be worthwhile to leave it in because it's handy for the admin - and use views_build_view (or whatever its called in D6) to feed the page output ?
4. Regarding "you have to save the whole information about the flag". Wouldn't you just need to include fid? As it is, if I need flag info, I'm joining flag_note to flag_content (fcid), which of course holds fid. If we want to use this thing store history ...
5. ... then there's clearly a little more juicing up of the model needed. I wasn't considering that, but if it's such a simple model, that it probably won't hurt to include it.
6. I agree that fccid is not needed ... unless someone (like us?) want's to hang something off flag_note ... like history ;-) ?? I pretty much stuck in it there out of habit. I get uncomfortable if there's no primary key. SInce, at the momemnt, flag_note is one-to-one with flag_content, fcid is all we need to the PK. But, if we want to keep history, or some other unknown requirement, we might as well keep it ?
7. I thought about the nodeapi a little while ago, and I also realized the smae thing re: delete. But for some reason, I thought that nodeapi wasn't called for users. If it is, then we definitely need to fix that. If not, then we need to add the appropriate hook for when a user gets deleted. What about Comments?

I'm excited about all this - really happened very quickly. I had this requirement for a project, and looked at this issue only a few days ago... went off to build the thing, and when I came back there was all this new action ! Really glad you're in on this with me.

So, going forward we should refer this issue to flag-note project? and take up the individual issues, patches there?

Do you have a CVS account already? If so, let me know and I'll ask the folks to add you as a maintainer. Actually, I think that there's this arcane protocol - like you havce to create an issue on flag_note asking for maintainship. I have to say it's all good, then you have to ask the Drupal Gods to make you a maintainer on the project and give them a link to the issue where I say it's all good... hmm hmm hmm

I'll take a look at the docs, feel free to do so yourself, and let's rock and roll.

Thanks much

switched to #505230: some thoughts about a flag history and some fixes/improvements

Fantastic, thanks guys! Any interested users should report questions/bugs to the new Flag Note issue queue.

I've just encountered a need for flag history functionality. I've spent a while researching in the issue queue for flag and flag_note, but the issues are old and it seems nothing has been done since and there is no flag history for the current d7 version of flag now (please correct me if I'm wrong).

Now that flags are fieldable entities, it seems those discussions are no longer applicable. I would think flag history should now be more like enabling revisions for individual flags much like revisions for content types. This probably could be done in a separate module, but it seems more like it belongs to the core flag module.

My question is, for the current maintainers, how do you see flag history functionality fitting into the flag module?

Well first off, we'd have to look at this on D8 first, as development on that branch is well under way.

Then for the D7 version of this, it would make sense to use the revisioning system in Entity API rather than write ours from scratch. But introducing a dependency on Entity API is something we've deliberately avoided so far.

So in conclusion, I would say: file a new issue to consider making Flaggings revisionable in D8, and look at a new contrib module for this on D7.