view relationships don't filter on flag type/id and user (current/any)

Yes it does produce duplicates, but it is a valid use case (at least to me).

For example I'm using this with flag abuse to list all individual abuse reports.

My suggestion would be just the flag connection (ie. above) with 'if no relationship used will cause duplicates' for people like me that desire the duplicates. I believe it does not interfere with any current functionality?

Ah sorry guess I'm confused... if the keep history is enabled is it possible to have more than one row in flag_note table to 'fcid'? I am not using that feature (or delete flag note).
From how I have it configured and what I understand fcid is flag content ID, and it connects one to one with the flag_content fcid ID so connecting via

  $data['flag_note']['table']['join'] = array(
    'flag_content' => array(
      'left_field' => 'fcid',
      'field' => 'fcid',
    ),
  );

would be a one to one connection and will show the flag note for a flagged instantaneous.

Ie user a flags content b with note c.
Ie user d flags content b with note e.

The view connected to the flag with fields Node title, flagger, note would should
b a c
b d e

The issue with connecting via nid, cim, or uid is not being about to connect on fcid, ie. a view of each flagged instantaneous and with item was flagged. (Or, I just think the sql looks prettier that way :<).

Ahh, still, the use case is valid so it;d be useful to provide it-- with a warning? There's several cases in views that mention certain filters/arguments could cause duplicates (like taxonomy filter/argument).

The current relations join via

comment id
node id
user id

But do not join the flag_content table and without the uncommented code, unless I'm missing it, cannot directly connect with the flag table and thus are excluded from all flag provided views information like limitation to fid.

My use case:
I'm using it with flag_abuse to make a view of reported abuses with the reasons why the report was issued. I want a list filtered by content is flagged with abuse (provided by flag_abuse) and the reasons why.
Uncommiting that code (and only that code that related flagged content id to flagged content ID), all I had to do was add the flag not field to my view and I was done; usability wise that is one advantage there since most peoples flag related views are set up like that.
In order to add the flag note with it commented out I'd have to add the relationship (no big deal), however since it's connecting via the node it wouldn't work. All notes would show up unfiltered by which flag was which

so instead of
User 1 flagged content b and said "blah"
User 2 flagged content b and said "bleh"

I'd get

User 1 flagged content b and said "blah
User 1 flagged content b and said "bleh"
User 2 flagged content b and said "blah
User 2 flagged content b and said "bleh"

Right? Since the relationship is just to the node so relationship from b goes to flag_note twice for each user flagging I think

Now, that would produce duplicates.

I could do it use of content, ignore the flagged relationship, however that would not be useful as soon as I have something else that uses flag_note.

Ie flag abuse with note, featured with note

User 1 flagged content b and said "blah" // flag abuse note
User 1 flagged content b and said "i love this" // feature flag

Right? Or am I really missing something?

Also something I just noticed

User 1 flagged node 4 and said "MEEP"
User 2 flagged comment 4 and said "RAWR"

it's not connecting via the flag tables at all from what I can tell... so

<?
// relationship (notes on comments)
$data['comments']['flag_note_comments_rel'] = array(
'group' => $groupname,
'title' => t('Notes on comment'),
'help' => t('All notes associated with a flagged comment.'),
'relationship' => array(
'label' => t('Flag note on comment'),
'base' => 'flag_note',
'base field' => 'content_id',
'relationship field' => 'cid',
),
);

?>

What's preventing a flag report on note 5 coming up when listing notes for comment 5? It's connecting on the cid to content_id, and content_id is not unique for node,user,comment, ie or rather unique for each but not among.

Am I really not understanding/missing something? @.@

That sounds like it'd work; most of what I know of views on a code level is from directly copy pasting/viewing other module's views implementation.

However, it might be a good time to seperate flag_history from flag_note and include the join with flag_content table-- for flag_note only.
The advantage of that is for people like me who aren't using the flag history can make their views via the flag_content, which is what I want XD

Flag note schema could probably be something like fcid, fvid (flag verison id, flag note id, unique history record id), note
So then the note could then connect:
1) the flag_content via fcid (with some way to distinish current flag_note for those using flag_history, maybe a filter or might be ways to add additonal information via the via. Also, could do something like taxonomy all terms where it groups all the records together. ).
2) and flag_history via fvid

Doesn't like that guy #526108: Flag notes v. Flag history has done anything yet though.