Flag notes v. Flag history

well, you might be right. but i still cannot image a real situation in which you need to have a flag history without any information tied to the flagging/unflagging operation. may you please make an example ?

good point. it's possible to separate history and 'notes' (as additional information).
we have to use a table (a copy of the flag_content one) and a place to store optional additional info
(if you just want to keep an history) like cck/node tables: a rewrite of flag note to use cck nodes instead of just plain text
is planned. see #505230: some thoughts about a flag history and some fixes/improvements.

if you want to help you're welcome.
do you think there's the need for a split ?

i think that renaming the project to flag_history adding a functionality "add history information" (cck nodes through nodereference or userreference) would be the simplest (faster) solution. actually if you activate notes then you can choose to keep a flag history but probably the "you can activate notes regarding or not keeping of a flag history" paradigm is more correct.

anyway i understand the "building blocks" view so if you want to write a flag_history module you're welcome,
then i will refactor flag_note considering this new module, let me know.

i think i'll wait untill you finish flag_history as a separate project,
then i'll integrate a new major release of flag_note with it (if you agree).

cheers~

The discussion in #585976: view relationships don't filter on flag type/id and user (current/any) has gotten me thinking about flag_history (ya know when your mind wonders and end up back to a random subject again and again?). Again I'm mainly motived by the absolute belief that flag_note should safely be able to join with flag_content.

My current thoughts/suggestions would be that fcid (flag content id) is the flag version ID. The reasoning behind this is that fcid can change, to my knowledge, when an item is unflagged then reflagged. So it's changing id in some respect to the same information (content_type,content_id,fid,uid make a unique item).
So for a flag_history table
fcid, flag content id, serving as a vid
fhid, flag history id, serving as nid sorta. For every instance of content_type, content_id, fid, uid the same fhid is used. Or actually, don't even need this. Content_type,content_id,fid,uid is already serving as that.
Could also store an additional field argument that could describing what the change is ie "flag" "note change" etc.

So as far as views goes, should thus be able to make a connection to flag_history jut like flag_content and get the flagging history.

As far as flag_note goes it simplfies the schema
fcid
note

Since fcid is the unique for each note this way, it can directly connect to the flag_history and the flag_content tables without worries.

hook_flag is changing so could even add a 'note' as an action (search flag issues for that, too tired!)

Then flag_note changes by triggering an update on the fcid (either change the id or delete and re-insert. don't want to flag/unflag due to the hook's being called, just db change). Also, flag_note would not have to depend on flag_history.

Massive re-write, but not too much?

Anyhow, just suggestions.

Some new thoughts. Sorry, been walking too much and my mind decided to think of this :/!

One of the issues with just directly copying the flag table and keeping track of that is that there are other modules altering, connecting to flag_content, for example flag_weight (well, only one I can think of atm actually) (thus also why my fcid as fvid wouldn't work).

Flag weight operates by adding the variable to the flag_content table. It does that via the install function.

To keep appropriate track of the history of flag table, including things like flag_note and flag_weight, perhaps it'd be a good idea to try capturing the changes to flag_content.

Unfortuanlly there appears to be no hook called when a module is enabled, so can't react to that.

But if could get compatible modules to notify flag_history of new fields that they want flag_history to keep track of..

Then my newly suggested workflow ... (XD)...
(Altering tables is always wearisome in drupal, but it may work in this case?)
flag_history modifies flag_content with one field, fvid, flag verison id.
flag_history contains some sort of action to mark what has happened-flag, unflag, note changed, etc.
flag_note modifies flag_content with flag_note field.
flag_note notifies flag_history to add the flag_note field to flag_history.
on changes, ie. flag_note note changes, flag, maybe unflag,
a new entry into flag_history is made with all the details of the event.
when relavent, flag_content is updated with new fvid. (and any other relevant fields updated).

Also, nice to keep track of view's knowledge of flag_content. (For example, could directly the gather hook, hooks_views_data to figure out what has been emassed for flag_content. Or use the alter; I believe there is an alter). ?

shrug.

first thank you again for your suggestions. i've tried unsuccessfully to concact TUc for any progress about flag_history.
it seems that there's a lot of work to do (and plan). unfortutaley i'm busy till the end of the month (october).
if you would like to join the project i can give you cvs access (or just, well, wait =)

I still need to apply for a cvs account, but perhaps by then I will; I'd like to help.

Subscribing