Exposing the flaggings table: Alternative Views support

I'm attaching a schema of how this can be done. This is a rip off of once-functional old patch I had laying around.

  // Advertise this table as a possible base table
  $data['flag_flagging']['table']['base'] = array(
    'field' => 'content_id',
    'title' => t('Flaggings'),
    'help' => t('Get at the individual flaggings.'),
    'numeric' => TRUE,
  );

'field' should point to 'fcid', of course, not to 'content_id'. (That snippet was written long ago, when we didn't yet have a primary key on that table.)

Another reason to expose this table:

Is there any trick to making the view sort on total flags within the past 24 hours?

If we expose this table, we will be able to do a "summary" on the flaggings done during the past X days/hours/etc.

Another reason to expose this table:

I need to get all flagged nodes from the users I have flagged.

[...]

Flag's Views implementation [...] should make the flagged content table (node) available for use as fields, filters, arguments, etc.

The patch achieves this by exposing three relationships: "The flagged node", "The flagged comment", The flagged user".

Another reason to expose this table:

[I want to add a section] "Users who have favorited this object have also favorited..."

(The "flagged node" relationship I mentioned in the previous reply solves this as well.)

There are many reasons to exposes this table. The code here complements the "flagging flaggings" feature which in itself solves many feature requests.

[...] to do the flag views integration rewrite

What's described in this thread isn't a rewrite. A rewrite entails writing an "upgrade path" for all the old views and to rewrite the handbook pages, and we don't have energy for this.

What's described here is a supplemental (or "alternative"), that could even reside in a separate module. The existing Views integration isn't modified.

Please read #859822: Views integration for private flags module and then come back here.

I've read it. You wrote:

Currently the only way to use flag_content fields is with the user relationshp, which limits the a user's flagged nodes to a single flag.

And this proposal (#371432) makes this possible. Don't you think so?

But I'd like to have buy in from the module maintainers before I start.

I can't speak on behalf of Nate. As for me, I've been AWOL so I'm not a factor. But it'd be easier for me to spend the few hours needed to complete this task than to make various promises. I may have good news for you: it's possible that I'll need to implement this anyway, to accommodate #871064: Making flaggings fieldable better.

#981912: List flags & its count user is falgged with - Views & Flag was marked a dup of this issue.

(It contains nice examples of views that are hard to make with the current Views support.)

(Fixed changing the title by mistake.)

I bet you lost hope, after two years, this moment would come :-)

There's now an alternative, better Views support for Flag:

Flag Vista

(Some may ask why wasn't "Flag Vista" posted as a mega-patch for Flag. Because it would have taken years to review it and write code to convert existing, old views. I suspect changing the Catholic doctrine would be easier. Instead, we should decouple Flag's built-in Views support into a separate module to give users the chance to simply not have it.)